O GPTWOL pode ser executado no ZimaOS como uma aplicação Docker personalizada, mas o mais importante no YAML da comunidade não são as credenciais de exemplo antigas. A aplicação precisa de rede do anfitrião para poder enviar pacotes Wake-on-LAN na rede local, de armazenamento persistente para a respetiva base de dados e dados do cron, e de uma porta web que não esteja já a ser utilizada por outro serviço.
O tópico de janeiro de 2026 é útil como configuração de referência funcional, mas tanto o GPTWOL como o ZimaOS evoluíram. A documentação atual do GPTWOL continua a exigir rede do anfitrião para o Wake-on-LAN, enquanto as versões atuais do ZimaOS disponibilizam um fluxo de trabalho YAML mais completo. Trate o ficheiro de origem como um ponto de partida e confirme as opções atuais no projeto upstream antes de o importar.
O que o YAML da comunidade configurava
A definição da aplicação partilhada utilizava a imagem misterbabou/gptwol:latest, network_mode: host e restart: unless-stopped. Também guardava o estado do GPTWOL em duas pastas do anfitrião, mapeadas para /app/db e /etc/cron.d.
A configuração de origem disponibilizava a interface do GPTWOL na porta 99 e definia um fuso horário para as tarefas de ativação agendadas. Estes valores não são universais. Escolha uma porta livre no anfitrião e utilize o fuso horário correspondente à máquina que executa o contentor.
Por que motivo o GPTWOL utiliza a rede do anfitrião
A documentação upstream atual do GPTWOL indica que o contentor precisa do modo de rede do anfitrião para enviar comandos Wake-on-LAN na LAN. Isto é diferente de uma aplicação web normal, que muitas vezes pode permanecer isolada numa rede bridge do Docker e utilizar apenas uma porta publicada.
A rede do anfitrião também altera a forma como deve pensar nas portas. A aplicação escuta diretamente na rede do anfitrião ZimaOS, pelo que a porta selecionada para o GPTWOL tem de estar livre. Se a página web não abrir, confirme a porta configurada e verifique se existe outro serviço a escutá-la antes de alterar definições não relacionadas no router.
Configuração Docker atual do GPTWOL documenta o modo de rede necessário, os caminhos de armazenamento, as opções de autenticação e as funcionalidades de agendamento.
Não reutilize as credenciais de início de sessão de exemplo
O YAML da comunidade ativava a autenticação local e utilizava credenciais de exemplo simples. Estas mostram como o utilizador de origem configurou a aplicação, mas não constituem uma predefinição segura a copiar para uma nova instalação.
Se ativar a autenticação local, substitua qualquer nome de utilizador e palavra-passe públicos de exemplo antes da primeira implementação real. As versões atuais do GPTWOL também suportam OIDC. Em qualquer dos casos, o projeto upstream recomenda não expor diretamente o serviço à Internet pública sem uma autenticação adequada.
O Wake-on-LAN é normalmente uma função de controlo da LAN. Se precisar de o acionar quando estiver fora de casa, prefira uma camada de acesso remoto segura em vez de colocar diretamente a interface web do GPTWOL numa porta pública.
Importar ou editar o YAML no ZimaOS atual
O tópico de janeiro de 2026 é anterior à experiência YAML atual do App Store 2.0. O ZimaOS 1.7 introduziu a edição YAML nativa para aplicações e o ZimaOS 1.7.1 melhorou ainda mais a compatibilidade ao guardar YAML. Isto significa que as capturas de ecrã ou a localização dos botões da publicação original podem já não corresponder à interface atual.
Mantenha a definição do serviço Compose simples: imagem, rede do anfitrião, política de reinício, valores de ambiente necessários e volumes persistentes. Não mantenha metadados x-casaos obsoletos apenas porque apareciam num ficheiro exportado, a menos que o fluxo de trabalho atual das aplicações do ZimaOS necessite efetivamente deles.
Notas de lançamento do ZimaOS 1.7.1 descrevem as melhorias atuais de compatibilidade YAML.
O GPTWOL não pode ativar o WOL num destino que não o suporte
O GPTWOL envia o pacote de ativação; não torna compatível um computador que não suporte ativação remota. A máquina de destino continua a precisar de ter o Wake-on-LAN ativado no firmware e no sistema operativo, e o adaptador de rede tem de continuar apto a receber o pacote mágico no estado de energia pretendido.
Antes de depurar o contentor, confirme que o destino pode ser ativado por outra ferramenta WOL conhecida e funcional na mesma LAN. Se isso funcionar, teste então o GPTWOL. Se nenhuma ferramenta conseguir ativar o destino, comece por resolver problemas na BIOS, na placa de rede, no estado de encerramento e no percurso da rede do destino.
