Wake-on-LAN made usable by more than one person
Wake-on-LAN is an old, simple idea: send a specially formed packet to a network adapter so a sleeping or powered-off machine starts. The awkward part is everything around that packet. Someone must remember MAC addresses, know the right broadcast network, check whether a machine is already running, schedule recurring starts, and provide a safe way for other people to use it. UpSnap wraps those chores in a clean browser interface.
The dashboard can wake a device with one click, ping a chosen port to show its state, discover machines through a network scan, and run events on cron schedules. It can also issue a custom shutdown command. PocketBase supplies stored data and accounts, while UpSnap adds permissions that an administrator can assign per device: view, edit, delete, power on, or power off. That makes it more practical than a shell alias for a shared home lab, classroom, workshop, or small office.
The responsive interface offers 35 themes and 23 listed locales. UpSnap still stays focused: it is a power dashboard, not a remote desktop or monitoring system.
The one-command start hides network prerequisites
You can download a release binary and run upsnap serve, or launch the official container with host networking. Images cover amd64, arm64, arm/v7, and arm/v6, which suits common servers and single-board computers. The supplied Compose file persists PocketBase data under /app/pb_data, drops all capabilities except NET_RAW, and documents a non-root user option.
Host networking is not an incidental example. The file says it is required for magic packets, and the service must sit on a network path where broadcasts can reach the sleeping devices. Every target also needs Wake-on-LAN enabled in firmware and in its network adapter configuration. Wireless adapters, segmented VLANs, routers that suppress directed broadcasts, and devices that remove NIC power while off can defeat the feature. UpSnap cannot repair those conditions from its dashboard.
Discovery brings another dependency. Nmap must be available, while privileged ping and scanning use NET_RAW. Operators who disable privileged ping must grant the container's group permission through the host's net.ipv4.ping_group_range setting. Scheduled actions also depend on the container's time zone, so set TZ and verify a harmless schedule before relying on an overnight startup.
These are reasonable requirements for a network utility, and the README is candid about most of them. Still, budget more than the container pull: validate one device, then status detection, then scheduling, before entering the rest of the network.
Shutdown is powerful and deliberately dangerous
Wake packets are comparatively low risk. UpSnap's optional off action is different because it runs a user-defined command through a shell, possibly as root. The maintainers explicitly warn users not to expose the application to the open web. If an attacker found a route around authentication or abused that endpoint, the command path could become a shell on the local network.
That warning should determine the architecture. Keep UpSnap bound to the trusted LAN, or bind it to localhost behind a carefully configured proxy. Use WireGuard, OpenVPN, or another VPN when remote access is necessary. Per-device user permissions reduce accidental misuse, but they are not a reason to put a shell-adjacent service on a public URL. Use a dedicated SSH identity with narrow permissions for shutdown, avoid embedding a broadly privileged password, and test what each account can actually do.
The official container's capability choices are thoughtful: everything is dropped except the raw-network access needed for core functions, and no-new-privileges is offered as an option. A non-root setup is documented in the wiki. Those protections are worth enabling, especially if shutdown commands are configured.
Small rough edges in a mature core
The current open queue is tiny, but two reports affect expectations. One says devices can initially appear on or unavailable while lazy ping determines their real state, delaying the wake button. Another asks to remove the current IP-address requirement and resolve DNS or mDNS hostnames. That second thread includes a maintainer note about reduced personal availability and active contributor work on the change. Until it lands, installations with frequently changing DHCP addresses should use reservations or carefully maintained static entries.
Recent closed work shows responsive maintenance around related validation problems. Version 5.4.4 fixed IP and MAC address regular expressions plus subnet-mask checking. A later July fix closed a report where a valid CIDR value passed the interface but failed during wake. These are small details, but network addressing is the product's foundation, so pinning a tested release is sensible.
UpSnap also is not a substitute for device management. It does not promise operating-system patching, remote terminals, hardware inventory, or rich alerting. MeshCentral is better when those are the actual requirements. Home Assistant is a better home for wake actions driven by sensors and broader automations. UpSnap wins when people primarily need clear, controlled power buttons.
Active releases and an easy recommendation
The latest release, 5.4.4, shipped July 23, 2026, after a steady series of 5.3 and 5.4 releases from March through July. The repository was pushed July 26, and open pull requests were updated August 7. GitHub listed only five open issues and pull requests combined, with three of those five being proposed features. The maintainer's reduced availability is worth noting, but current release and contributor activity do not support calling the project dormant.
Documentation covers the main binary and Docker routes, reverse proxies, sub-path hosting, permissions, internet exposure, development, and translations. Important non-root and shutdown details live in the wiki rather than the main page, so production operators should read beyond the quick command.
UpSnap is easy to recommend for a trusted network. It takes a fussy protocol and gives it a dashboard that other people can safely understand, provided the operator respects the boundary around shell commands. The best rollout is modest: one host-networked instance, one known-compatible machine, persistent data, VPN-only remote access, and no shutdown command until its privileges have been narrowed and tested.