Skip to content

Tenancy & Deployment Model

Date: 2026-02-08

Summary

AccessOS v0 uses a tenant-isolated data-plane model: one deployed service set per tenant in a single AWS account, plus a shared global control plane for tenant registry, routing metadata, and licensing.

Control plane capability details live in 05-specs/global-control-plane-registry-and-licensing.md.

Current Recommendation (v0)

Single AWS account + per-tenant ECS services for customer workloads.

Why this now

  • Strong isolation posture without relying only on application logic.
  • Limits blast radius of service defects and credential mistakes.
  • Supports enterprise isolation narrative while keeping operations centralized.
  • Fits expected 12-month scale (~100 tenants) with quota planning.

Deployment Shape (v0)

  • Shared global control plane services for metadata/operations.
  • Per-tenant data-plane service set:
  • integrations-service
  • discovery-service
  • discovery-worker
  • audit-service
  • iam-service
  • Tenant-scoped storage/resources (DB schema or DB partition, S3 prefix/bucket policy scope, Secrets Manager paths, IAM role scope).

Workspace Model

  • workspace_id is the primary product scope for day-to-day access control.
  • Workspace visibility is enforced by APIs and service middleware.
  • Tenant Admin may perform explicit administrative flows (for example, workspace owner transfer) and those actions must be audited.

Routing Strategy

  • Prefer tenant subdomains (for example, tenant.a3os.app) for direct routing clarity.
  • If shared hostnames are used, a router/gateway resolves tenant mapping via control-plane published metadata.
  • Routing resolution must not require per-request data-plane lookups.

Enforcement Model (Required)

  • Runtime access to tenant resources is constrained by tenant-specific IAM roles, secrets, and resource policies.
  • Service instances are deployed with tenant-bound credentials and must not hold cross-tenant data-plane credentials.
  • API and background workers enforce workspace scope from authenticated context.
  • Queue payloads carry tenant/workspace identifiers and never include secrets.

Cross-Scope Rules

  • Cross-tenant product data access is out of scope for v0.
  • Cross-workspace reads are workspace-scoped by default.
  • Explicit cross-workspace admin operations require role checks and auditable reason fields.

CI/CD Implications

  • Separate environment planes: dev and prod.
  • Each environment manages a fleet of tenant service sets.
  • Rollouts should support canary/wave deployment across tenants.
  • Tooling must prevent accidental cross-tenant deploy targeting.

Future Options

  • Premium tier: account-per-tenant deployment for stricter isolation/compliance.
  • Optional shared control-plane enhancements for routing and fleet management only.