felhom.eu/STATUS.md

STATUS — what works, what's broken, what's next

Ready for the first real tester (Tester-2): yes. You confirmed the tunnel route and the connect mails (2026-09-30).

Updated 2026-10-04: off-site safety finished. Both demo boxes run controller 0.290.0 and host agent 0.138.0. Hub 0.128.0. New installs get golden 0.290.0 with agent 0.138.0; every box's floor is 0.290.0.

Today (2026-10-04): off-site safety finished

• The weekly clean-up is ON and no longer stops itself. The fake-backup check now skips young copies that a manual backup replaced the same day, instead of refusing. I ran one window on demo-hp: no refusal, nothing removed (127 → 127), because every candidate was still young. The first real removals come when those copies are older than 8 days — around 11 October. demo-felhom gets its first window at its next night run.
• DooPlex keeps 8 weekly copies of ep0 (your choice). Old copies go weekly; anything ep0 deletes still never reaches the copy by itself. Today's nightly copy ran fine.
• tester-1's 3 old keys are gone. The daily alarm for tester-1 stopped. (You got one last alarm mail this morning, sent just before I removed them.)
• A restore from the DooPlex copy works. I restored demo-hp's whole box onto a scratch machine in about 3 minutes, read its data, then deleted it. One trap found: a restored box starts automatically and points at the real drives. Run beside the original, that would be two copies of the same box. I switched it off in time; the runbook now warns, and a row asks to make it safe by default.
• "Delete my old set-aside backups" works again. The hub does it, 7 days after the household's request; the household or you can cancel in that time. Tested on tester-1 with a planted test folder.
• Your answers are recorded, including that you keep the current Hetzner key for now (a row holds the 3 steps).
• Rows: 6 closed, 4 opened. The list went from 330 to 328.

Today (2026-10-03, evening): your choices A and A — built

• A box can no longer delete its off-site backups. Both demo boxes now use a key that can only add. I tried a delete from each box: refused. Old backups all stayed (demo-felhom 11 → 13, demo-hp 91 → 100).
• No box gets the storage password any more. The box gives the hub only its public key; the hub puts it in the storage account. I asked for the password with demo-hp's own login: refused.
• The hub keeps the passwords locked (encrypted). A copy of the hub database no longer reveals them.
• Every day the hub checks each storage account's key file. It found old unlocked keys from earlier boxes: 4 on demo-felhom's account and 5 on demo-hp's — now removed. tester-1's account still has 3 (its box is gone); you get a daily alarm for it until they go.
• The weekly clean-up window works, but it is switched OFF. I opened one window on demo-hp by hand: it opened, the fake-backup check refused, and it closed in 3 seconds. The check refused because I had made a manual backup today — it is too strict. I fix that next; until then nothing deletes old backups (there is plenty of room).
• ep0's whole-box backups are copied to DooPlex every night. First copy: 12 GB in 3 minutes, all 4 backups. DooPlex cannot read them (encrypted per household). A failed copy mails you; the test mail arrived.
• One bug, found and fixed live: the first new box version misread its backup count as 0, and you got one false alarm mail ("demo-felhom: fell from 11 to 0"). Ignore that mail. Fixed 15 minutes later (0.289.1).
• Rows: 3 closed, 6 opened, 1 opened and closed the same day. The list went from 327 to 330.

Today (2026-10-03, later): off-site backup safety, step 1 — measured, nothing built

• The "add only" lock works. I tested it on tester-1's storage account (your choice; no box uses it now). New backups go in. Restore works. Every delete is refused. I put the account back exactly as it was.
• But the lock alone does not protect us yet. A broken-into box can ask the hub for the storage password. With that password it can log in and remove the lock. First the box must stop getting the password.
• A second trap: with "add only", an attacker can add fake backups dated in the future. The normal clean-up rule then deletes all the real backups. Any clean-up must check for this.
• The hub keeps every storage password in plain form. Anyone who reads the hub database can delete every household's off-site backups. New row.
• ep0: Hetzner cannot snapshot the extra disk at all. One of the three old ideas does not exist.
• Rows: 2 closed, 3 opened. The list went from 326 to 327 rows. The dated check for 6 October is done.

Today (2026-10-03): the to-do list is in order — paperwork only, no machine touched

• Finished items left the open list. It went from 442 rows to 326. Nothing was deleted; each moved row names where its full text is.
• Every open row now has one category and one severity (P1 now · P2 before the first paying customer · P3 during the first customers · P4 later). No row is P1. 27 rows are P2.
• Two new automatic checks refuse a finished row left in the open list, and a new row without a category or a severity.
• Your four new items are on the roadmap: security updates for the box's own system; legal pages and business papers; "what if the household leaves Felhom"; a second login step for the dashboard. Two of them are also real findings today: a box never receives system security updates, and the website has no privacy notice, terms or imprint.
• The ranked list and my reasoning: the triage recommendation in the audits folder.

Tester-2 — read only, from the hub. The customer record exists. Tester-2's box has not registered yet.

Today (afternoon): every app checked again

• No data-loss fault. I checked all 58 apps with the fixed check. It made each app really save something, then looked where the data landed. No app saves data where the backup does not copy it.
• 40 apps: proven correct. 18 apps: not proven either way. In those 18 the check could not fill every folder (for example an upload folder stays empty because my test saves no upload). Nothing was found outside a backed-up folder. I list them and work on them later.
• papra was broken for new installs, now fixed. It needs more memory than its limit, so a fresh install crashed in a loop. I measured it and raised the limit. No box runs papra.
• plant-it's program image is gone from Docker Hub. It is already hidden from new installs. No box runs it.

Removing an app now tells the truth (your choice A)

• When the household removes an app, its own files (books, videos) stay. The dialog and the result now say so, and name the folder. Proven on the scratch box: the video was still there after the remove.

Before the first paying customer

Everything here must be done before the first customer who pays:

1. SparkyFitness: written permission from the author (the e-mail draft is ready). If none → hidden from new installs.
2. Tandoor: written permission from the authors. If none → hidden from new installs.
3. A lawyer reviews the licence list (Tandoor, SparkyFitness, Emby, n8n, Plex, the paid "enterprise" parts, Redis).
4. Agent updates: I may sign agent updates only until the first paying customer; after that you sign them.

Your licence decisions are recorded: Emby, Plex and n8n stay. recipe-importer needs nothing unless we share it.

Also today

• New version 0.288.0 and a new golden (0.288.0).
• Rows. 7 closed, 6 opened. The list went from 436 to 442 rows.

What needs you

0. Nothing new from the off-site work. The Hetzner key change stays your call whenever you want it (3 steps, in the list).
1. plant-it: keep the hidden template as it is, or remove it entirely (its image no longer exists). If you say nothing: it stays hidden; nothing runs it.
2. Send the SparkyFitness request, and ask the Tandoor authors (the "Before the first paying customer" list).
3. Phone test (2 minutes), only if you want it: say so, and I put MeTube back on demo-hp with a family login.

Standing steps

• Monthly security re-test: last run 2026-10-01, next due ~2026-11-01. (You start it with the standing brief.)
• Weekly: the golden bake (next around 9 October; today's bake was 0.288.0).
• Registry clean-up: only when the registry disk fills; "show me" mode first, then a person decides.