One dashboard controls wake, status, schedules, and access
Wake-on-LAN sends a special packet to start a sleeping or powered-off machine. UpSnap handles the awkward details around that packet: saved devices, MAC addresses, broadcast settings, status checks, scheduled events, and access for more than one person. PocketBase supplies storage and accounts. An administrator can grant each user separate rights to view, edit, delete, wake, or shut down a device.
The product stays focused. It can ping a configurable port, discover devices through a network scan, and run cron events. The interface includes 35 themes and 23 listed locales, but UpSnap is not a remote desktop, monitoring stack, or operating-system management service. That limited scope is a strength for a home lab, classroom, workshop, or small office that mainly needs reliable power buttons.
Host networking and target firmware decide whether wake works
Users can run a release binary on port 8090 or pull the official container. Published images cover amd64, arm64, arm/v7, and arm/v6. The Compose example uses host networking because magic packets need the network's broadcast path, and it persists PocketBase state under /app/pb_data. A non-root route is documented separately in the wiki.
Every target must have Wake-on-LAN enabled in firmware and in its network adapter. Wireless hardware, VLAN boundaries, routers that block directed broadcasts, and machines that cut power to the adapter can prevent a wake even when the dashboard reports that it sent the packet. Test one known-compatible device before importing the network. A working web page proves only that UpSnap is running.
Discovery requires nmap. Privileged ping and scanning use NET_RAW, while the container example drops other Linux capabilities. Non-root ping may also need the host's net.ipv4.ping_group_range adjusted. Cron follows the container time zone, so set TZ and check one harmless scheduled event before depending on an overnight start. These details turn the one-command launch into a small network deployment.
What happened when we ran it
Our sandbox worked in the backend directory at commit 297518f. Installing 85 Go packages took 30 seconds, and the build succeeded in 49 seconds. The test step completed in 27 seconds with 1 passed and 0 failed out of 1. That is a clean measured result, although one discovered test cannot cover every broadcast, account, cron, scan, and shell-command path.
The checkout held 155 files, about 8,618 source lines, and occupied 5.1 MB. Our scan found 3 CI workflow files, no Dockerfile, and no tests directory. The README still points users to official container images and a Compose file, so the absent Dockerfile describes the repository signal from our harness rather than the availability of a container deployment.
We did not send packets to physical machines or evaluate a real routed network. The 30-second install and 49-second build establish that the backend compiled in our fresh 3-CPU, 8 GB Debian container. They do not establish that a particular BIOS, network adapter, router, or VLAN will pass and act on a magic packet.
A shutdown command can become a root shell path
UpSnap's off action runs a user-defined command through a shell, potentially as root. The README explicitly recommends against exposing the application to the public internet because unauthorized use of that API route could provide shell access on the local network. This warning should determine the deployment: keep the service on a trusted LAN and use WireGuard, OpenVPN, or another VPN for remote access.
Per-device permissions help prevent ordinary users from changing or powering machines they do not own. They do not make a public shell-adjacent endpoint safe. Use a dedicated SSH identity for shutdown, restrict it to the needed host and command, and avoid storing a broadly privileged password. The safest configuration is no shutdown action at all if wake is the only required job.
The container example's capability choices reduce some exposure by retaining only raw-network access, and a non-root setup is available. Verify the effective user and permissions after deployment. A proxy and TLS protect transport, but neither addresses what the configured shutdown command can do after a valid or stolen login reaches it.
IP addressing still creates two visible rough edges
Open issue 1762 says a device can initially appear on or unavailable while lazy status checking finds its real state, delaying the wake control. Issue 1753 asks to remove the required IP address and add DNS or mDNS names. An open pull request updated in August 2026 proposes FQDN support, but an unmerged proposal is not a shipped feature. DHCP-heavy networks should use reservations or maintain addresses carefully until their chosen release supports names.
Version 5.4.4 shipped on July 23, 2026 with address-validation fixes. GitHub recorded the last repository push on July 26, 6,223 stars, and 6 combined issues and pull requests. Pull requests were still updated in August. That mix supports an active-health judgment even though the open queue includes contributor proposals rather than six product defects.
Use it on a trusted LAN, not as a public control plane
UpSnap offers more discipline than a wake script without expanding into full device management. The measured backend installed and built cleanly, the documentation says plainly where the dangerous boundary sits, and current releases cover common processor architectures. Home Assistant is a better fit when wake is one step in a larger household automation. MeshCentral makes more sense when ongoing remote administration is the job.
For its narrow purpose, UpSnap is easy to recommend. Start with one host-networked instance, persistent data, one known device, and a VPN route. Add schedules after checking the time zone. Add users after testing permissions. Treat custom shutdown as a separate security project rather than another button in the dashboard.