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 three public repositories — check my homework:

  • codeberg.org/TAPPaaS/TAPPaaS — the platform
  • codeberg.org/TAPPaaS/Community — everyone else's modules
  • codeberg.org/TAPPaaS/Documentation — tappaas.org

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

This is one basement. There are 4 other known instances of TAPPaaS.

The same platform, two very different rooms

The MakerFLOSS rack at Orange Makerspace
makerfloss.eu — Orange Makerspace. Donated enterprise iron, a community lab.
The rack in my basement at home
hrossen.dk — my basement. Three small boxes, a switch, a modem.

Same modules. Same install.sh. Same tests. Same updates.

The software: foundation underneath, stacks on top

AI stack — tappaas2, on the GPUvllm-amd · 312LXC · Radeon 8060S128 GB unifiedlitellm · 310gateway · keys4 GBopenwebui · 311the chat window4 GBProductivity — tappaas1nextcloud · 340files · calendar8 GB · 80 GBeuro-office · 343documents8 GBFoundation — every app above rests on thesenetwork · 110OPNsense8 GBtappaas-cicd · 130mothership16 GBidentity · 140Authentik4 GBlogging · 1502 GBunifi-os · 811switch · AP6 GBbackup · PBSon tappaas3tankc1

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.

But we cannot do that here today. So instead — let us kill a node.

tappaas1 is running the firewall (vm:110), the mothership (vm:130)
and identity (vm:140) — all HA, fenced, watchdog armed.

I cut its power. They come back on another box.

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 brutal commit graph of a side project

2025-05   99  ██████████  ← the honeymoon
2025-06   21  ██
2025-07   53  █████
2025-08  141  ██████████████  ← Sommerhack 2025
2025-09    6  █  ← vacation
2025-10    9  █
2025-11   41  ████
2025-12   47  █████
2026-01   66  ██████
2026-02  141  ██████████████
2026-03   33  ███
2026-04   19  ██
2026-05  190  ██████████████████
2026-06  351  ██████████████████████████████████  ← something changed
2026-07  164  ████████████████
2026-08  126  ████████████  (to the 25th)

Not a burndown chart. A heartbeat — 1,507 beats, and two months where it
nearly flatlined.

The services stayed up through the flat bits anyway, 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
195 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. Before TAPPaaS existed I ran a hand-built setup for
    five years, uninterrupted. It never had a name. Every design decision
    here is an argument I already lost once, at home.
  • Rewrite 1 — ADR-003. Every module was a plain install.sh you ran in the
    right order, by hand. Replaced by dependsOn / provides contracts, resolved
    into an install order by the platform.
  • Rewrite 2 — ADR-007. The flat pile of sequenced scripts became a
    manager / controller paradigm: 7 TypeScript managers that own intent,
    6 controllers that do the live I/O against OPNsense, Authentik, Proxmox, the switch.

Both times the same mistake: I had written as a sequence of steps
what needed to be a structure — dependencies the first time, roles the second.

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 — nothing starts with a prompt

By the time the AI is allowed to code, 2–3 artefacts exist —
carefully crafted and reviewed by humans:

  1. An Issue — a well-defined problem and a proposed fix. No issue, no change.
  2. An ADR, for anything non-obvious — reviewed by at least two people.
    Usually me and Erik. 24 of them so far.
  3. A design and implementation plan — including how this will be tested,
    written before a line is written.

Then the AI takes over — as eight specialist roles: architect, bash, python,
nix, tester, security, infra, PM.

The model does not decide what to build, or what "done" means. It never has.

Guardrail 2 — 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 commit that entered history passed under my eyes.

Guardrail 3 — 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
34,490 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 4 — 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 — nixos-rebuild test before switch

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

Guardrail 5 — the tests decide, not the agent

Every module ships two test levels:

When it runs What it is for
quick every change, every scheduled update is this service still itself?
deep test-module.sh <module> --deep the full behaviour, too slow for every commit

And around them:

  • the test plan is written in the ADR, before the implementation exists
  • after implementation, a full regression across every module — not just the one touched
  • 195 test suites · 34,490 lines · 27% of all source

An agent that can edit code can also edit the test that would catch it.
That is exactly why a human writes the test plan first, and why the
regression sweep is the thing that says "done" — not the agent.

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 — 195 test suites, 27% 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.

Start smaller than I did

Step What you get
1. One box, evaluation tier 4 cores / 16 GB / two disks. 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 Home Assistant. 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.

Sixty minutes. Roughly: 8 opening, 18 Good, 14 Bad, 14 Ugly, 6 close. Leave the last 5 for questions from the tent — this crowd will have them. Tone: this is a confession, not a product pitch. The proof is the mess.

Read the four bullets slowly. The fourth is the one that sounds mad and turns out to be the whole point — come back to it in the AI section.

The 1091 → 1507 jump is the joke that lands: I wrote the abstract in the spring and the project kept going. Point at it. The 41 is the other one worth pausing on: 8 foundation + 12 apps in the TAPPaaS repo, plus 21 modules other people wrote in the Community repo. That last number is the one that says this stopped being my hobby. Figures recomputed 2026-08-25 from the tree (a module = a directory with its own <name>.json contract), using the methodology in src/STATISTICS.md. Community repo: codeberg.org/TAPPaaS/Community.

Deliberately short divider slide. Say "it runs" out loud and pause.

