Establish the design foundation for the heleosv2 multi-tenant hosting platform before any implementation code: - Monorepo skeleton: docs/, platform-infra/, site-templates/, deployments/, control-panel/ with orientation READMEs. - docs/: roadmap index, architecture + threat model, naming conventions, site profiles, provisioning workflow, backup & DR runbook, repo/GitOps layout, and the approved architecture plan. - docs/adr/: 9 ADRs recording the rationale for single-host Compose, Traefik edge, nginx+fpm split, shared MariaDB, ZFS-per-customer, decoupled backup streams, Forgejo, CLI-first, and SFTP-only. - Secrets hygiene: .gitignore (only *.enc.* committed) and .gitattributes (LF for scripts/Dockerfiles/YAML run on the Linux host). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.1 KiB
1.1 KiB
ADR 0005 — ZFS dataset per customer
Status: Accepted
Context
Backups must be cheap, integrity-checked, and restorable per customer without
touching neighbours. ZFS offers checksummed integrity, cheap copy-on-write
snapshots, and incremental zfs send.
Decision
Create a ZFS dataset per customer (tank/customers/<customer>/web) holding
only the web root. Docker image/layer storage and the MariaDB datadir live
on separate platform datasets. Customer web data is bind-mounted into containers
from the customer dataset.
Consequences
- ✅ Snapshot and
zfs sendoperate at the customer granularity — restore one customer independently. - ✅ Data integrity via checksums; cheap frequent snapshots.
- ✅ Keeping the dataset to web files only (no logs, no DB dumps) means an
unchanged site produces a near-empty incremental, keeping offsite
sendcheap — the explicit reason logs and DB dumps are stored elsewhere (ADR 0006). - ❌ Ties the platform to a ZFS-capable host (OpenZFS on Linux); not portable to arbitrary cloud block storage without rework.