Upsnap

Wake-on-LAN tooling, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: Free, MIT-licensed web dashboard for Wake-on-LAN — click a button to remotely power on sleeping machines from any browser, with cron scheduling and network device discovery built in [README].
• Who it’s for: Homelab owners, remote workers who need to boot their office workstation from the couch, and small teams who are tired of leaving machines running 24/7. Requires some Docker comfort.
• Cost savings: No SaaS to replace — but if you’re leaving a desktop always-on to avoid boot wait, that’s 80–150W of continuous draw. Waking on demand can cut machine uptime by 60–70%, saving $7–25/month per machine in electricity depending on your rate.
• Key strength: Single binary or single Docker container. Does exactly what it says, no vendor dependency, no telemetry, no commercial tier to upsell you into [README].
• Key weakness: Requires a dedicated always-on intermediary device (Pi, NAS) on the same local network as the machines you want to wake. WoL is a Layer 2 protocol — UpSnap doesn’t solve the network topology problem, it just makes the tooling nicer [2].

---

What is Upsnap

Upsnap is a web UI wrapper around Wake-on-LAN, the 30-year-old networking protocol for remotely powering on machines that are off or asleep. You run it on a device that never shuts down — a NAS, a Raspberry Pi, any always-on Linux box — point a browser at port 8090, and click a button to wake any machine on your network that has WoL enabled in its BIOS.

The project description is refreshingly unpretentious: “A simple wake on lan web app written with SvelteKit, Go and PocketBase.” That’s the entire pitch. No AI integration angle, no enterprise tier teaser [README].

The tech stack is worth understanding. The backend is Go, using PocketBase — a self-contained Go server that handles the database (SQLite), user auth, and an admin API out of the box. The frontend is SvelteKit, compiled in at build time. The result is a single binary: download it, run it, done. Docker is also available with a well-commented compose file. At 5,398 GitHub stars and 211 forks, it has a healthy audience for a tool this narrowly focused.

The key technical reality that shapes every deployment decision: WoL packets live on Layer 2 (the data link layer), which Tailscale, WireGuard, and most VPN tunnels operate above [2]. That means you cannot send a magic packet over Tailscale from your laptop to your sleeping home desktop — not directly. You need a device that’s physically on the same LAN segment as the machine you want to wake. UpSnap runs on that intermediary. Your phone, connected via Tailscale, reaches UpSnap; UpSnap broadcasts the magic packet locally [2]. This isn’t a flaw in UpSnap — it’s WoL’s fundamental architecture — but it means UpSnap is a second piece of infrastructure, not a standalone solution.

---

Why people choose it

There aren’t many comparative reviews of WoL dashboards — it’s a niche category — but the Tailscale engineering blog [2] and NAS installation guides [3] illuminate the two main use cases.

The Raspberry Pi + Tailscale pattern is the canonical setup [2]. You have a workstation at home or at the office. It’s off. You’re remote. You want to start it without leaving it powered on all day. The solution: a Raspberry Pi connected by ethernet, running UpSnap, connected to your Tailnet. You hit UpSnap from your phone, click wake, the Pi sends the magic packet, the workstation boots, Tailscale reconnects it to your network [2]. The Tailscale blog describes this use case in detail and specifically calls out UpSnap as the right tool for the web UI layer.

NAS users are the other primary segment [3]. If you’re running a Synology, UGREEN, or TrueNAS box that’s already powered on 24/7, adding UpSnap as a Docker container costs nothing incremental — electricity is already flowing, the Docker runtime is already there. The MariusHosting install guide [3] walks through the Portainer deployment on UGREEN step by step, which tells you that NAS-based deployments are common enough to warrant detailed documentation.

What they’re escaping: The alternative to UpSnap is SSH-ing into an always-on device and typing wakeonlan -i 192.168.1.255 aa:bb:cc:dd:ee:ff from memory — or leaving machines permanently on. The web dashboard earns its place when more than one person needs wake access, when you want scheduled events, or when you simply want to click a button at 10 PM instead of opening a terminal.

