# SPR (spr-networks/super): a per-device WiFi password router you run yourself

> SPR builds a micro-segmented network where every device gets its own passphrase and its own /30 subnet. It is aimed at homelab and small-site operators who want zero-trust rules without a cloud controller.

**spr-networks/super** — One wifi password per device. Ad Blocking & Privacy Blocklists. Policy Based Network Access

- Repository: https://github.com/spr-networks/super
- Website: https://www.supernetworks.org/
- Stars: 867 · Forks: 68
- Language: JavaScript
- License: BSD-3-Clause
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/spr-networks-super

## The problem SPR solves: shared WiFi passwords and flat LANs

A single WiFi passphrase is a shared secret. Everyone who has it can join the same layer 2 network, see the same broadcast traffic, and reach every other device unless something else stops them. Guest networks split that into two buckets, which is not much better. SPR's answer, as the README puts it, is "One Password Per WiFi Device": each client gets its own passphrase, so revoking one device means changing one credential rather than re-keying the house. The README also lists policy based routing, isolation by default, and per-device DNS rules as core features. The intended audience is visible in the topics list (homelab, router, parental-control, self-hosted) and in the setup guides: Raspberry Pi 4/5, general Linux, and a virtual install for a personal VPN. This is for someone who treats the router as a server, not an appliance.

## How SPR identifies devices and assigns each one a /30 subnet

The README's How it Works section is short but specific. Device identity is established with a MAC address plus a per-device passphrase for WiFi, or a VPN public key for remote devices. From there, "each device gets its own /30 subnet to exist on." A /30 holds four addresses, two of which are usable, so the allocation is deliberately tiny: the device and the router, nothing else. Firewall rules block spoofing and impersonation, and routing rules redefine what each device can reach. That is the whole design in one paragraph, and it explains why the project ships so many top-level directories: dhcp, dns, wifid, wireguard, flowgather, packet_logs and superd are separate services rather than one monolithic daemon. The docker-compose.yml confirms this shape. Each service is its own container with its own image, and the base and watchdog containers run with network_mode: host and privileged: true. The trade-off is real: privilege is concentrated in the host-networked containers, and the README claims "almost no unmanaged code, minimized attack surfaces" as a goal rather than a guarantee.

## Installing SPR from prebuilt containers and adding a first device

The README gives two paths. Building from scratch is the slower one and uses a memory-backed filesystem, which the README warns can fail on memory-limited devices; the documented workaround is the build argument --set "*.args.USE_TMPFS=false". The prebuilt path is shorter:

```bash
docker-compose pull
./setup.sh # (optional)
docker-compose up -d
```

After that the services come up under Docker, with the base, watchdog, superd and other containers defined in docker-compose.yml. The README also points to setup guides for Raspberry Pi 4/5, general Linux, and a virtual install, and to an iOS app for the client side. Device onboarding itself is not scripted in the README; it happens through the UI, where you create a per-device passphrase and the device joins with it. Expect to read the Pi or general setup guide before the first boot, because the README does not document rollback or a recovery path if the host networking setup goes wrong.

## Where SPR is the wrong tool

The README does not document rollback, and the update path is a docker-compose pull plus a restart of host-networked, privileged containers. If your router is also your only path to the internet, a failed pull or a bad image tag leaves you without a network until you can attach a keyboard. The version pinning in docker-compose.yml defaults to ${RELEASE_VERSION:-latest}, so an unpinned deployment tracks whatever latest resolves to; the repository does include update-pins.sh and reproducible.env, which suggests the maintainers care about pinning, but the default compose file does not force it. Second, some features are explicitly gated. The README marks mesh with wired backhaul and policy based site forwarding with an asterisk and states that "Some features are part of SPR PLUS, a paid subscription to support the project." If those two items are the reason you are looking at SPR, the free path does not include them. Third, this is not a consumer mesh kit. Multi-WAN, Wireguard, DNS over HTTPS and per-device rules are all configuration you own.

## SPR compared with Pi-hole plus a stock router

The common homelab alternative is a Pi-hole or similar DNS sinkhole sitting behind a normal router. The difference is where policy lives. A DNS sinkhole filters names and nothing else: two devices on the same LAN still reach each other, and a device that ignores your DNS server bypasses the filter entirely. SPR puts the decision at the routing layer, where the README says each device sits on its own /30 and connectivity is redefined by routing rules. That means isolation and ad blocking come from the same box, and a client cannot opt out by changing its resolver. The cost is scope. A sinkhole is a small service you can run next to anything; SPR is the router, and the docker-compose.yml shows it taking network_mode: host and privileged access to do the job. If you only want DNS filtering and you are happy with your existing router, the sinkhole is the smaller commitment. If you want per-device passphrases and default isolation, the sinkhole cannot provide them.

## Maintenance, licensing and the upgrade cost

The repository is not archived, and the last push was on 2026-08-26, the same day as the clearfog-v1.2.6 release. Releases v1.2.5 and v1.2.4 both landed on 2026-08-17, so the recent cadence is close together rather than evenly spaced. Upgrades follow the same two commands as installation, and the compose file's image tags are parameterised by RELEASE_VERSION and RELEASE_CHANNEL, which is what makes pinning possible. The licence is BSD-3-Clause, a permissive licence that generally allows reuse and redistribution with the copyright notice retained; the repository ships a LICENSE file at the top level. The paid SPR PLUS subscription is a separate commercial arrangement for specific features, not a licence change, and nothing in the README describes what happens to those features if a subscription lapses. Treat that as an open question to resolve before you build a network around it.

## Conclusion

Adopt SPR if you already run Linux hardware and want isolation enforced at the router rather than at each client, and if you accept that the paid SPR PLUS tier gates site forwarding and mesh with wired backhaul. Skip it if you need a drop-in replacement for a consumer mesh kit or if you will not read the setup guides, because a router that carries every device's traffic is not a good place to improvise. Before committing, verify on your own hardware that the WiFi chipset supports the WPA3 multi-PSK mode, and read the release notes for the version you plan to pull.

## FAQ

### What is SPR (spr-networks/super)?

SPR stands for Secure Programmable Router. The README describes it as a way to create an adaptive, micro-segmented network for WiFi devices, remote VPN access and wired systems, with one WiFi password per device and per-device DNS rules.

### How do I install SPR?

The README gives two routes: build from scratch with ./build_docker_compose.sh --load followed by docker-compose up -d, or pull prebuilt containers with docker-compose pull, optionally run ./setup.sh, then docker-compose up -d. Setup guides exist for Raspberry Pi 4/5, general Linux and a virtual install.

### Does SPR need Docker?

The README lists interoperability as running on a wide variety of Linux systems with Docker, and the repository ships docker-compose.yml, docker-compose-virt.yml and docker-compose-kvm.yml. The documented install and update commands are docker-compose commands.

### Is every SPR feature free?

No. The README marks mesh with wired backhaul and policy based site forwarding with an asterisk and states that some features are part of SPR PLUS, a paid subscription to support the project.

### What licence does SPR use?

The repository lists BSD-3-Clause and includes a LICENSE file at the top level.

## Sources

- [License: BSD-3-Clause](https://github.com/spr-networks/super/blob/main/LICENSE)
- [Project website](https://www.supernetworks.org/)
- [README](https://github.com/spr-networks/super/blob/main/README.md)
- [Releases](https://github.com/spr-networks/super/releases)
- [spr-networks/super on GitHub](https://github.com/spr-networks/super)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spr-networks-super