A private mesh for your services — not a flat network you join. You run it all; we run nothing.
Enroll your devices into a federation. Grant one service to one peer. It answers on localhost — over a post-quantum WireGuard mesh you own end to end. No account, no control plane we run, no telemetry. Built on sidehub, one open binary for every OS.
No accounts to create. No servers to provision. Run the binary, mint a code, paste it on the next device.
Drop the single sidehub executable on the device you want as the controller and run it. It opens a setup page on localhost — choose Controller. No daemon to install, no config file to hand-edit, no kernel module.
In the controller’s dashboard, issue a one-time code bound to your federation. Hand it to whichever device should join — paste it, scan a QR, sneakernet it. Your call.
Run sidehub on the new device and paste the code in its setup page. It pairs with the controller, builds an encrypted tunnel to every hub, and exposes the federation’s services on localhost.
Two devices that can't reach each other directly — behind a home router, a firewall, a carrier NAT — meet through a relay. The relay only forwards encrypted frames and sealed invitations; it never sees your traffic, your keys, or even which services exist. Because it can't read anything, it doesn't have to be yours: use our open relay (free, on request), a partner's, or run your own. It's never part of what you have to trust.
A service is one thing you expose — a database, a web app, an SSH port, a SOCKS exit, even your mailbox. The controller grants it to specific peers, and it shows up on a local address on their machine. Nothing else on your network is visible — there's no subnet to scan, no flat address space to firewall.
Databases, SSH, Git, registries — anything on a port.
localhost:5432DNS, syslog, game servers, custom protocols.
localhost:5353Web apps and APIs answer at a name — no IP, no port to remember. Resolved on your own machine, never by public DNS.
wiki.home-lab.sideservices.localhostA proxy or exit on another node — route requests through where it sits.
localhost:1080A private IMAP + SMTP mailbox the controller hosts for your federation — opt-in, mesh-only.
imap + smtp on localhostThe controller is a small web app on your own machine. You see every service, who it's granted to, and what's denied — and any device sees just the services granted to it, reachable by name. Click a screenshot to enlarge.
sideservices.localhost — HTTP services open at service.federation.sideservices.localhost.
Cross-platform, self-hosted, deny-by-default, post-quantum. No public DNS, no public TLS, no public anything.
Controller, hub, relay, consumer — the same static sidehub executable, the same commands. Linux, macOS, Windows, Android, iOS, FreeBSD, OpenBSD. No separate management or signal servers to run.
You don’t join a flat network where everyone can see everyone. A service stays invisible until the controller grants it to a specific peer — and is revoked the same way.
TCP and UDP services bind to a stable local port. Web services answer at service.federation.sideservices.localhost — resolved by the binary, never by a public resolver.
Direct, encrypted hub-to-hub tunnels, with a relay fallback when a peer is behind NAT. Identities and key exchange are hybrid post-quantum (Ed25519 + ML-DSA, X25519 + ML-KEM) — harvest-now-decrypt-later doesn’t work here.
Hand another federation a code and it can consume one service of yours — scoped, revocable, deny-by-default. The two networks never merge, and neither side learns the other’s topology.
No sign-up, no vendor control plane, no telemetry. The only thing you have to trust is your own controller. The relay is untrusted — it can’t read your traffic, so it can be anyone’s (ours, a partner’s, your own). Your keys never leave your devices.
Same WireGuard primitive as a mesh VPN. A different idea of who's in charge — and what's reachable.
A vendor runs the control plane you have to trust. You sign up; your coordination lives in their cloud.
Your own controller is the only thing you trust — no account, no vendor in the loop. The relay is untrusted, so it can be ours, a partner's, or yours.
Every node gets a flat address, gated by network ACLs, plus a separate management or signal server to operate.
Deny-by-default at the service level, and federation across organizations. One binary is every role — nothing extra to run.
A global, open network anyone can join; you firewall on top.
Each federation is private and controller-signed — reachable only where you grant it.
A shared global relay for one-off shells through NAT.
A persistent, encrypted mesh on infrastructure you own, with structured, revocable service access.
Across all of them: end-to-end post-quantum identity and key exchange, and services that answer on localhost — no public DNS, no public CA.
Short version: one binary, a post-quantum WireGuard mesh, deny-by-default service access, and a localhost addressing trick. Everything stays on devices you own.
Request alpha access →The set of devices (hubs) you’ve enrolled together. One hub is the controller — it signs enrollment and holds the federation’s identity. Every other hub reaches the others directly over WireGuard, with a relay fallback for hubs behind NAT. There’s no central data plane and no shared address space — just the services you grant.
A mesh VPN drops every device onto one flat network and gates it with ACLs. SideServices is deny-by-default at the service level: a service is invisible until the controller grants it to a specific peer. The WireGuard transport is the same proven primitive — the access model isn’t.
Through localhost. TCP and UDP services bind to a stable local port. Web services answer at service.federation.sideservices.localhost, resolved by the binary itself against state the controller signed — never by a public resolver.
Because both already happen, privately, elsewhere in the stack. Traffic between hubs is encrypted by WireGuard; the few control channels use self-signed, fingerprint-pinned certificates and signed payloads, not the public PKI. Names resolve locally. Nothing about your services leaks to certificate-transparency logs or open resolvers.
Yes. Hand another federation a one-paste code and it can consume one specific service of yours — scoped and revocable, deny-by-default. The networks never merge, and the consuming side never learns your internal topology.
Yes, end to end. Identities are hybrid Ed25519 + ML-DSA-65 signatures; enrollment and key exchange are hybrid X25519 + ML-KEM-768. A future quantum computer that records today’s traffic still can’t read it or forge an identity.
Yes. Deploy it without a rendezvous and it’s consume-only: it imports services others share with it and reaches them outbound, but exposes nothing. Attach a rendezvous later (no redeploy) if you ever want it to host services of its own.
No — and that’s the point. The relay (the same binary, in its rendezvous role) only forwards encrypted frames and sealed invitations between devices that can’t connect directly. It can’t read your traffic, your keys, or your service map, so it’s never part of your trusted computing base. Use our open relay (free, available on request), a partner’s, or run your own — it makes no difference to your security.
No. No sign-up, no central control plane, no telemetry. The controller is a device you own running the same binary. Codes travel hub-to-hub by whatever means you choose.
SideServices is the network and the product; sidehub is the single open binary that runs every role — controller, hub, relay, or consumer. One executable, no runtime dependencies.
It’s in closed alpha right now, and free. Request access at info@sidephone.io. Public builds and source are coming soon.
SideServices (the sidehub binary) is in closed alpha — free, but builds and source aren't public yet. Want in? Email us and we'll get you set up.
one binary — every OS, every role · all builds coming soon