platform/deployments/README.md
Bart Van Geyt e5ff798dd4 Refine to nested customer -> site model
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>
2026-07-07 12:37:39 +02:00

18 lines
686 B
Markdown

# deployments
GitOps state — nested `customer/site` directories, rendered by the provisioning
CLI (Phase 4). Empty until the first site is provisioned.
Layout (see
[../docs/03-naming-conventions.md](../docs/03-naming-conventions.md) §7):
```
<customer>/
└── <site>/
├── site.yaml # declarative source of truth (customer, site, profile, domains)
├── docker-compose.yml # rendered from a site-templates profile
├── .env.example # non-secret references
└── secrets.enc.yaml # SOPS/age-encrypted secrets (committed encrypted only)
```
**Never commit plaintext secrets.** Only `*.enc.*` / `*.sops.*` are allowed.