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-03 (evening): off-site backups a box cannot delete — built and live. Both demo boxes run controller 0.289.1 and host agent 0.138.0. Hub 0.127.0. New installs get golden 0.289.1 with agent 0.138.0; every box's floor is 0.289.1.

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. Off-site clean-up window: nothing to decide now. It stays OFF until the next session fixes the too-strict check. If you do nothing: no old off-site backup is deleted; storage grows slowly (each household uses under 1 GB). 0b. How much history should DooPlex's ep0 copy keep? Today it keeps everything and grows every night.
   • A — keep the last 8 weekly copies (recommended): undo up to 2 months; about 4 times ep0's size (ep0 keeps 2).
   • B — keep everything: never loses anything; DooPlex's disk slowly fills (5.5 TB free today).
   • If you do nothing: B — it grows; nothing breaks for months. 0c. tester-1's old keys: say "remove them" and I clean that storage account's key file through the hub. If you do nothing: one alarm mail a day for tester-1.
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.