bart/platform
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
heleosv2 multi-tenant hosting platform (infra + CLI)
13 commits 1 branch 0 tags 136 KiB
Find a file
Bart Van Geyt 7a65e7f7c6 fix(ansible/backup): create /etc/sanoid and install its defaults 
Some sanoid packages (e.g. on Ubuntu 26.04) don't ship /etc/sanoid, so the
config template failed with 'Destination directory does not exist'. Create
the directory explicitly, and copy the packaged sanoid.defaults.conf into
it (sanoid requires it beside sanoid.conf) so the first timer run succeeds.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-09 05:28:08 +02:00
.forgejo/workflows Phase 3: site templates & base images 2026-07-07 17:06:25 +02:00
control-panel Phase 4: provisioning CLI (heleosctl) 2026-07-07 17:18:36 +02:00
deployments Refine to nested customer -> site model 2026-07-07 12:37:39 +02:00
docs Phase 5: backup/DR automation (backup Ansible role) 2026-07-07 18:04:41 +02:00
platform-infra fix(ansible/backup): create /etc/sanoid and install its defaults 2026-07-09 05:28:08 +02:00
site-templates Phase 3: site templates & base images 2026-07-07 17:06:25 +02:00
.gitattributes Phase 0: architecture docs, ADRs, and repo scaffold 2026-07-07 12:26:00 +02:00
.gitignore Phase 4: provisioning CLI (heleosctl) 2026-07-07 17:18:36 +02:00
CLAUDE.md Phase 5: backup/DR automation (backup Ansible role) 2026-07-07 18:04:41 +02:00
README.md Phase 0: architecture docs, ADRs, and repo scaffold 2026-07-07 12:26:00 +02:00

README.md

heleosv2 — Multi-Tenant Web Hosting Platform

A rebuild of a small web-hosting business on modern, isolation-first infrastructure: container-per-customer + ZFS-dataset-per-customer, with repeatable CLI-driven provisioning and clean per-customer backup/restore.

Core philosophy — the customer is the boundary. Isolation (containers), backup (ZFS), and restore all line up on the same boundary, so a compromised or broken site is contained and restorable without touching neighbours.

Status

Phase 0 — writing the design documents before any platform code. See docs/00-roadmap.md.

Repository layout

This monorepo groups four logical areas whose contents have different lifecycles (see docs/07-repo-layout-gitops.md):

Path Purpose
docs/ Architecture, ADRs, runbooks, conventions.
platform-infra/ Ansible + base compose for host, Traefik, MariaDB, Forgejo, monitoring.
site-templates/ Dockerfiles for standard images + compose templates per site profile.
deployments/ Rendered per-customer configs (GitOps state). No plaintext secrets.
control-panel/ Provisioning CLI now; customer-facing panel later.

Key decisions

  • Single bare-metal host, Docker Compose per customer, no orchestrator.
  • Shared MariaDB (per-site DB + least-privilege user).
  • Decoupled backups: web files via ZFS snapshot/send; DB via automysqlbackup + rsync; logs via Loki.
  • Lightweight DevOps: Forgejo + built-in registry + Trivy.
  • CLI-first provisioning; web panel deferred until the platform is proven.

The full approved architecture plan lives at docs/architecture-plan.md.