MakerFLOSS/slides/tappaas/one-year-in/index.md

marp	theme	class	paginate	title	description
true	gaia	invert	true	TAPPaaS one year in — The Good, the Bad, and the Ugly	Sommerhack 2026, Taler Teltet — 27 August, 15:30

TAPPaaS — one year in

The Good, the Bad, and the Ugly

Lars Rossen · Sommerhack 2026 · Taler Teltet 27 August, 15:30

---

Last year, in this tent, I pitched a dream

Everyone needs a cloud in their basement. A Trusted, Automated, fully Private Platform as a Service.

On commodity hardware:

• your data, your hardware
• no hidden fees
• no reliance on closed source
• no reliance on the Internet

A year later I am back with the messy proof that it is real — and to make the case that you should build one too.

---

The receipts, up front

First commit	10 May 2025 — "Initial commit"
Commits when I submitted this abstract	1,091
Commits standing here today	1,507
Contributors	3 (I am ~77% of it)
ADRs written	24
Modules — 8 foundation · 12 apps · 21 community	41
Lines of code (bash · TypeScript · Python · Nix)	126,699
Of which test code	34,490 — 27%
Lines of documentation	~39,500

Everything in this talk is in two public repositories. You can check my homework.

---

What I am actually going to do to you

1. The Good — it runs. Here is what "it runs" means, and one surprise.
2. The Bad — what it really costs, and why that only works if it is shared.
3. The Ugly — the confession. I gave an AI root on every node.
4. Your turn — why you should build one, and how to start small.

I am not selling anything. There is nothing to buy.

---

The Good

It runs.

---

The iron: three boxes, a switch, an AP and a modem

flowchart TB
  n1["<b>tappaas1</b> — ASUS · EPYC 4464P<br/>12c/24t · 64 GB ECC<br/>tanka1 2×4 TB NVMe <b>mirror</b><br/>tankb1 12 TB HDD"]
  n2["<b>tappaas2</b> — Minisforum MS-S1 MAX<br/>Ryzen AI MAX+ 395 · 16c/32t<br/><b>128 GB unified</b> · Radeon 8060S<br/>tanka1 2 TB NVMe"]
  n3["<b>tappaas3</b> — TianBei WTR PRO<br/>Ryzen 7 5825U · 8c/16t · 32 GB<br/>tanka1 1 TB NVMe<br/>tankc1 5 TB HDD — PBS"]
  sw["<b>UniFi USW Pro XG 10 PoE</b><br/>10.0.0.201<br/>trunk: mgmt untagged +<br/>VLAN 200 310 410 420 430 510 610"]
  ap["UniFi Nano HD<br/>access point · port 9"]
  modem["ISP modem<br/>port 5 · VLAN 100 = wan"]
  n1 -- "10G · p12" --> sw
  n2 -- "10G · p2" --> sw
  n3 -- "2.5G · p3" --> sw
  sw --- ap
  sw --- modem

---

The software: foundation underneath, stacks on top

---

I promised you eight. There are forty-one.

Where	#	What is in there
Foundation — TAPPaaS repo	8	cluster network templates tappaas-cicd identity backup logging satellite
Apps — TAPPaaS repo	12	nextcloud euro-office vaultwarden litellm openwebui vllm-amd hass deconz coturn nextcloud-hpb netbird-client windows-server
Community repo — other people	21	immich jellyfin wordpress forgejo mailserver hosting sonos hue synology reolink solaredge alfen unifi shelly-fleet …

Twenty-one of those forty-one are not mine. Erik wrote 13, Andreas 6.

That is the number I did not dare put in the abstract.

---

"It runs" is a bigger claim than it sounds

Every one of those services, without me:

• updates itself on a schedule — and the update is gated by a test
• backs itself up nightly to Proxmox Backup Server, and off-site
• reports its own health, so I find out before my family does
• has a certificate that renews
• has one login — my identity provider, not eight password fields

The interesting engineering is not installing Nextcloud. It is Nextcloud still being there, patched, in eighteen months, unattended.

---

One idea does all the work: everything is a module

nextcloud/
├── nextcloud.json  # the contract — what it is, needs, provides
├── nextcloud.nix   # the NixOS machine
├── install.sh      # put it there            (once)
├── update.sh       # keep it patched         (on schedule)
├── test.sh         # prove it still works    (gates the update)
└── README.md

The firewall is a module. The backup server is a module. The mothership that installs the modules is a module.