---

Features

Based on the README and source articles:

Core functionality:

• One-click device wake from the browser dashboard [README]
• Custom port ping per device — ping port 3389 or 22 to confirm a machine finished booting, not just powered on [README]
• Cron-based scheduling for wake and shutdown events — “boot the workstation weekdays at 8 AM, shut it down at 7 PM” [README]
• Network scanning to auto-discover devices in a CIDR range with MAC address detection (requires nmap and root privileges) [README]
• 35 visual themes, light and dark variants [README]
• i18n support: Bulgarian, Czech, German, English, Spanish, French, Hindi, and more [README]

Auth and access control:

• Admin and user accounts, managed through PocketBase [README]
• Per-device, per-user permissions: admins control exactly who can view, edit, delete, or power each device on/off [README]
• No LDAP, no SSO — authentication is internal to the UpSnap instance [README]

Deployment options:

• Single binary download and run [README]
• Docker images for amd64, arm64, arm/v7, arm/v6 — covers Pi 3B, Pi 4, Pi 5, and nearly every NAS CPU [README]
• AUR package for Arch Linux [README]
• Subpath deployment behind reverse proxies (Caddy, nginx) documented with examples [README]
• Custom entrypoint for adding shutdown packages (e.g., sshpass, net-tools) into the Docker container [README]

What it doesn’t do:

• No mobile app — browser-only UI
• No built-in VPN or remote access relay — you handle that with Tailscale or WireGuard [2]
• No sleep or hibernate commands built-in — shutdown is a custom shell command you configure per device, running on the UpSnap host
• No network monitoring beyond port pings — not a replacement for Grafana, Uptime Kuma, or SNMP tools

---

Pricing: self-hosted math

There is no SaaS version of UpSnap and no commercial tier. The software is free, and the README says so explicitly — including a scam warning noting that anyone charging for UpSnap access is committing fraud [README].

The relevant cost math isn’t SaaS vs. self-hosted. It’s always-on electricity vs. on-demand wake.

If you’re leaving a desktop on 24/7:

• A mid-range workstation at idle: ~80–150W
• 120W × 24h × 30 days = 86.4 kWh/month
• At $0.15/kWh (US average): ~$13/month per always-on machine
• At $0.28/kWh (EU average, 2024): ~$24/month per always-on machine

If you only need it 8 hours a day, waking on demand:

• 120W × 8h × 30 days = 28.8 kWh/month
• At $0.15/kWh: ~$4.30/month — saving ~$8.70/month
• Annual saving per machine: $104 US / $196 EU

If you have two workstations or a small dev team with dedicated machines, this compounds quickly.

Cost to run UpSnap itself:

• Raspberry Pi 4 at idle: ~3–5W — roughly $0.54–$0.90/month at US rates
• A NAS already running: $0 incremental
• A cloud VPS: only relevant if UpSnap is on the same physical LAN as the target machines — which rules out most cloud VPS scenarios

UpSnap is free. The only real cost is the electricity for the host device, and if you already have a Pi or NAS running, that’s already baked into your existing power bill.

---

Deployment reality check

Wake-on-LAN has hardware prerequisites that UpSnap can’t paper over, and it’s worth being honest about the full setup picture.

Before you touch UpSnap:

1. WoL must be enabled in the BIOS/UEFI of every machine you want to wake — it’s off by default on many boards [2]
2. Target machines must be connected by ethernet at the physical layer — WoL over WiFi is unreliable and broadly unsupported [2]
3. You need an always-on device on the same LAN segment as the targets [2]

The UpSnap install itself is not the hard part. For a technical user who knows Docker: the compose file is clear, the environment variables are documented, and the reverse proxy examples for Caddy and nginx are both included in the README. Budget 15–30 minutes to a working instance. MariusHosting’s guide [3] gets a NAS user through Portainer deployment in about 8 steps — the guide exists because the process is repeatable enough to document.

