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

Who or what is actually behind a login, human or machine — the same underlying question either way, just with a different shape.

For a person, 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.

For a machine, there's no interactive login — an API or agent gets a credential scoped to only what that job needs, resolved from a credential manager rather than typed by anyone. 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. An AI agent with shell access sharpens that further, reading whatever's on disk and echoing it into a log without anyone intending it — centralised credential management stops being optional here.

This is about who or what gets in — see Credentials for how the credential behind that login is actually stored and handled, human and machine alike.

Scope and 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.

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 Backups for the fuller treatment — the three problems any backup design has to solve, and the layers built on top of that.