//Single-Tenant & On-Prem Plan

Single-Tenant & On-Prem Plan

Status as of April 17, 2026: Control Plane Migrated (Rust Native).

Goal

ButtrBase should support four deployment topologies behind one product contract:

  • multi-tenant SaaS
  • single-tenant managed cloud
  • single-tenant BYOC
  • on-prem / air-gapped

    • The API, admin UX, entitlements, audit model, and billing decision contract should stay as consistent as possible across all four.

    Why This Matters

    Larger customers often need one or more of:

  • dedicated compute and data isolation
  • private networking
  • customer-owned cloud accounts
  • stricter residency controls
  • offline or tightly firewalled deployments

    • If deployment topology is real product scope, it has to be modeled deliberately instead of handled as a custom services exception.

    Target Modes

    Multi-Tenant SaaS

    Shared runtime with tenant isolation at the data and authorization layers.

    Single-Tenant Managed Cloud

    ButtrBase runs a dedicated application stack, database, storage namespace, and secrets boundary for one customer.

    Single-Tenant BYOC

    ButtrBase deploys into customer-owned cloud infrastructure with customer networking and secrets controls.

    On-Prem / Air-Gapped

    ButtrBase ships as a packaged deployment inside customer infrastructure with minimal or no dependency on hosted ButtrBase services.

    Product Invariants

    These should stay stable across deployment modes:

  • same customer-facing API contract
  • same RBAC and entitlement model
  • same audit-event schema
  • same app, org, team, and identity object model

    • If a mode needs a capability difference, that difference should be explicit and documented.

    Architecture Direction

    Control Plane vs Runtime Plane

    Split the platform logically into:

  • control plane
  • runtime plane

    • For SaaS they may share infrastructure. For single-tenant and on-prem they should be deployable separately.

    Minimum Isolation For Single-Tenant

  • dedicated Postgres instance or database
  • dedicated object storage namespace
  • dedicated secret namespace
  • dedicated queue or worker namespace
  • dedicated provider credentials

    • Schema-only isolation is not enough for the single-tenant SKU.

    Billing Implications

    On-prem should not assume a shared ButtrBase-managed Stripe or PayPal account.

    Plan for three billing execution modes:

  • ButtrBase-managed provider accounts
  • customer-managed provider accounts
  • manual invoice mode

    • The pricing decision APIs should stay stable even if provider execution differs.

    Analytics Implications

    Keep the analytics contract stable, but vary the sink by topology:

  • shared warehouse for SaaS
  • isolated dataset or warehouse for single-tenant
  • local export or customer-owned telemetry stack for on-prem

    • Recommended Build Order

    1. add a first-class deployment_mode 2. make provider and storage configuration topology-aware 3. define the first managed single-tenant reference architecture 4. define the on-prem packaging, upgrade, and diagnostics story 5. document supported and unsupported capabilities per mode

    Related Docs

  • /docs/enterprise/enterprise-readiness
  • /docs/enterprise/rust-production-architecture
  • /docs/enterprise/staging-smoke-tests