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>
1.1 KiB
1.1 KiB
ADR 0003 — Per-site nginx + php-fpm behind Traefik
Status: Accepted
Context
Traefik terminates TLS and routes but cannot talk FastCGI to php-fpm. PHP sites
need something that serves static assets and bridges HTTP→FastCGI. Options:
one combined nginx+fpm image, Caddy-with-php_fastcgi (single process), or the
classic split of nginx and php-fpm into two containers.
Decision
Each PHP site runs nginx + php-fpm as two containers within its own compose
project, sharing the web-root volume. Traefik routes to the site's nginx; nginx
proxies .php to that site's php-fpm.
Consequences
- ✅ Conventional, extremely well-documented pattern.
- ✅ PHP runtime can be patched/pinned per site independently of the web server.
- ✅ nginx cannot execute PHP outside the fpm boundary; php-fpm runs non-root.
- ❌ Two containers per PHP site increases container count and compose verbosity.
- ↔️ Caddy-single-container remains a valid future simplification for low-traffic sites; revisit if container density becomes a concern. Static and redirect profiles avoid php-fpm entirely.