# 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.