9f819df4d9
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>
22 lines
1 KiB
Markdown
22 lines
1 KiB
Markdown
# 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).
|