SPR (Secure Programmable Router): Per-Device WiFi Passphrases and Containerised Policy Routing
One wifi password per device. Ad Blocking & Privacy Blocklists. Policy Based Network Access
At a glance
- What is it?
- SPR is a self-hosted router stack that gives every WiFi device its own passphrase and its own /30 subnet, then applies nftables policy between them. It is aimed at homelabs and small networks that want device-level isolation without buying into a proprietary mesh.
- Who is it for?
- Adopt SPR if you run a homelab or small network and you specifically want per-device WiFi passphrases with default-deny isolation between devices, and you are willing to read the API docs rather than expect a complete written manual. Do not adopt it if you need a vendor support contract, if your hardware is not covered by the setup guides, or if you only want ad blocking, where Pi-hole or AdGuard Home are far less work.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 20 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem SPR solves: shared WiFi passwords destroy device identity
On a normal home or small-office network, every device that knows the WiFi password is the same device as far as the router is concerned. There is one pre-shared key, one broadcast domain, and any firewall rule you write has to be keyed on an IP address that DHCP may hand to someone else tomorrow. SPR's answer is to make the WiFi credential itself the identity. The README states the project provides one password per WiFi device, and the How it Works section explains that an unspoofable device identity is established with a MAC address and per-device passphrase for WiFi, or a VPN public key for remote devices. That identity is what the firewall and DNS layers act on. The target user is the homelab operator or small network admin who wants the isolation properties of a corporate zero-trust setup without a controller, a licence portal and a subscription. SPR is not trying to be a consumer mesh kit. It is a router operating system delivered as a set of containers, and the README's own goal list puts security and privacy first, programmability through an API second, and ease of use third. That ordering is honest about what you are buying.
One passphrase, one /30: how device identity becomes policy
The mechanism described in the README is short but specific. Each device gets its own /30 subnet to exist on. A /30 holds four addresses, of which two are usable for hosts, so the allocation is deliberately tiny: the device and the router, nothing else. Combined with strict firewall rules that block network spoofing and impersonation, this means a compromised device cannot simply claim a neighbour's address and inherit its rules, because the address it would claim belongs to a different subnet with a different policy attached. Connectivity between devices and to the internet is then redefined by routing rules rather than by broadcast reachability. The README describes this as isolation by default, with bidirectional groups and unidirectional service rules available when you want two devices to talk. The supporting components named in the repository topics are coredns for DNS and nftables for the packet filter, with WireGuard for remote access. The DNS layer is per-device as well: the feature table lists per-device DNS rules and overrides, DNS ad block lists, DNS over HTTPS for remote queries, and DNS rebinding protection. Observability is part of the same pipeline, with traffic insights by country and ASN, uplink health monitoring, alerts, DNS logs, and an event system with a database. The README also points at a separate repository, sprbus-json, for the bus events that the UI and plugins consume.
Getting it running: docker-compose, build script, and the tmpfs trap
The README gives two installation paths. To build from scratch, run ./build_docker_compose.sh --load followed by docker-compose up -d. To use prebuilt containers, run docker-compose pull, optionally ./setup.sh, then docker-compose up -d. There is no package manager step and no kernel module compilation documented in the README itself. The one operational detail the README does flag is worth reading twice: for performance and to minimise wear on SD cards, the build uses a memory-backed filesystem, and on memory-limited devices this can cause build failures if memory is exhausted. The documented escape hatch is to pass --set "*.args.USE_TMPFS=false" to the build script. If you are building on a Raspberry Pi with 2GB or 4GB of RAM, that flag is the first thing to try when the build dies partway through. Platform coverage in the README is limited to links: a Raspberry Pi 4/5 setup guide, a general setup guide, and a virtual setup guide for a personal VPN, all hosted on supernetworks.org. The README does not enumerate supported network cards or confirm which WiFi drivers expose the multi-PSK capability, so hardware validation has to come from those guides. An iOS app is listed as available, and a browser demo is linked at demo.supernetworks.org.
Where the documentation is thin, and what that costs you
The README is a feature table and a set of links, not an operator manual. Configuration keys are not listed. The API is referenced through a documentation site rather than described here. The FAQ lives on the website. For a project whose stated second goal is being programmable with an API, the repository front page tells you almost nothing about what the API surface looks like or how stable it is between releases. The release cadence visible in the supplied material is rapid: v1.2.4 and v1.2.5 both landed on 2026-08-17, and clearfog-v1.2.6 followed on 2026-08-26. Frequent point releases are normal for an actively developed router stack, but they also mean that anything you script against the API is a moving target unless you pin a tag. The second documentation gap is commercial rather than technical. The README marks mesh with wired backhaul and policy based site forwarding with an asterisk, and the footnote says some features are part of SPR PLUS, a paid subscription to support the project. Which features sit behind that line is not specified on the repository page. If mesh or site forwarding is why you are interested, that is the first question to resolve before you install anything. A third gap: the README claims almost no unmanaged code and minimised attack surfaces, which is a design intention rather than something a reader can verify from the repository listing. Treat it as a stated goal, not a measured property.
SPR versus OPNsense and OpenWrt: different answers to the same question
The obvious alternatives are OPNsense and OpenWrt, and the difference is not feature count. OPNsense is a FreeBSD-based firewall distribution with a long-lived configuration model, a large plugin ecosystem, and documentation that covers most settings in prose. It assumes you already have a WiFi access point, or that you will run one separately, and it identifies clients by IP, MAC or certificate rather than by WiFi credential. OpenWrt runs on the router itself, is extremely broad in hardware support, and gives you a shell where you configure hostapd and nftables directly. SPR's distinguishing move is the multi-PSK WiFi credential as the unit of identity, plus the per-device /30, plus a container-based architecture where each service is a Docker image. If you want ad blocking and nothing else, Pi-hole or AdGuard Home are a fraction of the setup effort and run happily alongside whatever router you already own. If you want a firewall with a decade of documented behaviour and a stable GUI, OPNsense is the lower-risk choice. SPR is for the case where the WiFi credential itself needs to be the identity, and where you are comfortable with a Docker Compose stack and a JSON event bus as your operational surface.
Maintenance, upgrades and the BSD-3-Clause licence
The code is BSD-3-Clause, which is a permissive licence: it allows use, modification and redistribution, including in closed products, provided the copyright notice and licence text are retained. It does not impose a copyleft obligation on your own configuration or plugins. None of that is legal advice, and if you plan to redistribute SPR or ship it inside a product, read the LICENSE file in the repository and talk to a lawyer. The practical maintenance question is different. Upgrades go through Docker images, so the update path is docker-compose pull followed by docker-compose up -d for the prebuilt route, or a rebuild with ./build_docker_compose.sh --load. There is no documented in-place upgrade path for the underlying host beyond the setup guides. Because the project ships point releases frequently, you should decide deliberately whether to track latest or pin a tag, since the API plugin system and the event bus schema are the parts most likely to shift. The paid SPR PLUS tier is the other ongoing cost, and it is framed in the README as supporting the project rather than as a support contract. If you need someone to call when the uplink fails at 2am, this is not that product.
Who should install SPR, and what to check first
SPR fits a specific operator: someone running a homelab or a small network who wants device-level isolation as the default state, who is willing to treat the router as a Docker host, and who values per-device DNS rules and ad block lists as part of the same policy engine rather than as a bolt-on. The iOS app and the React UI mean it is not purely a shell project, but the README's own goal ordering tells you where the effort went. It is the wrong tool if you need vendor support, if you want a single WiFi password shared across a household and no further complexity, or if your hardware is not on the supported list. Before you commit, verify the multi-PSK support of your access point and driver, confirm which features are gated behind SPR PLUS, and test the build on your actual device with USE_TMPFS=false if memory is tight. The demo at demo.supernetworks.org is the cheapest way to see the UI before you spend an evening on the build.
Editorial conclusion
Adopt SPR if you run a homelab or small network and you specifically want per-device WiFi passphrases with default-deny isolation between devices, and you are willing to read the API docs rather than expect a complete written manual. Do not adopt it if you need a vendor support contract, if your hardware is not covered by the setup guides, or if you only want ad blocking, where Pi-hole or AdGuard Home are far less work. Before committing, verify three things: that your access point and driver combination supports the multi-PSK configuration SPR relies on, whether the mesh, site forwarding and other starred features fall under the SPR PLUS subscription, and that you can build the Docker images on your target device with the memory-backed filesystem or with USE_TMPFS set to false.
Community notes