One model to learn, not eight.

---

dependsOn — the trick the whole thing rests on

{
  "description": "Nextcloud — files, calendar, contacts",
  "vmname": "nextcloud", "vmid": 210,
  "dependsOn": ["cluster:vm", "templates:nixos", "backup:vm",
                "network:proxy", "identity:identity"],
  "config": {
    "cluster:vm": { "cores": 4, "memory": "8192", "diskSize": "64G" },
    "network:proxy": { "proxyPort": 443 }
  }
}

Install order is computed from these declarations. Nobody maintains a list. Add a module, and the platform works out that it needs a VM, an OS, a VLAN, a certificate, a login and a backup job — in that order.

---

Reduce flexibility. On purpose.

A key design goal is to REDUCE flexibility. There is value in decisions having been taken up front.

Some use cases will not fit TAPPaaS. That is the trade. For what fits, it is dramatically easier.

Zones, VLANs, naming, storage roles, backup policy, identity model — decided. You get to pick the applications, and where they live.

---

The surprise

My basement grew a brain.

---

Local AI. Private, offline, mine.

Silicon	AMD Ryzen AI MAX+ 395 — Radeon 8060S (Strix Halo)
Memory	128 GB unified — the GPU sees nearly all of it
Largest model tested	gpt-oss-120b — 120B parameters
Speed	~50 tok/s at 7B FP16 · ~20 tok/s at 30B 4-bit
API	OpenAI-compatible, on my own VLAN
Data leaving the building	none

One commodity box. Not a rack, not a hyperscaler, not a monthly bill.

---

The demo I have been waiting a year to do

Pull the cable out.

Then ask it something.

---

Why this is the point, not a party trick

Sovereignty is not a checkbox you tick at a vendor.

• The model runs on hardware you own
• Your documents are indexed on your VLAN
• Nobody re-prices it, deprecates it, or reads it
• It works when the fibre is cut, the account is suspended, or the terms of service change on a Tuesday

litellm in front means apps ask for "a model" — local today, someone else's tomorrow, your choice, revocable.

---

The Bad

What it actually cost.

---

The quiet months are the honest part

September–October 2025: 15 commits in two months.

TODO: what actually happened here — say it plainly, it is the most relatable slide in the deck

The lesson I take from it: a self-hosted platform that needs you every week is not a platform, it is a pet.

Those two months are the real test. The services stayed up. Because updates, backups and tests do not need me to be enthusiastic.

---

June 2026: 351 commits. Something changed.

That is not me getting three times better at typing.

That is the month I leaned all the way into AI-assisted development — which is exactly the confession in part three.

Hold that thought.

---

The iceberg under every "simple" service

	Files	Lines
Foundation — the platform	575	114,138
Apps — the things you actually use	144	15,726

For every line in an app module, there are seven lines of platform underneath.

tappaas-cicd alone — the mothership — is 81,942 lines, 72% of the foundation. Inside it: 8 TypeScript managers (36,920 lines) and the controller layer that talks to Proxmox, OPNsense and the switch (29,352).

---

It is a lot of work. That is the argument for sharing it.

Building this was not cheap, and I will not pretend otherwise: 112,000 lines, 1,507 commits, 24 ADRs, six unfamiliar stacks, a year of evenings.

But look at where that cost sits:

Paid once, by whoever writes it	Paid by you, per site
the 8 foundation modules	a box and an afternoon
145 test suites that gate every update	module-manager module add <app>
every install, update and repair script	nothing — patches arrive tested

A hyperscaler amortises a datacentre across a million tenants. We amortise a platform across a thousand basements.

Erik's 13 modules and Andreas's 6 cost me nothing and made my system better. Yours would too. That is the economic case: not that self-hosting is cheap, but that the expensive part only has to happen once.

---

Did I get it all right?

No. There have been at least two large rewrites — and a whole system before this one.

• The predecessor. I ran a hand-built setup for a few years before TAPPaaS existed. Every design decision here is an argument I already lost once, at home.
• Rewrite 1 — ADR-007. Foundation modules used to be numbered: 05-ProxmoxNode, 10-firewall, 30-tappaas-cicd. The number was the install order. Retired: order is now computed from dependsOn.
• Rewrite 2 — ADR-014. Zone tiers lived in prose in a README. Now tier and isolated are state, and four invariants are machine-checked on every reconcile.

Both times the same lesson: something I had encoded as a convention had to become a declaration.

