e5ff798dd4
Adopt a two-level ownership model: a customer owns many sites, with isolation/containers/DB/backup at the site level and grouping (one SFTP login, recursive backup, billing, bulk delete) at the customer level. - 03-naming-conventions: rewritten for customer/site ids and slug = <customer>-<site>; nested ZFS, per-customer SFTP chroot, deployments mirror the nesting. - Propagated paths through docs 01, 04, 05, 06, 07 and deployments/README. - ADR 0005 retitled/updated to per-site datasets nested under customer. - architecture-plan.md: note pointing to doc 03 as authoritative on naming. Clarifies subdomains: same-app subdomains are aliases on one site; a separate-app subdomain is its own isolated site under the same customer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.8 KiB
2.8 KiB
heleosv2 — Roadmap & Document Index
This is the entry point for the platform design. Read the documents in order; each builds on the previous.
Document index
| # | Document | What it answers |
|---|---|---|
| 00 | This file | Phases, sequencing, where everything lives. |
| 01 | Architecture & threat model | What the system is; which boundaries protect what. |
| 02 | ADRs | Why each major technology choice was made. |
| 03 | Naming & conventions | How datasets, networks, containers, DBs, domains are named. |
| 04 | Site profiles | The four standard site stacks and their contents. |
| 05 | Provisioning workflow | Signup → live, step by step. |
| 06 | Backup & DR runbook | How backups run and how to restore one customer. |
| 07 | Repo layout & GitOps | Repo boundaries, secrets, deployment flow. |
The full approved architecture plan is at
architecture-plan.md.
Phased roadmap
| Phase | Goal | Output |
|---|---|---|
| 0 | Design docs & conventions | This docs/ set (in progress). |
| 1 | Host baseline | Ansible: ZFS pool + datasets, Docker, nftables, SSH hardening, egress filtering. |
| 2 | Platform services | Traefik (TLS/ACME), shared MariaDB, Forgejo + registry. Smoke test: hello-world routed over HTTPS. |
| 3 | Site templates & images | Standard images (php-fpm non-root, nginx, static) + compose templates for 4 profiles; Trivy/gitleaks in CI. |
| 4 | Provisioning CLI | provision / deprovision / list; ZFS + DB + compose + route; per-customer chrooted SFTP. |
| 5 | Backup & DR | ZFS snapshot/send for web; automysqlbackup + rsync for DB; restore drill. |
| 6 | Observability | node_exporter + cAdvisor + Traefik metrics → Prometheus/Grafana; Loki/Promtail; Uptime-Kuma. |
| 7 | Migration | Move existing sites: static/redirect → custom PHP → WordPress; DNS cut per site. |
| 8 | Customer panel (later) | Web UI over the Phase 4 CLI; self-service backup/restore; Falco runtime detection. |
Guiding principles
- The customer is the boundary — isolation, backup, restore align on it.
- Containers isolate, they don't secure by themselves — defense in depth (non-root FPM, read-only rootfs, per-site networks, egress filtering, least-privilege DB users).
- Each backup stream matches its data's change pattern — don't fold the DB dump into the web dataset (it would bloat every incremental).
- CLI/templates before UI — prove the platform, then wrap it.
- Phase the heavy stuff — observability, panel, Harbor/Falco come after the core works with real tenants.