NSL.SH and YunoHost: same goal, different philosophy

A question from the CHATONS community recently pushed us to write down how NSL.SH compares to YunoHost. It is a fair question, and it deserves an honest answer.

TL;DR

The philosophy first, because it explains our choices

Our priority is to make open source accessible to everyone, including people who will never touch a DNS config or open a port. Yundera and NSL.SH share that same objective, Yundera just pushes the idea further. That is our real difference with YunoHost, which aims for the state of the art of pure self-hosting. We accept trade-offs in favor of simplicity, and we try to be transparent and consistent about them.

So yes, NSL.SH is in some sense a YunoHost alternative: both want you to run your own apps on your own machine. But we optimize for different things, and that shows up in every concrete choice below.

The concrete differences

Apps run in containers

YunoHost packages apps directly on a Debian system, with its own packaging format maintained by the community. NSL.SH apps are standard Docker containers described by a compose file. Any containerized app can be brought in, isolation comes for free, and upgrades or removals do not leave traces on the host system. The trade-off: containers use somewhat more resources than native packages, and we depend on the upstream images.

Tunnel by default

YunoHost assumes your server is reachable: a public IP, ports 80 and 443 forwarded, DNS pointing at you. That works great when your ISP cooperates. NSL.SH assumes the opposite by default: your machine may be behind CGNAT, on a mobile connection, or on a network you do not control. When a direct route is possible, traffic flows directly. When it is not, a WireGuard tunnel makes the machine reachable anyway, with zero router configuration.

A domain and HTTPS by default

On YunoHost, the domain is your job: buy or obtain one, configure DNS, then let the system handle certificates. On NSL.SH, every machine gets a working subdomain out of the box ({sub}.{user}.nsl.sh) with HTTPS already enabled. Nothing to buy, nothing to configure, and you can still bring your own domain later if you want one.

SSO by default

Every app in the store sits behind single sign-on by default. An open-source sidecar (AppShield, using OIDC) fronts each app, so one account opens everything and no app is ever exposed unauthenticated to the Internet. Apps whose own login cannot be disabled keep it, but authentication is mandatory across the store: an app without it needs a written justification to be accepted.

Mail: a sender service by default vs a full mail server

This one deserves detail, because it is where the two philosophies diverge the most, and where a quick comparison would be unfair to both sides.

What NSL.SH gives you by default. Every machine ships with a mail sender service enabled out of the box. It authenticates against the nsl.sh server and lets you and your apps send email as *[email protected], matching your subdomain identity. Password resets, invitations, notifications: they just work, with zero SMTP configuration. Delivery is relayed through SendGrid, so deliverability is handled for you and your mail does not land in spam because of a home IP with a bad reputation. Today this is send-only; receiving on those same addresses is planned but not yet supported. And to be transparent about what that means: it is a relay, so outgoing mail transits our sender infrastructure and SendGrid. The default is convenience, not a self-hosted mailbox.

But a full mail server works on NSL.SH too. Since apps are standard containers, nothing stops you from running a complete mail stack on your machine and truly owning your inboxes. The prerequisites are then exactly the same as anywhere else: a custom domain, the mail DNS records (MX, SPF, DKIM, DMARC), an open port 25, and reverse DNS. The difference with YunoHost is not capability, it is what you get without asking: on NSL.SH the full mail server is an option you set up, on YunoHost it is the integrated default.

What YunoHost gives you. A genuinely full mail server, built in and tied to user accounts: Postfix for sending, Dovecot for receiving. You get real self-hosted mailboxes at [email protected], one per user account, with standard IMAP, SMTP and POP, so Thunderbird, K-9 or Apple Mail plug straight in, and you can add a webmail like Roundcube on the server. Aliases and forwards are configurable per user. See the YunoHost email documentation for the full picture.

What running your own mail server costs, on either system. The software side is done for you (YunoHost) or a container away (NSL.SH). The hard part is deliverability, which has three layers. First, DNS records: mail needs MX, SPF, DKIM and DMARC, and YunoHost generates the recommended configuration for you to apply. Second, port 25 must be open, and many residential ISPs block it outbound, which stops outgoing mail entirely. Third, reverse DNS (PTR): your public IP must resolve back to your mail domain, and this is configured at your ISP or VPS provider, not at your registrar. Without it, anti-spam filters will likely mark you as spam. This last one is the step people trip on most.

YunoHost's free subdomains (nohost.me, noho.st, ynh.fr) genuinely help with the first layer: DNS records, including the mail ones, are configured automatically. But the free domain does not solve port 25 or reverse DNS, because those are tied to your IP and your ISP, not to which domain you picked. Whether your outbound mail actually lands in real inboxes depends on your connection.

The honest summary. Both systems can host a real mail server, with the same network prerequisites. The difference is the default. YunoHost hands you the full server integrated with your user accounts, and delivery then depends on your connection. NSL.SH hands you outgoing mail that works immediately on any connection, including behind CGNAT, through a relay, and leaves the full mail server as an option for those who want it and have the network for it. Same trade-off as everything else in this post.

Focus on how easy the apps are to use

This is less a feature than a policy. An app is not "done" when it installs, it is done when a non-technical person can click it and use it: pre-authenticated launch, sane defaults, data that survives reinstalls, no reading logs to finish setup. Every app submission is reviewed against that bar. YunoHost has made enormous progress on usability too, but its center of gravity remains the self-hoster; ours is the person the self-hoster is helping.

what these choices cost

Transparency is part of the deal, so here is what we trade away.

The naming and verification layer (the control plane) is centralized: DNS resolution goes through our backend, which verifies each machine's signature before routing. That is the price of automatic domains and TLS. Your actual traffic (the data plane) is direct when your machine is reachable, and transits our infrastructure only in tunnel mode.

On TLS: with a managed nsl.sh subdomain, the connection is re-terminated at the edge, so the edge can see traffic in transit. The strictly end-to-end path is the direct sslip.io address, where TLS terminates on your machine and nothing in between decrypts. A well-configured YunoHost box with its own domain terminates TLS on your hardware, full stop, and on that specific point it is stronger.

What never changes, in every mode: your data at rest stays on your own machine. That is the property we consider non-negotiable, and it is the one both projects ultimately exist to defend.

Choosing between the two

If you want the state of the art of pure self-hosting and control over every layer including the network edge, YunoHost is excellent and we mean that sincerely. If you want the people around you to actually run their own apps, including the ones who will never open a router admin page, that is the problem NSL.SH exists to solve.