Files
felhom.eu/documentation
admin 721297ed5e
gates / gates (push) Failing after 10m43s
golden 0.206.0 baked, published, round-trip verified — NOT vouched; the gate goes green
Controller v0.206.0 shipped the R-241 fixes on 2026-08-07 while the vouched
golden still carried 0.205.0, so a machine installed this morning would have
received neither - and the next recovery walk would have measured the old
behaviour and failed for a reason nothing to do with the walk. Same gap as
R-239, one day after R-239 was closed.

  version  0.206.0
  sha256   c85230b42f53baa9c1ee9986ac312c751d6cbc29fbe070d87bb2214429a9108e
  size     656,750,694 bytes (uncompressed 2,003,138,560)
  MinAgent 0.127.0

Round-trip verified rather than trusted: the published bytes were fetched
back, re-hashed independently (match), zstd-tested, and
./etc/felhom-controller-image was read OUT of the download ->
felhom-controller:0.206.0. That last step is the one that matters, because
GOLDEN_VERSION is derived from the tag argument and could be right over stale
content.

All acceptance markers pass; unit Result=success ExecMainStatus=0. Secret
hygiene: token file->file, in-VM runner so it never reached a command line
(unit-property grep 0), literal-value leak grep on the COMMITTED log 0 - with
a positive control proving the grep works before the 0 was believed.

Bake VM torn down: CT 9100 purged, secrets shredded, qemu observed gone via
ps -eo comm, drill.qcow2 reverted to virgin.

THE GATE BUILT EARLIER THIS SESSION NOW PASSES. It was shown CONVICTED against
the pre-bake state and is OK now - red to green on the same check, the same
command, which is its proof that it measures something real. Note it went
green on the BAKE, not the vouch: that is its stated limitation, and the vouch
is still pending the operator.

NOT VOUCHED - the operator's act. Only one field moves: golden_version
0.205.0 -> 0.206.0 (+ its derived sha). agent_version and min_agent both stay
0.127.0. wrapper_sha256 is unchanged but is CLEARED if omitted from the POST.
2026-08-07 13:05:40 +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.

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 05, slices 710). 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.