๐ Network & outbound traffic
A "no cloud" product that quietly phones home isn't one. This is what NoCloudMe 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 Mac 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 doctor diagnostic console shows outbound sessions, blocked attempts and how long they lasted โ 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 NoCloudMe'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