Files
curriculum-project-hub/docs/adr/0025-alpha-silo-deployment.md
T

2.7 KiB

ADR 0025: Alpha Uses Managed Single-Organization Silos

Status

Accepted for the supervised alpha.

Context

The shared SaaS control plane, durable cross-Organization admission scheduler, and customer administration SPA are not complete. Real customer data must not depend on partially migrated application-level tenant filtering merely to start the supervised alpha.

Decision

Each alpha Organization runs as a separately named Silo deployment. A Silo has one Hub systemd unit and service identity, one logical PostgreSQL database and database role, one workspace root, one environment/session secret, one local master-key keyring, one Feishu Application Connection, and Organization-local Provider Connections. The process is pinned by HUB_SILO_ORGANIZATION_ID and refuses startup unless its database contains exactly that one active Organization.

Application releases remain shared and versioned; customer state does not live inside a release directory. Host-console bootstrap, upgrade, backup, restore, and KEK rotation always name a Silo instance explicitly. The alpha exposes no platform administration surface. Operators provision and support Silos through the controlled host console and retain an external change record.

The process-local trigger queue is not an accepted-work queue in the Silo alpha. A busy project or instance rejects new work explicitly. Each instance has checked-in application limits and explicit systemd CPU, memory, and process ceilings. Workspace filesystem quotas are a host provisioning prerequisite.

This topology changes deployment, not the semantic tenant root: Organization remains the tenant root and every authorization, secret, audit, Project, Team, and Run remains Organization-scoped. A later pooled or bridge adapter may host multiple Organizations only after ADR-0022's durable admission and platform control requirements are implemented.

Consequences

  • Cross-Organization data access is prevented by database credentials and process/filesystem identity in addition to application authorization.
  • Provisioning, migrations, backups, health, and upgrades are repeated per Silo and therefore must be automated before tenant count grows materially.
  • Cross-Organization fairness is not applicable inside one Silo; host cgroup ceilings prevent one Silo from exhausting the machine.
  • Database/workspace backups and the keyring/environment recovery copy are produced to distinct protected destinations and must pass a restore drill.

Deferred

  • Shared platform identity and administration from ADR-0023.
  • Pooled durable fair scheduling from ADR-0022.
  • Customer org administration SPA and self-service onboarding.
  • Docker or Kubernetes as an alternative deployment adapter.