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>
46 lines
2.8 KiB
Markdown
46 lines
2.8 KiB
Markdown
# 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](01-architecture-and-threat-model.md) | What the system is; which boundaries protect what. |
|
|
| 02 | [ADRs](adr/) | *Why* each major technology choice was made. |
|
|
| 03 | [Naming & conventions](03-naming-conventions.md) | How datasets, networks, containers, DBs, domains are named. |
|
|
| 04 | [Site profiles](04-site-profiles.md) | The four standard site stacks and their contents. |
|
|
| 05 | [Provisioning workflow](05-provisioning-workflow.md) | Signup → live, step by step. |
|
|
| 06 | [Backup & DR runbook](06-backup-and-dr.md) | How backups run and how to restore one customer. |
|
|
| 07 | [Repo layout & GitOps](07-repo-layout-gitops.md) | Repo boundaries, secrets, deployment flow. |
|
|
|
|
The full approved architecture plan is at
|
|
[`architecture-plan.md`](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
|
|
|
|
1. **The customer is the boundary** — isolation, backup, restore align on it.
|
|
2. **Containers isolate, they don't secure by themselves** — defense in depth
|
|
(non-root FPM, read-only rootfs, per-customer networks, egress filtering,
|
|
least-privilege DB users).
|
|
3. **Each backup stream matches its data's change pattern** — don't fold the DB
|
|
dump into the web dataset (it would bloat every incremental).
|
|
4. **CLI/templates before UI** — prove the platform, then wrap it.
|
|
5. **Phase the heavy stuff** — observability, panel, Harbor/Falco come after the
|
|
core works with real tenants.
|