I'm rebuilding my digital life — with an AI agent

Two days ago I sat in front of a factory-fresh notebook. A clean Arch Linux install, an empty home directory, no legacy baggage. That classic moment when you swear to yourself: this time I’ll do everything right.

I’ve sworn that before. What’s different this time: I’m not building alone — and I don’t build anything without writing down why.

The experiment

I gave myself two rules:

1. Every load-bearing decision gets written down — as an Architecture Decision Record, ADR for short. The format comes from software engineering and goes back to Michael Nygard’s 2011 article. Nothing complicated: one short document per decision — context, decision, rationale, consequences, including the alternatives it did not become.
2. An AI agent is my cockpit. I don’t work with chat windows and copy-paste, but with an agent in the terminal that reads and writes files, configures servers, maintains documentation — and remembers from session to session what we’re working on, through persistent memory.

The goal behind this is bigger than a tidy notebook: getting out of services I don’t own. The password manager without Linux support, the mailbox on Exchange, the photos on Google — replaced piece by piece with services on my own server. Own your stack — hence the name of this series.

What happened in 48 hours

Twelve ADRs were written in the first two days:

A selection:

• Organization: the home directory follows the PARA method (Projects, Areas, Resources, Archive). Sounds trivial, but it’s the foundation for an agent — and for me — to find things again.
• Passwords: Vaultwarden on my own VPS at an EU provider instead of a US cloud subscription. The old manager stays as a bridge until the migration is verified. (For my own setup, EU data sovereignty is enough — customer systems we run in Switzerland when the customer requires it. They usually do, rightly so.)
• Secrets: two classes with two homes — interactive credentials go to the password manager, automation tokens go encrypted into the Git repo (sops + age).
• Access: a WireGuard VPN with an internal service zone, central SSO with Authentik and LLDAP, passkeys instead of SMS codes — on Linux, too.
• Git: a lightweight self-hosted Forgejo instance instead of GitLab cloud.

This is the target architecture — one notebook, one VPS, a clear split between public and VPN-only. Public is only what has to be reachable on the go without a VPN (password access, login, Git for CI); admin interfaces simply don’t exist outside the VPN. And backups aren’t a web service at all: they run encrypted, off-site.

Each of these decisions has a document listing the alternatives it did not become — and why. That part is already paying off: when I ask in six months “why no Tailscale again?”, the answer is in the repo.

The honest part

Not everything went smoothly, and that’s the point of this series. The example that gave me the most to think about: the first version of the “internal zone” — admin interfaces that were supposed to be reachable only inside the VPN — had a hole. The IP filter in the reverse proxy was useless, because Docker replaces the client address with its own bridge address (documented behaviour — you just have to know it). The internal zone was publicly reachable. We only found it because the process demands testing your own blocks from the outside, against yourself. The details deserve a post of their own.

The lesson is a process lesson, not a tool lesson: an AI agent builds as much infrastructure in an hour as I used to build in a weekend. That’s exactly why the counterweight is needed — documented decisions, runbooks, tests against your own security assumptions. Speed without a review process isn’t productivity; it’s deferred damage.

Three rules crystallized along the way:

1. No data loss, ever. An old service is only cancelled once the export is verified and the replacement is in production — backups follow the 3-2-1 rule.
2. Scripts are the executable truth. Anything covered by a setup script is never changed by hand on the server again — adjust the script first, then run it.
3. Every session ends with a commit. Documentation that isn’t in the repo doesn’t exist.

Why public?

Because this is exactly our business. At AnalytikData we build Coautra, an audit-proof development process for AI speed — and this series is the same standard applied to our own infrastructure: honest field reports instead of polished demos. What works, what breaks, and the reasoning behind it.

Next up is the biggest construction site: migrating mail away from Exchange and Google Workspace — the moment “own your stack” gets serious. And the Docker network hole gets its own post.

Questions, objections, war stories of your own? Write me — I answer personally.