GPTWOL puede ejecutarse en ZimaOS como una aplicación Docker personalizada, pero la parte importante del YAML de la comunidad no son las credenciales de ejemplo antiguas. La aplicación necesita usar la red del host para poder enviar paquetes Wake-on-LAN en la red local, almacenamiento persistente para su base de datos y los datos de cron, y un puerto web que no esté siendo utilizado por otro servicio.
El hilo de enero de 2026 resulta útil como configuración de referencia funcional, pero tanto GPTWOL como ZimaOS han evolucionado. La documentación actual de GPTWOL sigue requiriendo el uso de la red del host para Wake-on-LAN, mientras que las versiones actuales de ZimaOS ofrecen un flujo de trabajo YAML más completo. Considera el archivo de origen como un punto de partida y verifica las opciones actuales del proyecto antes de importarlo.
Qué configuraba el YAML de la comunidad
La definición de la aplicación compartida utilizaba la imagen misterbabou/gptwol:latest, network_mode: host y restart: unless-stopped. También guardaba el estado de GPTWOL de forma persistente en dos carpetas del host, asignadas a /app/db y /etc/cron.d.
La configuración de origen exponía la interfaz de GPTWOL en el puerto 99 y establecía una zona horaria para las tareas programadas de activación. Estos valores no son universales. Elige un puerto libre del host y utiliza la zona horaria correspondiente al equipo que ejecuta el contenedor.
Por qué GPTWOL utiliza la red del host
La documentación actual del proyecto GPTWOL indica que el contenedor necesita el modo de red del host para enviar comandos Wake-on-LAN en la LAN. Esto difiere de una aplicación web común, que a menudo puede permanecer aislada mediante la red bridge de Docker y un único puerto publicado.
La red del host también cambia la forma de gestionar los puertos. La aplicación escucha directamente en la red del host de ZimaOS, por lo que el puerto seleccionado para GPTWOL debe estar libre. Si la página web no se abre, verifica el puerto configurado y comprueba si otro servicio está escuchando en él antes de modificar otros ajustes del router.
Configuración actual de Docker de GPTWOL documenta el modo de red requerido, las rutas de almacenamiento, las opciones de autenticación y las funciones de programación.
No reutilices las credenciales de inicio de sesión de ejemplo
El YAML de la comunidad habilitaba la autenticación local y utilizaba credenciales de ejemplo sencillas. Estas muestran cómo configuró la aplicación el usuario original, pero no son valores predeterminados seguros que debas copiar en una instalación nueva.
Si habilitas la autenticación local, cambia cualquier nombre de usuario y contraseña de ejemplo públicos antes de realizar la primera implementación real. GPTWOL también admite OIDC en sus versiones actuales. En cualquier caso, el proyecto advierte que no se debe exponer el servicio directamente a Internet sin una autenticación adecuada.
Wake-on-LAN suele ser una función de control dentro de la LAN. Si necesitas activarlo cuando estés fuera de casa, es preferible utilizar una capa segura de acceso remoto en lugar de colocar directamente la interfaz web de GPTWOL en un puerto público.
Importa o edita el YAML en la versión actual de ZimaOS
El hilo de enero de 2026 es anterior a la experiencia YAML actual de App Store 2.0. ZimaOS 1.7 introdujo la edición YAML nativa para aplicaciones, y ZimaOS 1.7.1 mejoró aún más la compatibilidad al guardar YAML. Por ello, las capturas de pantalla o la ubicación de los botones de la publicación original pueden no coincidir con la interfaz actual.
Mantén sencilla la definición del servicio de Compose: imagen, red del host, política de reinicio, valores de entorno necesarios y volúmenes persistentes. No conserves metadatos x-casaos obsoletos solo porque aparezcan en un archivo exportado, a menos que el flujo de trabajo actual de aplicaciones de ZimaOS realmente los necesite.
Notas de la versión de ZimaOS 1.7.1 describen las mejoras actuales de compatibilidad con YAML.
GPTWOL no puede habilitar WOL en un objetivo que no lo admite
GPTWOL envía el paquete de activación; no hace que un equipo incompatible pueda activarse. El equipo de destino debe tener Wake-on-LAN habilitado en su firmware y sistema operativo, y su adaptador de red debe poder seguir recibiendo el paquete mágico en el estado de alimentación previsto.
Antes de depurar el contenedor, comprueba que el equipo de destino pueda activarse mediante otra herramienta WOL conocida y funcional en la misma LAN. Si funciona, prueba entonces con GPTWOL. Si ninguna herramienta puede activar el equipo, investiga primero la BIOS, la tarjeta de red, el estado de apagado y la ruta de red del equipo de destino.