Non-root gotchas:

• Running as root (or granting cap_net_raw) is required for the nmap network scan page [README]
• Running as a non-root user (e.g., user: 1000:1000) disables network scan — you add devices by entering MAC addresses manually [README]
• Docker must run in host network mode for the most reliable Layer 2 broadcast behavior; bridge mode can interfere with magic packets in some network configurations

The security warning that’s easy to skip:

The README is direct about this:

“Although UpSnap has user authorisation, it is not recommended to expose it to the open web… The shutdown device command is basically a command piped to sh (root if you run docker). If anyone gains unauthorized access and can abuse this api route in any way, the attacker has access to a (root) shell on your local network.” [README]

Do not put UpSnap on a public IP, even with strong credentials. Use a VPN. The Tailscale blog [2] recommends this exact setup and walks through it. This means two pieces of software to configure before you’re done, not one. Budget for it, and don’t skip the VPN step because it “seems like too much.”

Realistic time estimates:

• Technical user with Docker experience: 30–60 minutes including VPN and reverse proxy
• NAS user following a guide like MariusHosting [3]: 1–2 hours
• Non-technical user without a technical helper: this setup is probably not a good fit

---

Pros and Cons

Pros

• MIT license, no commercial upsell, no telemetry. The README explicitly warns against scams charging for UpSnap access. Unconditionally free, unconditionally open [README].
• Single binary or single container. No external database, no Redis, no separate services. PocketBase bundles SQLite. One Docker container covers everything [README].
• Cross-architecture Docker images. amd64, arm64, arm/v7, arm/v6 — covers Raspberry Pi models across generations, every major NAS platform, and x86 servers [README].
• Cron scheduling built in. Scheduled wake and shutdown events are first-class features, not shell scripts you wire up yourself [README].
• Per-device user permissions. Fine-grained enough to give a colleague access to wake their own machine without touching anyone else’s [README].
• Network scan for device discovery. Point UpSnap at a CIDR range and let it find your devices — no manual MAC address lookups for users running as root [README].
• 35 themes. Unusually complete visual polish for a focused utility [README].
• Port ping confirmation. Know the machine actually finished booting before you try to RDP in [README].
• Active maintenance. 2,228 commits, regular releases, AUR package maintained, Docker images for current hardware [README][3].

Cons

• Requires an always-on intermediary. WoL’s Layer 2 constraint means UpSnap is always a second device, not a standalone solution [2]. If you don’t already have a Pi or NAS, that’s an upfront cost and setup task.
• No VPN built-in. Remote access requires a separate VPN setup [2]. UpSnap handles the WoL UI; it does not handle the network access problem.
• Root required for network scanning. Non-root users lose the scan feature and must add devices manually [README].
• Shutdown command is a shell pipe. Powerful for automation; dangerous if UpSnap is misconfigured and exposed publicly. This is honest but requires careful deployment [README].
• No SSO or LDAP. User management is internal PocketBase auth. Fine for personal use or two-person teams, awkward for company-wide deployment [README].
• Hardware requirements are outside UpSnap’s control. If the target machine doesn’t support WoL or uses WiFi, nothing in UpSnap can compensate [2].
• PocketBase dependency. PocketBase is relatively new (2022). If its development stalls or introduces breaking changes, UpSnap’s storage and auth layer is affected.
• No alerting or monitoring. UpSnap will report a port as up or down; it won’t notify you when a machine unexpectedly powers off or fails to wake.
• Sparse third-party coverage. Aside from the Tailscale blog and NAS install guides, independent user reports on long-term reliability or edge case behavior are hard to find.

---

Who should use this / who shouldn’t

Use Upsnap if:

