platform/docs/adr/0001-single-host-docker-compose.md
Bart Van Geyt 9f819df4d9 Phase 0: architecture docs, ADRs, and repo scaffold
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>
2026-07-07 12:26:00 +02:00

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/send story, 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).