Skip to content

🌐 Network & outbound traffic

A "no cloud" product that quietly phones home isn't one. This is what NoCloud is allowed to send out, and how that's enforced rather than promised.

Default deny, with declared exceptions

The old state was all-or-nothing: outbound access was either fully blocked (App Store apps) or fully open (everything else). A script that needed exactly one legitimate destination had no way to say so, so it ran either sandboxed and broken, or unwrapped and able to reach anywhere.

Now the default is deny, and the handful of things that genuinely need to leave your LAN declare it up front:

  • Apps declare their network needs in their manifest, the same way they declare which database tables they may read or write — visible before you install, not discovered afterwards. See The Store.
  • Anything not declared simply can't get out.

The appliance never calls the outside world

The home server used to pull code from GitHub itself — a real outbound connection from the very box being locked down.

That's inverted now: your workstation pushes to the home server over your own LAN/SSH. The workstation already talks to GitHub for your development work; the appliance no longer needs to talk to GitHub at all. One less thing that reaches the internet, and one less thing that can be reached.

You can see it

Blocking without visibility is just hoping. The security panel's Traffic and Firewall tabs show live outbound connections and a count of recently blocked attempts per destination — so an app quietly trying to reach somewhere it shouldn't is something you notice, not something you assume isn't happening.

What this is not

  • It isn't a firewall for your browsing — it governs what NoCloud's own pieces may send.
  • Reaching your data from outside is a different perimeter: LAN or WireGuard VPN, plus SSO. See Security & privacy.
  • Some pieces are still being brought under it (containers, scheduled refreshes); the tracked backlog is honest about which, rather than claiming a lockdown that isn't finished.

See also: Security & privacy · The Store · Platform

Reaching home from outside: WireGuard, and only WireGuard

NoCloud never serves your web to the internet. Your DNS records can point at private LAN addresses; nothing listens on a public 80/443. Away from home, your devices open a WireGuard tunnel to your server and then use everything exactly as if you were on the sofa.

On your router, forward one single UDP port (default 51820) to the server — and nothing else. If a guide ever tells you to forward 80/443 "so the web works from outside", that guide is describing a different product.

Add or remove devices on the server:

sudo nocloud-core/scripts/wg_client.sh add phone     # prints the config + a QR to scan
sudo nocloud-core/scripts/wg_client.sh list
sudo nocloud-core/scripts/wg_client.sh remove phone

Set WG_ENDPOINT in config/site.env first (what devices dial from outside: a dynamic-DNS name or your public IP, plus the port). The tunnel's server keys and every client config are harvested into nocloud-private — a wiped server gets its tunnel back on the next deploy, and every device keeps working.

Certificates for any situation

TLS is configured by two site.env keys — set in the install wizard, changeable any time in Settings → Network:

ACME_MODE What happens
dns (recommended) Let's Encrypt via your DNS provider's API (DNS-01). Works with zero public exposure — fits the WireGuard-only model. Set DNS_PROVIDER to your acme.sh hook name (hcloud, cf, …) and put its credentials in secrets/dns_env (KEY=value lines). Any of acme.sh's ~150 providers works; custom hooks go in nocloud-private/acme_hooks/.
http Let's Encrypt HTTP-01 webroot. Only for setups that already, deliberately, run a public server.
manual Bring your own: drop the full chain at tls/cert.pem and the key at tls/key.pem (corporate CA, self-signed, whatever). Nothing is issued or renewed for you; the health panel warns three weeks before expiry.

Issuance and renewal run on the server (scripts/cert_issue.sh, the acme-renew@ timer); credentials never appear in code or in the public repo.