Wakupator

Self-hosted network power management, honestly reviewed. No marketing fluff, just what you get when you run a home lab.

TL;DR

• What it is: A lightweight Linux daemon that intercepts network traffic destined for sleeping machines and wakes them via Wake-on-LAN — no firewall changes required [1][README].
• Who it’s for: Home lab operators and small-infrastructure owners who want to stop running servers 24/7 and only spin them up when traffic actually arrives [1][README].
• Cost savings: Purely a function of electricity. A home server drawing 50W running 24/7 costs ~$65/year at US average rates. If Wakupator cuts active hours by two-thirds, you save ~$43/year — per machine [1].
• Key strength: Genuinely non-intrusive. It intercepts packets before your firewall sees them, requires no application-layer changes, and works with any IP-based service [README].
• Key weakness: Sensitive to internet-facing traffic and bot scans. Any unsolicited packet on a monitored port wakes the machine. If your server is exposed to the internet, expect unexpected wake-ups [README].

---

What is Wakupator

Wakupator is a Linux binary that sits on your always-on host (the README example uses a Raspberry Pi) and watches your LAN for traffic destined for machines that are currently off. When traffic arrives on a monitored IP and port, it sends a Wake-on-LAN magic packet to bring that machine up [README].

The mechanism is clever in a low-level way: rather than setting up proxy services or NAT rules, Wakupator uses IP spoofing — it temporarily claims the IP addresses of sleeping machines on the network, so the Linux kernel delivers their incoming packets to Wakupator’s raw socket. When it detects that traffic, it fires the WoL packet and stops spoofing [README][1].

Before a machine shuts down, it POSTs a JSON registration to Wakupator specifying which IPs and ports to monitor. Wakupator holds that registration until the machine wakes up, then drops it. The client is identified by MAC address, so multiple machines with multiple IP/port combinations can coexist [README][1].

The project was created by a developer (GitHub handle: gibus21250) who shared it on r/homelab with a Minecraft server as the motivating use case: “I have a machine hosting services like a Minecraft server, but don’t need it running 24/7, Wakupator can wake it up automatically when someone tries to connect to it” [1]. That explains the design philosophy well — it’s purpose-built for exactly this scenario, not a general-purpose power management platform.

As of this review, the project has 167 GitHub stars and is MIT-licensed. It’s a single-developer project, not backed by a company or community of contributors [GitHub].

---

Why people choose it

There isn’t a large corpus of third-party reviews — this is a niche tool with a small following. The main public signal is the original r/homelab introduction post [1] and its listing in the awesome-selfhosted catalog [2][3]. That’s a thin signal by the standards of a mature project, so this section pulls primarily from the README and the creator’s own description.

The core value proposition is specific and honest: energy savings at the cost of availability. The creator doesn’t overclaim. The homepage pitch (GitHub README) literally says “The main goal of this project is to reduce energy wasting by sacrificing availability” — not something you’d read in a VC pitch deck [README]. Machines take time to boot after a WoL packet. Your first connection attempt will time out or reset. Users who can’t tolerate that delay don’t belong in Wakupator’s target audience.

What sets it apart from simpler WoL tools is the no-configuration-required interception model. Most WoL setups require either:

1. A user to manually send a WoL packet (too manual for automation)
2. A reverse proxy or port forwarder that stays alive to receive connections (requires app-layer config)
3. Static IP/MAC bindings changed on your router

Wakupator sidesteps all three by reading packets before the firewall at the raw socket level. Nothing on your router needs to change. No proxy to maintain. The sleeping machine’s IP just appears live on the network as far as incoming packets are concerned [README].

The r/homelab community reception was warm but realistic — the post has engagement from users interested in home server power management, and the creator was transparent about limitations including bot scan sensitivity and the machine startup latency trade-off [1].

---

Features

Based on the README:

Core operation:

• Watches for incoming traffic on registered IPs and ports using raw sockets [README]
• Temporarily claims sleeping machines’ IP addresses via spoofing to receive their packets [README]
• Sends Wake-on-LAN (IEEE 802.3) magic packets when traffic is detected [README]
• Supports multiple registered clients simultaneously; each identified by MAC address [README]
• Supports both IPv4 and IPv6 (with caveats for IPv6, detailed in Deployment section) [README]
• Works with any IP-based service — not limited to HTTP/HTTPS or any specific protocol [README]

Registration flow:

• Machines register via a JSON POST before shutdown [README]
• Registration includes IP addresses and ports to monitor [README]
• Registration is automatically removed when the machine wakes up [README]

Deployment:

• Distributed as a pre-compiled binary for Linux; source compile also documented [README]
• No Docker image (binary-only) [README]
• Requires cap_net_raw and cap_net_admin Linux capabilities — can run without full root via setcap [README]
• Includes a systemd service file example [README]

What it does NOT have:

