How It Works
Yundera combines a local app runtime on your machine with a mesh network (NSL.SH) that makes your apps reachable from anywhere.
The two planes
The system separates into two distinct layers:
Control plane — naming and verification
When someone visits app.yourname.nsl.sh:
- DNS resolves the domain to the NSL.SH network.
- The mesh-router backend verifies the request cryptographically (libp2p signature).
- The request is routed to your PCS, where the local mesh-router resolves which app container should handle it.
This control plane always goes through NSL.SH infrastructure — it's what gives you automatic domains and TLS with zero configuration.
Data plane — your app traffic
The actual traffic to your app (the data plane) takes one of two paths:
| Your network | Traffic path | End-to-end encrypted? |
|---|---|---|
| Directly reachable (public IP, ports open) | Traffic goes directly to your PCS | Yes — nothing in between decrypts |
| Behind CGNAT (no public IP, no port-forwarding) | Traffic goes through an encrypted WireGuard tunnel via NSL.SH | Encrypted in transit; the tunnel endpoint sees traffic |
In both cases, your data at rest stays on your machine.
What happens when you install an app
- You click "Install" in the dashboard.
- The PCS pulls the Docker image and creates the container.
- A domain is assigned automatically:
{appname}-{yourname}.nsl.sh. - A TLS certificate is provisioned.
- If the app uses AppShield (the SSO sidecar), it registers with the PCS authentication system — you're logged in automatically.
- The app is live and accessible from anywhere.
No DNS records to create. No certificates to manage. No port-forwarding rules to configure.
Domain shape
Every Yundera domain follows the pattern:
{subdomain}.{user-domain}.{server-domain}
For example: immich.john.nsl.sh — where immich is the app, john is the user, and nsl.sh is the server domain.
For more on how domains, TLS, and routing work, see Domain & Routing.