Files
felhom.eu/documentation
admin e61aac1d8f
gates / gates (push) Successful in 22s
CHAOS NIGHT: two enumerated gaps become rows in the same session
R-547 (P3): a disk that fills and empties between sweeps is never mentioned to
anyone. The guest's root filesystem sat at 96% for ten minutes and no alarm of
any kind fired - checked twice, once by the round's runner and once
independently after the fill was released. disk_critical is defined at >=95%
used, but the fill-watch is a DAILY sweep plus one check ~90s after a controller
start, so a ten-minute window contains no check. The timing was almost comic:
the controller restarted at 21:28 after the previous round's power cut, so its
single opportunistic check ran about twenty seconds before the disk filled.
This is the ladder working as designed, not a missed alarm - it is filed because
the honest answer to "would the household be told?" is no, and that is written
down nowhere.

R-548 (P3): the whole-guest backup's LOCAL tier cannot fit on a
small-system-disk box and retries on that tier for ever. A ~29GB source into a
14GB pve-root, measured falling at ~16MB/s - under four minutes to a full / on
the nested PVE. The product's behaviour is correct throughout: it failed the
tier, named it, scheduled a retry, its status surface agreed, and the off-site
tier then succeeded from the same snapshot in ~8.5 minutes taking no local disk.
What is filed is the loop: on a box this shape the local tier can never succeed.
Honest caveat recorded in the row - the 32GB system disk is this drill's own
fixture choice - but nothing checks whether the local target could hold the
source before starting.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-09-17 00:16:25 +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.