• Web UI or dashboard
• Docker image
• Windows or macOS support (Linux only) [README]
• Built-in scheduling or time-based rules
• Automatic registration (machines must register themselves before shutdown)
• Any mechanism to prevent bot-scan-triggered wake-ups beyond network-level filtering [README]

---

Pricing: energy cost math

Wakupator is free and MIT-licensed. There is no SaaS tier, no cloud offering, no paid plan — this is strictly a self-hosted binary [README].

The relevant cost comparison is electricity:

Always-on home server:

• Mini PC or NAS: ~20–50W draw
• At 50W, 24/7: 438 kWh/year
• At US average ($0.15/kWh): **$66/year per machine**

With Wakupator (assume server active 6–8 hours/day on average):

• 50W × 7h × 365 = 128 kWh/year
• Cost: ~$19/year per machine
• Savings: ~$47/year per machine

Raspberry Pi running Wakupator itself:

• ~3–5W continuous draw
• ~$4–6/year additional electricity cost

Net: if you have two or three machines on Wakupator, you’re saving $80–130/year in electricity while the always-on host (Pi or equivalent) costs you ~$5 extra. The math is real but modest — this isn’t replacing a $200/month SaaS bill, it’s trimming a household utility cost [1].

The creator’s framing is accurate: “Save energy, save the Planet! (and reduce your bills)” [1]. It’s a genuine quality-of-life and environmental win for home lab operators, not a cost-savings play for commercial infrastructure.

---

Deployment reality check

Wakupator has a steeper setup curve than the r/homelab post makes it sound. It’s not a Docker Compose one-liner. Here’s what’s actually involved:

Prerequisites:

• An always-on Linux host on the same LAN as the machines you want to manage (Raspberry Pi is the typical choice) [README][1]
• Wake-on-LAN enabled in BIOS/UEFI and the OS on every machine you want to wake [README]
• Network infrastructure that does not have static IP/MAC bindings for the IPs Wakupator will spoof [README]

Installation:

1. Download pre-compiled binary or compile from source [README]
2. Set Linux capabilities: sudo setcap cap_net_raw,cap_net_admin+eip /path/to/wakupator [README]
3. (Recommended) Install as a systemd service using the provided example unit file [README]
4. Configure each managed machine to POST its registration JSON to Wakupator before shutting down [README]

The registration automation step is non-trivial. You need to write a shutdown script on each managed machine that fires before the network goes down. The README documents this in the example section but it requires you to wire it into your shutdown process — systemd ExecStop or a similar hook [README].

IPv6 gotcha: If you’re monitoring an IPv6 address and the machine can also start manually (not just via WoL), you must disable Duplicate Address Detection (DAD) on the client machine: sysctl -w net.ipv6.conf.all.accept_dad=0. The reason: when the machine boots manually, it sends ICMPv6 Neighbor Solicitation probes to check if its IP is in use — and Wakupator is still spoofing that IP, so the kernel may flag it as a duplicate address and bring the interface down in a degraded state. Disabling DAD avoids this race condition [README].

The bot scan problem is the most operationally painful limitation. The README is upfront about it: services exposed to the internet will receive frequent port scans and those packets can trigger Wakupator and wake machines unnecessarily. The documented mitigation is to filter bot traffic at your router or hardware firewall — but that’s additional configuration that may not be feasible for everyone [README]. In practice, this means Wakupator works cleanly for LAN-only services (NAS, game servers, internal tools) and gets messy for anything internet-facing.

Services on the Wakupator host itself must not bind to 0.0.0.0 or :: on ports being monitored — your SSH daemon on port 22, for example, should bind only to the host’s real IP, not all interfaces, otherwise it conflicts with spoofed addresses [README].

Realistic setup time for someone comfortable with Linux: 1–3 hours for a clean install with one managed machine, including shutdown hook setup and testing. Budget extra time for IPv6 or multiple machines. For someone new to Linux capabilities and systemd service files, add 2–4 hours.

---

Pros and Cons

Pros

• MIT-licensed, no phone-home, no telemetry. It’s a binary that runs on your hardware. Nothing calls back to a server [README].
• No firewall or router changes. The IP spoofing approach means your network config stays exactly as-is. Add or remove managed machines without touching your router [README].
• Works with any IP protocol. Doesn’t care if it’s TCP, UDP, game traffic, custom protocols. If there’s an IP packet, Wakupator sees it [README].
• Minimal resource footprint. Designed to run on a Raspberry Pi. Not competing for RAM with services you actually care about [1][README].
• Honest about trade-offs. The README and the creator’s own post don’t oversell. The availability trade-off is stated plainly [README][1].
• Runs without full root. setcap capabilities mean you don’t need to run as root — a meaningful security improvement over alternatives that require root [README].

Cons

