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 same primitive — grant one service to one peer, deny everything else — covers problems that usually need four different products. Nothing below opens a port, publishes a DNS name, or joins two networks together.
Remote support for an HMI, a PLC or an instrument normally means a jump host, a VPN account and a route into the OT segment. Here the vendor is granted exactly one service on one device, for as long as you say.
Two organizations, two controllers, no merged network. A federation code grants a single service across the boundary — and neither side learns anything about the other's topology, hosts or other services.
A hosted runner needs your private registry, a package proxy or a seeded database. The usual answers are a public endpoint behind a password, or a VPN credential sitting in CI secrets.
A GPU box running an inference server is the most sensitive thing to expose and the easiest to get wrong. Publish it as a service instead: it answers at a name on each teammate's own machine, and never on the internet.
SideServices also ships as ready-to-flash appliances — the whole mesh baked into a small, self-updating image. No server to run, no operating system to install or patch.
The easiest way to self-host an entire SideServices federation. Flash a Raspberry Pi, plug it in, and the controller, relay and your services come up as a single tiny image.
Built on the gokrazy appliance framework.
Put a SideServices appliance in front of an industrial machine or IoT device and expose only the specific services you choose — with no web traffic reaching the device by default.
The 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.
A service records who used it, how much moved and how long it took — per HTTP request and per TCP flow. The detail stays on the node that serves the service; only counts roll up to the controller. Request paths are stored without their query string, so an audit trail never becomes the leak.
A PLC, a camera, a printer, a lab instrument. Plug it into the IoT appliance’s protected port and it reaches its granted service with nothing installed and nothing configured — and it is still attributed individually by its own address.
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