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 KiB
1 KiB
ADR 0001 — Single bare-metal host, Docker Compose per customer
Status: Accepted
Context
Small hosting business, modest site count, ZFS-based backup strategy. Options ranged from a single host to a multi-host orchestrated fleet (Swarm/Nomad/k8s) or cloud VMs.
Decision
Run everything on one bare-metal host, using one Docker Compose project per customer/site. No orchestrator. Host configured with Ansible.
Consequences
- ✅ Simplest possible operational model; ZFS lives directly on local disks
(best snapshot/
sendstory, no network-storage complications). - ✅ Compose-per-customer maps 1:1 to the isolation and backup boundary.
- ✅ No control-plane overhead (no etcd, no scheduler).
- ❌ No built-in HA/failover; the host is a single point of failure — mitigated by disciplined offsite backups and a documented rebuild/restore drill.
- ❌ Vertical scaling only. If site count outgrows one box, revisit with a superseding ADR (Swarm/Nomad, ZFS locality becomes the hard problem).