• Linux-only. No exceptions. If your always-on host runs anything else, this doesn’t work [README].
• No Docker image. Manual binary deployment and capability management. More friction than most self-hosters expect in 2024 [README].
• Bot scans will wake your machines if anything you’re monitoring is internet-exposed. This is a fundamental limitation of the packet-interception approach, not a bug to be fixed [README].
• Manual registration required. Each managed machine needs a shutdown hook that fires the registration POST. There’s no autodiscovery or passive monitoring [README].
• IPv6 DAD race condition requires disabling a kernel safety feature on client machines. Small but real operational risk if you forget to do this on a new machine [README].
• 167 GitHub stars, single developer. No community to speak of beyond a r/homelab post. No issue tracker with significant activity visible. If this project goes unmaintained, you’re on your own [GitHub][1].
• No web UI, no dashboard, no monitoring. You manage it via JSON files and command-line flags. If something breaks silently, you may not know until someone complains a server didn’t wake up [README].
• No built-in scheduling. Can’t tell it “only wake machines between 8am and 10pm.” Every incoming packet is a potential wake trigger regardless of time [README].

---

Who should use this / who shouldn’t

Use Wakupator if:

• You have a home lab with servers you genuinely don’t need running 24/7 — game servers, media servers, NAS boxes you access occasionally.
• Your always-on host is already a Raspberry Pi or similar low-power device.
• You’re comfortable with Linux capabilities, systemd, and writing a simple shutdown script.
• Your managed machines are LAN-only or sit behind very aggressive firewall rules that block bot traffic before it hits your network.
• You want the absolute minimum footprint — no web interface, no database, no daemon that eats RAM.

Skip it if:

• Your servers are internet-exposed on common ports (80, 443, 22, 25) without upstream bot filtering. You will have unexpected wake-ups.
• You need a web UI to manage WoL from a browser or phone.
• You’re running Windows or macOS on your always-on host.
• You need scheduled wake-ups rather than traffic-triggered ones.
• You want something with a community, documentation depth, and long-term maintenance confidence. A 167-star solo project carries real longevity risk.
• You’ve never set up systemd service units or Linux capabilities before and don’t want to learn right now.

---

Alternatives worth considering

UpSnap — The most direct alternative for web-based WoL management. Browser interface, Docker deployment, scheduled wake-ups, ping monitoring, and per-device rules. Requires manual triggering (no automatic traffic detection) but far more polished UX. ~3,000+ GitHub stars vs Wakupator’s 167. For anyone who needs a dashboard rather than automatic packet detection, UpSnap is the better starting point.

wolweb — Minimal HTTP interface for sending WoL packets. Even simpler than UpSnap. No automatic detection, just a web endpoint you call manually. Good if all you need is a button.

etherwake / wol — Command-line WoL senders. Zero setup, but fully manual. No automation at all. Right tool if you just want to wake one machine occasionally from a script.

Proxmox VE — If your home lab is already virtualized on Proxmox, newer versions include WoL support for VMs. Not a drop-in replacement for what Wakupator does, but if you’re building infrastructure anyway, built-in features reduce the tool count.

Custom HAProxy + systemd approach — Some home lab operators use HAProxy as a always-on TCP proxy in front of sleeping backends, with a pre-connect hook that fires WoL. More complex to set up but gives you application-layer control that Wakupator lacks.

The honest comparison: Wakupator is the only tool in this list that wakes machines automatically on traffic detection without requiring any application-layer proxy. That’s its real differentiator. If you need that specific capability and you’re comfortable with the Linux setup, nothing else does it the same way. If you just want WoL with a friendly interface, UpSnap is the safer bet.

---

Bottom line

Wakupator solves a specific problem well: automatically waking LAN machines when traffic arrives, without touching your firewall or router config. The IP spoofing approach is genuinely clever, the MIT license is clean, and the energy savings math is real for anyone running home lab servers that sit idle most of the day. The trade-offs are also real — bot scans will trigger unexpected wake-ups on internet-exposed services, the setup requires Linux capability management and shutdown hook scripting, and you’re betting on a 167-star solo project for operational infrastructure. It’s the right tool for a home lab game server or occasional-use NAS behind a well-firewalled LAN. It’s the wrong tool if you need polished UX, Docker deployment, or reliable behavior on internet-facing ports.

---

Sources

1. gibus21250, r/homelab — “Introducing Wakupator: A Simple Service to Wake Up Your Machines Automaticaly and Save Energy!” https://www.reddit.com/r/homelab/comments/1fxmuwz/introducing_wakupator_a_simple_service_to_wake_up/
2. Track Awesome List — “Track Awesome Selfhosted (awesome-selfhosted/awesome-selfhosted) Updates Daily” https://www.trackawesomelist.com/awesome-selfhosted/awesome-selfhosted/
3. Track Awesome List — “Track Awesome Selfhosted (awesome-selfhosted/awesome-selfhosted) Updates Weekly” https://www.trackawesomelist.com/awesome-selfhosted/awesome-selfhosted/week/

Primary sources:

• GitHub repository and README: https://github.com/gibus21250/wakupator (167 stars, MIT license)