TODO: name the predecessor, and say how long you ran it

---

The Ugly

The confession.

---

I used AI to build it.

And I gave it root on every node.

Not "AI-assisted autocomplete".

Root. ssh. nixos-rebuild. qm. pvesh. The firewall. The secrets.

---

Why on earth would you do that

Because the alternative was that it never got built.

• One retiree, evenings and weekends, six unfamiliar technology stacks
• 112,000 lines of platform code for thirteen app modules
• The plumbing is tedious, not clever — the exact shape of work to hand over

The graph does not lie: May 190, June 351. That is what handing over the tedium looks like.

And the honest part: I could not have hand-written the last third of this.

---

So the real question is not "did you"

It is: what did you fence it with?

The guardrails are not vibes. They are written down, in the repo, loaded on every single session, and they override anything the model would otherwise default to.

---

Guardrail 1 — the line it may never cross

Never run git commit or git push — full stop. The operator performs ALL commits and pushes themselves. This holds even when a request seems to imply it — "land it", "ship it", "move this to main" — and even when a previous turn involved committing. That is NOT standing authorization.

The AI may change any file on disk. It may not make a change permanent.

Every single line that entered history passed under my eyes.

---

Guardrail 2 — the blast radius is designed

Layer	What it bounds
Modules	A mistake lands in one VM, not "the server"
Zones	A compromised VM cannot reach what its VLAN forbids
Proxmox snapshots	Minutes-old rollback, per machine
PBS + off-site	Nightly, immutable, pull-based
NixOS	nixos-rebuild test before switch — a bad config dies at reboot
30,282 lines of tests	The update does not land unless the service proves it works

Root access is only terrifying if the system underneath is a snowflake. Mine is disposable by construction.

---

Guardrail 3 — confirm before the irreversible

The standing rules, as written:

• Confirm before destructive ops — deleting a VM it did not create, dropping a storage pool, force-pushing main/stable, wiping /etc/secrets
• Fix root causes, not symptoms — no --no-verify, no silenced errors, no bypassed CI to make an install "succeed"
• Read before you rebuild — test before switch
• Propose tests first, then run them

Note what these have in common: they are all rules about honesty, not about capability.

---

Guardrail 4 — I stayed the reviewer

Eight specialist roles — architect, bash, python, nix, tester, security, infra, PM — with a security review in the path of every change.

But the load-bearing part is duller than that:

• I read the diff
• I write the commit message
• I press the button
• 24 ADRs exist so that I still know why the system is shaped this way

The day I stop reading diffs, this stops being sovereign and starts being someone else's system running in my basement.

---

Am I still in control? Honestly.

Yes — but "control" moved.

I no longer control every line. I control:

• the architecture — modules, zones, contracts
• the gate — commits, pushes, releases
• the proof — 145 test suites, 29% of the source, that must be green
• the exit — it is all open source, on my hardware, in my hands

That is a real answer, not a comfortable one. Ask me the hard version in Q&A.

---

Your turn

Build one too.

---

Why you, specifically, should

European sovereignty is not a policy problem you can wait out.

It is thousands of small boxes, in basements and back offices, running software nobody can withdraw.

• Your data has to live somewhere. Somewhere can be here.
• A skill you own beats a subscription you rent.
• Every basement cloud makes the next one cheaper to build.

TODO: your one-sentence version of this — say it in your own words, not mine

---

Start smaller than I did

Step	What you get
1. One box, evaluation tier	4 cores / 16 GB / a disk. Nested virt is fine.
2. Proxmox + OPNsense	Zones, VLANs, DNS, certificates that renew
3. The mothership	tappaas-cicd — the thing that installs the rest
4. One service	Vaultwarden. Small, useful, immediately missed.
5. Backup before service two	Non-negotiable. Ask me why.

No public IP? A satellite VPS is the escape hatch. No GPU? Skip local AI, keep everything else.

---

Where to find all of it

• tappaas.org — docs, work in progress, honest about it
• codeberg.org/TAPPaaS/TAPPaaS — the code, the 24 ADRs, the commit graph
• sovereigncomputing.org — the wider argument
• This deck — slides.makerfloss.eu/tappaas/one-year-in
• MakerFLOSS — Orange Makerspace, bi-weekly FLOSS jam. Come build one with us.

Contributions welcome. Open an issue before you open a pull request — somebody may already be packaging your app.

---

Questions

The harder, the better.