Self-Hosting Aegis Core: Setup, Modes, and Tradeoffs
Run your own dead man's switch. Docker setup for Aegis Core, the release modes it ships with, and the one tradeoff every self-hoster has to weigh.
A dead man's switch is the one category of software where "it runs on my machine" cuts both ways. Self-hosting means no third party holds your instructions. It also means the machine that must deliver your message is the same machine that goes dark when your house floods. This guide sets up Aegis Core, then walks that tradeoff properly, because choosing a release mode is the real decision.
Aegis Core is the open-source engine underneath the hosted Aegis DMS service: AGPL-3.0 licensed, self-hostable, and auditable at github.com/enegence/aegis
Two things it is not, stated up front. It is not a password manager. Estate data is encrypted at rest, but the key-management doc is explicit that the server holds the keys and there are no zero-knowledge claims. And it is not a legal instrument. Aegis delivers information; legal authority over your estate still comes from a will and an executor.
Setup
You need Docker with Compose, and a box that stays on. A Raspberry-class home server, a NAS that runs containers, or a small VPS all work.
git clone https://github.com/enegence/aegis.git
cd aegis
# Generates secrets and writes .env interactively
./setup.sh
# Start
./start.sh
# Open
http://localhost:8000
setup.sh generates the two secrets that matter: a session secret and a field encryption key. If you prefer to set them by hand, openssl rand -hex 64 and openssl rand -hex 32 respectively, in .env. The first visit prompts you to create the owner account. Everything else, including notification providers, storage, and optional TOTP two-factor, is configured from Settings afterward.
One habit to adopt on day one: back up .env and your database together. The database is useless without the field encryption key, and the key is useless without the database. The repo's docs/backups.md has the full procedure, including a hot-backup command that runs while the service is up.
The release modes, and what each one trusts
This is the section to read slowly. Aegis Core ships four release modes, and they differ in exactly one dimension: what still works when your host does not.
Vault (the default): everything on local disk, release executed by this host. If the host is offline when the switch should trip, nothing releases. The repo's own release-modes doc says this plainly, and so should every self-hoster running it.
Packet Mirror: adds an S3-compatible copy of the encrypted release packet. Your data now survives host loss, but release execution still needs the host for the key.
Relay Monitoring: connects Core to Aegis Relay, the hosted monitoring service. Relay watches your host and alerts. Release still runs on your host, so this raises your chance of noticing a problem, not your chance of delivering without one.
Relay Escrow: the Relay can execute the release if your host is gone. This is the only mode where a third party holds keys, and it is the only self-hosted mode with high resilience to server loss. That is the trade, stated in one line.
A fifth option exists and it is not a Core mode. Hosted is the fully managed Aegis DMS service, and the repo's docs are explicit that hosted mode is not available in the self-hosted open-source build. Core, the engine you just installed, is the open-source part. The hosted service built around it is a separate, managed product.
The right choice follows from one question: which failure worries you more, a third party seeing metadata about your arrangements, or your message not arriving because a power supply died the same month you did? Pure self-hosters should run Vault or Packet Mirror with monitoring they trust and a second pair of eyes on the box. People whose priority is that delivery happens should look at Escrow, or at the hosted service.
Security posture, verified against the repo
From the documented model: field-level AES-256-GCM encryption at rest, Argon2id password hashing, CSRF protection, HttpOnly cookies, optional TOTP, and an audit log of owner and claim actions. The key-management doc is candid about the limit of that: everything depends on the field encryption key living in an environment variable, so a host compromise that reads env vars decrypts everything.
The threat model and key-management docs are in the repo, at docs/threat-model.md and docs/key-management.md. Read them before you store anything real. Alpha software holding your most sensitive instructions deserves the same skepticism you would apply to anyone else's alpha, and being able to read the code is what makes that skepticism actionable rather than a feeling.
Set a check-in cadence you will actually keep. Add at least two trusted contacts on different channels. Then test the whole path once: trip a dummy switch and watch the claim flow end to end. A dead man's switch you have never tested is a hope, not a system.
Related reading: why verifiability matters in a dead man's switch trusted-contact cascades where a digital will ends and a switch begins
Keep reading
MORE FROM THE FIELD NOTES