• You already have a Raspberry Pi, NAS, or other always-on device on your LAN and want a clean UI to wake machines remotely instead of typing MAC addresses into a terminal.
• You’re already using Tailscale or WireGuard and want a WoL dashboard that slots into that access model [2].
• You want scheduled wake and shutdown events configured through a UI, not cron jobs written by hand.
• You need to give a family member or colleague one-click access to wake a specific machine without giving them SSH access.
• You’re on a NAS platform (Synology, UGREEN, TrueNAS) that already runs Docker and has always-on uptime [3].

Skip it if:

• You don’t have an always-on device on your LAN. UpSnap is useless without a host — it can’t wake machines if nothing is running.
• Your target machines connect by WiFi only. WoL requires ethernet at the NIC level. This is hardware, not software [2].
• You want network monitoring, infrastructure dashboards, or alerting. UpSnap is a WoL tool, not an observability platform.
• You need SSO, audit logs, or team governance features. This is personal/small-team utility software [README].
• You’re a non-technical user without someone to help with Docker and VPN setup. The security requirement — don’t expose to public internet — means the VPN step is not optional.

Consider Home Assistant instead if:

• You’re already running Home Assistant for home automation. Its built-in WoL integration covers the same ground with mobile app access and automations already in place — UpSnap would be redundant.

---

Alternatives worth considering

CLI tools (wakeonlan, etherwake, wol): Free, package-manager installable, zero setup beyond SSH access to an always-on device. If you’re comfortable opening a terminal, the web UI adds convenience but not capability. Evaluate honestly whether you need UpSnap over a bash alias.

Home Assistant WoL integration: If you already run Home Assistant, its Wake-on-LAN integration offers the same functionality — device wake buttons, automations, mobile app — without a separate container. For HA users, UpSnap is probably redundant.

Proxmox and TrueNAS SCALE: Both platforms include built-in WoL tools in their admin panels. If your machines run under these hypervisors, check whether the native feature covers your needs before adding another container.

WireGuard + command line: The manual approach — WireGuard for network access, a Pi as the WoL broadcaster, shell commands for wake. More setup, no UI, but zero extra software to maintain. Appropriate if you run a lean infrastructure and don’t need multi-user access.

Commercial WoL services: Services that claim to offer WoL over the internet via port forwarding exist but require opening your router to inbound traffic — which is exactly what UpSnap’s README recommends against. Avoid these.

For most homelab setups, the realistic decision is UpSnap vs. Home Assistant WoL (if HA is already in the stack) or UpSnap vs. a bash alias (if you prefer minimal infrastructure). UpSnap wins when multiple users need access, when scheduling matters, or when the UI genuinely reduces friction for your use pattern.

---

Bottom line

UpSnap is exactly what it says it is. A free, clean, MIT-licensed web dashboard for Wake-on-LAN. It doesn’t oversell, it has no commercial tier, and its README will tell you directly not to expose it to the public internet and why. That kind of honest documentation is a positive signal in utility software.

The single most important thing to understand before installing it: UpSnap solves the UI problem around WoL, not the network topology problem. You still need an always-on device on your LAN. You still need WoL configured in BIOS on every target machine. You still need a VPN for remote access. UpSnap is the layer on top of that infrastructure — a friendly, well-maintained face on a 30-year-old protocol. If the plumbing is in place, UpSnap is a genuine quality-of-life upgrade. If it isn’t, budget the time to lay it before installing UpSnap.

If getting Tailscale, a Raspberry Pi, and UpSnap configured correctly sounds like an afternoon you don’t have, that’s the kind of one-time setup upready.dev handles for clients — configured properly, documented, with you owning the infrastructure afterward.

---

Sources

2. Tailscale Blog — “Make a dedicated Wake-on-LAN server with Tailscale” (August 19, 2025). https://tailscale.com/blog/wake-on-lan-tailscale-upsnap
3. MariusHosting — “How to Install UpSnap on Your UGREEN NAS”. https://mariushosting.com/how-to-install-upsnap-on-your-ugreen-nas/

Primary sources:

• GitHub repository and README: https://github.com/seriousm4x/UpSnap (5,398 stars, MIT license, 2,228 commits)