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.2 KiB
1.2 KiB
ADR 0008 — CLI/templating first, customer panel later
Status: Accepted
Context
A customer-facing control panel (self-service create/delete/backup/restore over Docker + ZFS) is the single largest build — realistically months. Options: adopt and extend an existing PaaS (Coolify/CapRover/Cloudron), build a bespoke panel up front, or ship internal CLI tooling first and defer the UI.
Decision
Build provisioning as an internal CLI / templating tool first
(control-panel/). The customer-facing web panel comes later, as a wrapper
over the same, proven CLI operations.
Consequences
- ✅ Lowest initial risk; the provisioning logic (ZFS + DB + compose + routing) is validated end-to-end before any UI investment.
- ✅ The CLI doubles as the automation surface the future panel and CI call into — no throwaway work.
- ✅ Keeps early focus on correctness of isolation/backup rather than UX.
- ❌ No customer self-service until Phase 8; provisioning is operator-driven in the meantime.
- ↔️ Adopting an existing PaaS remains an option for the panel layer if building it proves too costly; the CLI would still own the ZFS/backup specifics.