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>
21 lines
965 B
Markdown
21 lines
965 B
Markdown
# ADR 0009 — SFTP only (no FTP)
|
|
|
|
**Status:** Accepted
|
|
|
|
## Context
|
|
Customers need file access to their web root. Legacy FTP is plaintext
|
|
(credentials and data in the clear). FTPS adds TLS but is firewall-hostile
|
|
(dynamic data ports). SFTP runs over SSH on a single port.
|
|
|
|
## Decision
|
|
Provide **SFTP only**, with each customer **chrooted to their own ZFS dataset**
|
|
(web root). No FTP, no FTPS. A web-based file manager (e.g. Filebrowser) may be
|
|
added later alongside the customer panel for non-technical users.
|
|
|
|
## Consequences
|
|
- ✅ Encrypted transport; single well-known port; firewall-friendly.
|
|
- ✅ Chroot enforces the same per-customer boundary as containers and datasets.
|
|
- ❌ Some legacy customer tooling only speaks FTP — those users migrate to SFTP
|
|
clients (documented in onboarding).
|
|
- ⚠️ SFTP access is a path into the web root; keys/passwords are per-customer and
|
|
rotatable, and the chroot prevents traversal to other customers or the host.
|