Every number here was read off the running cluster, not a wiki page. The last line is deliberately understated — it sets up the sharing argument in The Bad, and the Community repo in the next slide. Five sites is not a movement yet; it is proof the thing installs somewhere that is not here. Worth saying out loud: only tanka1 on tappaas1 is a mirror. tappaas2 and tappaas3 run single NVMe — deliberate, they are rebuildable from backup. The 10G links are direct-attach copper; tappaas1 and tappaas3 have a second NIC on VLAN 100 straight to the modem, which is how OPNsense gets a WAN.

The point of showing both: TAPPaaS does not assume a datacentre OR a cupboard — the module contract is what makes those two rooms the same system. The makerspace rack is loud, rented space, many hands; mine is quiet, mine, and runs my family's calendar. Neither is the "real" deployment.

The point of the picture: the top two boxes are the only part anyone in my house notices, and they are the small part. Everything below the line is what makes them survive a year unattended. vllm-amd is the one LXC in the estate — a container, not a VM, because the GPU has to be passed through to reach the 8060S.

The abstract promised eight services. Give the 41 a beat before explaining it. Then be honest about what "in the tree" means versus "live in my basement": a module existing and a module your family depends on are different claims. The Community repo is codeberg.org/TAPPaaS/Community — one directory per person, no gatekeeping, and it is the only slide in this deck that is evidence the project outgrew me. Say that plainly; do not undersell it.

This is the core argument of the whole project. Slow down here. Self-hosting is easy. Self-hosting you can forget about is not.

If someone asks "is this just Ansible/Terraform?" — the answer is: those are how you build one machine. This is about a machine estate that has a shape.

This is the least popular slide with hackers and the most important one. Every hour you spend re-deciding VLAN layout is an hour not spent on services. Expect pushback; welcome it.

Stress "unified memory" — that is what makes a 120B model possible on a box that fits under a desk. This is a genuinely new thing as of this year.

The cable-pull needs the basement, so it is the screen recording today. LIVE DEMO instead: `ha-manager status` first, so the tent sees the three services sitting on tappaas1. Then pull tappaas1's power. Be honest that this drops the firewall — the whole site goes dark for the fencing timeout before the services restart elsewhere. That pause IS the demo; narrate it rather than filling it. `ha-manager status` again to show them landed on another node. Checked 15:02 today: quorum OK, master tappaas3, fencing armed.

Tie back to bullet four from the dream slide: "no reliance on the Internet". That was the mad-sounding one. Here it is, cashed in.

Point at Sept/Oct 2025 — six and nine commits — and say "I was on vacation." Deadpan. That is the whole joke, and it makes the following line land: a platform that needs you every week is not a platform, it is a pet. Then point at June: 351. Do NOT explain it yet — that is the hook into The Ugly, two slides from now. Numbers regenerated 2026-08-25; August is a partial month.

Deliberate hook into The Ugly. The commit spike is the evidence, and the audience will already be suspicious. Good. Let them be.

The 7:1 platform-to-app ratio is the single most useful number in this talk for anyone thinking "I'll just spin up Docker Compose". That works — until you want it to still work next year without you. Source: src/STATISTICS.md, regenerated 2026-08-23.

This is the slide that turns The Bad from a complaint into an invitation. The honest concession first — it IS a lot of work — then the pivot: almost none of it is per-site work. Land on the last line and pause. If someone objects "a thousand basements do not exist yet" — agree, and say that is precisely why you are standing here. TODO: your own hours-per-week number makes the concession land harder.

This is the credibility slide. Do not soften the "No" — an audience that has just been told you gave an AI root needs to hear that you rebuild things when they are wrong. Both ADRs are in the repo, and ADR-007f was written by Erik, not me — which is the two-reviewer rule from Guardrail 1 doing its job in public. If you want a third: ADR-014 recast zone tiers from README prose into checked state, and its own changelog lists four things the draft got wrong.

Say it flatly and then be quiet for three full seconds. Let the tent react. This is the slide people came for and the one they will argue with afterwards.

Do not be defensive. The result is on the projector; the method is the price.

This is the pivot from confession to engineering. Everything after this is transferable to anyone in the tent using these tools.

This is the most transferable slide in the talk, and the one people actually need. The order matters: problem, decision, plan, and only then code. Two reviewers on an ADR is the part that keeps me honest — Erik has killed several of my ideas, and the ADR is where that argument is recorded.

Verbatim from CLAUDE.md. The distinction — mutate freely, persist never — is the single most useful idea in this section. Say why: git is the undo button, so the undo button is the thing it must not touch.

This is the actual answer to "you gave an AI root?!". The architecture that makes unattended updates safe is the same architecture that makes an over-eager agent survivable. Same property, two beneficiaries.

The failure mode with a capable agent is not malice. It is an agent that makes the red thing turn green by removing the check. Name that explicitly.

This closes the loop opened in Guardrail 1: the plan said how it would be tested, and this is where that promise is collected. The last two lines are the answer to the sharpest question in the room — "how would you even know if it cheated?"

Do not claim more than this. If someone says "that's not control, that's supervision" — agree, and say supervision with a hard gate and a working undo is what control has always meant in operations.

Prepared answers to have loaded: - "Isn't this just Ansible?" → estate vs. machine; dependsOn - "Why NixOS?" → reproducible rebuild is the undo button - "You gave an AI root — seriously?" → guardrail 2, blast radius by design - "What if you get hit by a bus?" → open source, docs, ADRs, TODO: honest answer - "Cheaper than Google?" → no. Ownable, though. - "Can I run it on one Raspberry Pi?" → no. Evaluation tier, x86, be realistic.