Files
felhom.eu/documentation
admin 63eff21a5c
gates / gates (push) Successful in 17s
golden 0.232.0 baked, vouched, floor raised — and it carries TWO releases
GOLDEN_SHA256 5f8a53ed5b19a6cb2006298ce6239f6fca2b990cc3ef6eada89f602801ca91b8,
657 494 489 B. 0.231.0 was never baked, so the fleet went 0.230.0 -> 0.232.0.

THE CHECK THE 0.230.0 BAKE SKIPPED, AND THIS ONE DID NOT: the bake script's fingerprint was
compared ACROSS THE HOP - 7b0fb5cf...73b6a1 on DooPlex and inside the VM. The previous bake
recorded only the DooPlex-side hash and said so; this one is a measurement.

Three independent readers agreed before anything was vouched: the bake's own print, the round
trip of the published bytes (HTTP 200, 657494489 B, same sha, hashed from what was
downloaded), and the hub's Day-0 dropdown reading Gitea on a different code path. The
delivered artifact names its own controller - ./etc/felhom-controller-image reads
felhom-controller:0.232.0 - with 19382 entries under var/lib/felhom/docker/.

Both pre-gates were shown able to see something before their zeroes were believed, and the
manifest was RE-READ after vouching rather than trusted from the 303 flash.

DELIVERY WAS ACTUALLY EXERCISED. Both boxes had been hand-deployed during validation, so the
floor had nothing to move. Rather than report delivery untested, demo-felhom was rolled back
to 0.231.0 and the chain run for real - it moved itself in ~20s:
  10:47:16 controller-swap: image file written, restarting bootstrap  target=...0.232.0
  10:47:26 controller-swap: new controller healthy                    target=...0.232.0

And this is the first bake golden_currency_gate.py actually gates: it now reads the
GOLDEN_SHA256 line out of the bake log rather than matching a directory name (R-410, shipped
hours earlier the same day). All 13 felhom.eu gates are green, golden-currency included, for
the first time since v0.230.0 was released.
2026-09-01 10:50:54 +02:00
..

Felhom — Documentation

Felhom is a managed home-server service for Hungarian households, built on a three-component model over Proxmox:

  • Hub — operator backend on k3s (hub.felhom.eu). Repo: felhom.eu/hub/.
  • Host agent — one per Proxmox host; operator-tier; owns all Proxmox interaction. Repo: felhom-agent/.
  • In-guest controller — one per customer LXC; Docker-only; manages the customer's apps. Repo: felhom-controller/.

This directory is the central, code-verified documentation home for all three components plus the platform and the security-audit record.

Sections

Controller (in-guest) — controller/

The Docker-only app-domain controller. Full per-area docs grounded in current source (v0.59.0). → controller/README.md: module map, deploy & stack lifecycle, backup architecture, storage/monitoring/metrics, auth/hub/sync/integrations.

Where we stand — architecture/where-felhom-stands.*

The operator's one-page picture of what is proven, built, partial and missing.

Host agent & platform — architecture/, proxmox-platform.md

The operator-tier agent and the Proxmox platform.

Hub (operator backend) — architecture/05

Security audits & remediation — audits/

Spike & test findings — tests/

Per-slice spike/validation findings (phases 0–5, slices 7–10). See tests/.

Conventions

  • Code-verified, not memory-derived. Architectural claims here are checked against the actual current source; if a claim can't be verified it is omitted and flagged, not guessed.
  • Per-repo operational working files (CLAUDE.md, CONTEXT.md, CHANGELOG.md, BUGHUNT.md, REPORT.md, TASK.md) live in their own repos — they are operational, not published docs.
  • Authoritative versions at last refresh: controller v0.59.0, agent v0.29.1, hub v0.11.0.