Skip to main content

Security

Introduction​

Security is about regulating access: if your data is locked in a safe on the ocean floor, it's secure but useless. The goal is that the right people can access the right data — and everyone else cannot.

Who counts as "the right people" isn't a technical question, though — it's decided by the same self-organising, democratic process everything else here is, not by whoever configured the firewall. And security that gets in the way of experimentation isn't doing its job: locking a system down so tightly that nobody can try anything new is just a slower way of losing to the same problem it was meant to prevent.

Security concerns apply at every layer of the stack. At the infrastructure level, networks can be attacked with increasingly sophisticated methods. At the OS and application level, code errors can be exploited to gain unauthorised access or control. Cyber-security is an ongoing game of cat and mouse — and self-hosters are not exempt from it.

Concerns​

Running your own infrastructure means taking responsibility for security at every layer.

Modularisation​

Services run in separate containers, and infrastructure can be split across separate instances, so a compromised or failing node doesn't take the rest down with it. The assumption isn't that you'll never get hacked — some vulnerability eventually gets through — it's that when it does, the damage stays contained at the infrastructure level instead of spreading everywhere.

Data minimisation​

Retention is kept to a minimum: what isn't stored can't be handed over or leaked in the first place, and members aren't tracked beyond what a service requires to function. Tools like Etherpad get retention timers, so documents holding sensitive information don't just sit around indefinitely once nobody needs them anymore. Where modularisation contains damage at the infrastructure level, this contains it at the data level — there's simply less to lose.

Authentication​

Logging into a service — the biggest risk is always the user, not the infrastructure: weak passwords, reused credentials, phishing. A well-configured, self-hosted identity provider deals with that directly: SSO means one login worth actually securing well — a passkey, MFA, the works — rather than a different, probably weaker one for every service. One place to enforce that, and one place to revoke access when something goes wrong.

Roles​

Access is broader than any one mechanism — the real question is what someone has actually committed to, not a fixed label. Access should track that commitment:

  • Committed to the infrastructure itself needs the heaviest access there is — shell — but heaviest still means the least that job actually requires, not a blank check.
  • Committed to one service gets access scoped to that service, not the whole platform.
  • Administrating a service gets access to that app's own admin panel — an admin login to WordPress, say — with whatever rights the job actually needs, not the server behind it.

Treating every layer as if it needed the heaviest tier just trains people to route around the friction instead of respecting it.

Machine access​

Not everything connecting to the stack is a person. An API or agent doesn't log in interactively and hold its own key the way a human developer does — it's handed a credential scoped to only what that job needs, resolved from a credential manager rather than typed by anyone. Same underlying question as human access, but the concern shifts from identity and judgement to scope and containment: treating a service account like a person's login is how it ends up with the same blast radius as a compromised admin.

AI agents sharpen that further. One with shell access reads whatever's on disk, credentials included, and can echo them straight into a log or chat transcript without anyone intending it. It mostly goes fine, which is exactly what makes the discipline easy to skip. Centralised credential management stops being optional here — an agent can't leak a flat-file .env it's never given a path to.

Recovery​

Everything above is prevention and containment — keeping the wrong people out, and limiting the damage when they get in anyway. Backups are a different mode entirely: not preventing failure, but surviving it once it's already happened. The risk isn't always someone getting in — it's losing the data entirely: a failed disk, a bad update, a mistake. Regular, tested backups are a security feature as much as an operational one; data that only exists in one place isn't secure, no matter how well that one place is locked down.

See Processes → Maintenance → Backups for the fuller treatment — the 3-2-1 rule, why a snapshot isn't a backup, and the layers this actually splits into.