GPTWOL can run on ZimaOS as a custom Docker application, but the important part of the community YAML is not the old example credentials. The application needs host networking so it can send Wake-on-LAN packets on the local network, persistent storage for its database and cron data, and a web port that is not already used by another service.
The January 2026 thread is useful as a working configuration snapshot, but GPTWOL and ZimaOS have both evolved. Current GPTWOL documentation still requires host networking for Wake-on-LAN, while current ZimaOS releases provide a more capable YAML workflow. Treat the source file as a starting point and verify the current upstream options before importing it.
What the Community YAML Configured
The shared application definition used the misterbabou/gptwol:latest image, network_mode: host, and restart: unless-stopped. It also persisted GPTWOL state under two host folders mapped into /app/db and /etc/cron.d.
The source configuration exposed the GPTWOL interface on port 99 and set a timezone for scheduled wake jobs. Those values are not universal. Pick a free host port and use the timezone that matches the machine running the container.
Why GPTWOL Uses Host Networking
GPTWOL's current upstream documentation says the container needs host network mode to send Wake-on-LAN commands on the LAN. This is different from an ordinary web application that can often stay isolated behind Docker bridge networking and a single published port.
Host networking also changes the way you think about ports. The application listens directly on the ZimaOS host network, so the selected GPTWOL port must already be free. If the web page does not open, verify the configured port and check whether another service is listening there before changing unrelated router settings.
Current GPTWOL Docker configuration documents the required network mode, storage paths, authentication options, and scheduling features.
Do Not Reuse the Example Login Credentials
The community YAML enabled local authentication and used simple example credentials. They are evidence of how the source user configured the app, not a secure default to copy into a new installation.
If you enable local authentication, replace any public example username and password before the first real deployment. GPTWOL also supports OIDC in current releases. In either case, the upstream project warns against exposing the service directly to the public internet without proper authentication.
Wake-on-LAN is usually a LAN-control function. If you need to trigger it while away from home, prefer a secure remote-access layer rather than placing the GPTWOL web interface directly on a public port.
Import or Edit the YAML in Current ZimaOS
The January 2026 thread predates the current App Store 2.0 YAML experience. ZimaOS 1.7 introduced native YAML editing for applications, and ZimaOS 1.7.1 further improved YAML saving compatibility. That means screenshots or button locations from the original post may no longer match the current interface.
Keep the Compose service definition simple: image, host networking, restart policy, required environment values, and persistent volumes. Do not carry over stale x-casaos metadata merely because it appeared in an exported file unless the current ZimaOS app workflow actually needs it.
ZimaOS 1.7.1 release notes describe the current YAML compatibility improvements.
GPTWOL Cannot Enable WOL on a Target That Does Not Support It
GPTWOL sends the wake packet; it does not make an incompatible computer wake-capable. The target machine still needs Wake-on-LAN enabled in its firmware and operating system, and its network adapter must remain able to receive the magic packet in the intended power state.
Before debugging the container, prove that the target can be awakened by another known-good WOL tool on the same LAN. If that works, then test GPTWOL. If no tool can wake the target, troubleshoot the target's BIOS, NIC, shutdown state, and network path first.
