Open source / GitOps-native / Vault-integrated / MIT

Turn your apps into templates for whitelabel products.

OpenTenant composes the Helm charts you already run into a declarative multi-tenant control plane. Each tenant gets its own release, secrets scope, domain, and configuration.

Start View Source

TENANCY

One release per tenant

SECRETS

Scoped in Vault

VALIDATION

Audited before runtime

Live control-plane model

See the platform coordinate every tenant boundary.

Git events enter through one reviewable manifest. Vault authorizes the exact secrets each release needs. OpenTenant compiles the graph, routes workloads to connected premium providers, and keeps every tenant in its own operational space.

Topology synchronized

7 providers / 4 tenant releases

Graph valid

0 cycles / 0 boundary violations

opentenant.yaml

# The whole SaaS — one manifest. One Helm release per tenant.
platform:
  cluster_domain: "opentenant.cloud"
  vault_root_path: "secret/data/opentenant/core"
  services:
    - id: "platform-routing-mesh"
      engine: docker-compose
      template_ref: git::github.com/org/routing-mesh

tenants:
  - id: "tenant-acme"
    vault_tenant_path: "secret/data/tenants/acme"
    userspace:
      kube_namespace: tenant-acme-prod
      domain: acme.opentenant.cloud
    deployments:
      - id: "acme-app"
        engine: helm                    # your chart, unchanged
        template_ref: oci://registry.org/your-chart
        config_patches:
          replica_count: 3
        dependencies:
          - "platform-routing-mesh"

Implementation Stack

Proven parts. No NIH required.

OpenTenant is the orchestration layer — underneath, it's built entirely on battle-tested infrastructure you already know.

System	Role in OpenTenant
HashiCorp Vault	The single source of truth for every secret. Per-tenant records are the contract between provisioning and deployment. Rotation flows through automatically.
Supabase	Platform auth (Supabase Auth + JWT guards), Management API for orgs/projects, Postgres per tenant, Storage, and OAuth2 "bring your own project" via Supabase Connect.
NestJS + TypeScript	The platform service — idempotent REST API for organizations, projects, tenant lifecycle, and the OAuth2 flow. Stateful secrets? Never. Everything in Vault.
Kubernetes	One Helm release per tenant. Namespaces as tenant boundaries. NetworkPolicies for pod-level isolation. Gateway API / Ingress for host-per-tenant routing.
Vault Secrets Operator	Reads tenant records from Vault and materializes them as Kubernetes Secrets inside the cluster.
Reloader	Watches tenant Secrets and rolls the exact pods affected by a credential rotation. Zero manual restarts, blast radius contained to one tenant.
External Secrets Operator	ClusterSecretStore backed by Vault — flat tenant registry where every key under `secret/metadata/tenants/` is one deployable tenant.
Terraform	Declarative tenant registry: one Vault entry → namespace + ExternalSecret + Helm release. Remove the entry, tear down all three.
Cloudflare	Edge SSL with Full (Strict), wildcard DNS `*.yourdomain.com`, WAF, WebSockets on, Origin CA certs on nginx-ingress, real client IPs via CF-Connecting-IP.
nginx / ingress-nginx	The egress controller — single entry point, path-routed single domain, streaming uploads, WebSocket-friendly, COOP/COEP headers.
GitHub / GitLab	GitOps source of truth for manifests and templates ( `git::` refs), CI-driven reconciliation, and container registries for OCI charts.
Docker Compose / PM2	First-class alternative engines for lighter workloads — same manifest, same validation, same Vault hydration.

HashiCorp Vault· secrets Supabase· auth & data NestJS· platform API TypeScript· end to end Kubernetes· runtime Helm· one release per tenant VSO· Vault → K8s Secrets External Secrets· flat registry Reloader· auto-roll on rotation Terraform· tenant IaC Cloudflare· edge & SSL nginx· egress controller GitHub / GitLab· GitOps Docker / PM2· alt engines

OpenTenant Mobile

One tenant contract. Every device your product ships to.

Model mobile delivery as infrastructure: GitLab starts the pipeline, Vault releases only the tenant-scoped credentials that build needs, and Expo targets mobile, TV, desktop, and connected-device experiences from one reviewable flow.

GitLab pipeline

Commit the release definition.

A reviewed pipeline identifies the tenant, target channels, Expo profile, and release version.

Tenant build cloud

Vault gate

Scoped signing keys and deployment secrets

Expo build profile

One configuration, channel-specific outputs

Mobile

iOS + Android

Living-room apps

Desktop

macOS + Windows

IoT

Edge devices

tenant_id → Vault pathrelease_channel → Expo profilecommit_sha → build provenanceenabled: false → access revoked

Tenant change service

Agents ship custom code without crossing tenant boundaries.

Every request receives an owner, an SLA clock, a scoped branch, and a review trail. Agents can change the tenant experience while validation, approval, secrets policy, and release isolation remain deterministic.

SLA active

Response window by tierEscalation thresholds enforcedClock visible to tenant

REQUEST

Tenant asks for a change

Portal, email, or voice intake becomes a scoped implementation brief.

tenant scoped

AGENT WORKSPACE

Custom code is edited

An agent works against the tenant’s branch, environment, and approved service boundary.

tenant scoped

REVIEW GATE

Checks run before merge

Diff review, tests, security policy, and explicit approval protect the shared platform.

tenant scoped

RELEASE

Only that tenant rolls

The approved change deploys to the tenant release with rollback provenance intact.

tenant scoped

Notification loop

No silent handoffs.

Operators and tenant stakeholders receive the right signal at every SLA transition.

Accepted · review ready · released

Voice

P1 alert · approval · escalation

SLA clock

Paused only on explicit tenant input

Technical library

Tenant infrastructure, explained end to end.

Architecture and security guides for platform teams operating isolated releases, secrets, networks, domains, and edge access.

09 / GUIDE

Kubernetes + Vault Tenant Isolation

From an Ubuntu cluster and external Vault to automated isolated releases.

Read guide → 10 / GUIDE

Cloudflare Zero Trust per Tenant

Private origins, explicit hostnames, and reviewable access policy on Kubernetes.

Read guide → 11 / GUIDE

NetworkPolicy Default Deny

Compile DNS, secrets, edge, and application paths for each tenant release.

Read guide → 12 / GUIDE

Vault Secret Rotation per Tenant

Synchronize credentials and roll only the workloads that actually depend on them.

Read guide → 13 / GUIDE

Tenant TLS + Domain Automation

Ownership, DNS, Gateway routes, certificates, renewal, and safe offboarding.

Read guide →

Use Cases

One orchestrator. Wildly different buildings.

The manifest doesn't care what it manages — processes, properties, or crops. If it can be declared, it can be tenanted.

The Main Case — SaaS

Any Helm Chart → SaaS

You built a great open-source app. Now ten thousand people want it "as a service." OpenTenant wraps your existing chart: each customer gets their own release, namespace, secrets, subdomain, and branding — from one manifest.

Your chart stays untouched — OpenTenant composes around it
Self-serve onboarding: user connects their project → tenant record in Vault → VSO + Reloader deploy it
Credential rotation rolls only that tenant's pods
Whitelabel: their domain, their theme, their data — your platform

Real Estate — IoT

The Airbnb of Commercial Real Estate

Point OpenTenant at physical space and a tenant becomes an office, retail slot, or clinic floor. Templates become device behaviors. Vault holds the cryptographic keys to the actual door locks.

Lease = userspace: locks, HVAC, badges, sensors scoped to one suite
Hosts list space like an Airbnb listing; guests get time-scoped access via the same dependency graph
Vault-native secret rotation = physical key rotation, automatically
Static validation means no tenant's automation can touch another's

Agriculture — AgTech

The Operating System of Vertical Farms

Every grow rack is a tenant. Each farm runs its own "release" of the cultivation stack — irrigation schedules, lighting curves, climate recipes — declared as versioned templates and patched per crop.

Rack = tenant: its own sensors, actuators, and namespace
Light recipe for basil is a template; the basil farm patches the photoperiod
Secrets to irrigation controllers live in Vault, rotated automatically
A failed pump in rack 7 triggers a rollout of exactly one release — not the whole farm

Whitelabel Platforms

Your Software, Their Logo

Agencies and OEMs resell software under their own brand. OpenTenant gives each reseller a fully isolated userspace with custom domain, theme, and service mix — while you operate one platform.

Onboarding a reseller = one YAML block
Offboarding = enabled: false
Rebranding = one field in their userspace
All secrets scoped per reseller — they can't see each other, ever

Built-in Safety

Audited before anything runs.

No deployment runs without passing the static validation engine — and isolation is enforced below the application layer.

✓Cycle detection.Circular dependencies are flagged statically — construction stops before the cement is poured.

✓Missing-link checks.Every dependency must resolve to a defined node. No dangling references, ever.

✓Cross-boundary validation.Tenants may depend on platform services — never on each other's internals.

✓Vault scoping.Secrets resolve per-tenant. The platform orchestrates keys it can never read.

✓Idempotent everywhere.Tenant creation checks Vault first; migrations are safe to retry; keys are get-or-create.

✓Network isolation.NetworkPolicies enforce that tenant A's pods can never reach tenant B's — below the app layer.

Evaluation path

Inspect the boundaries before you adopt the control plane.

OpenTenant separates declarations, execution, and secrets so your team can review each concern independently. The orchestration layer composes the system; it does not replace the infrastructure you already trust.

Inspect the current implementation →

INPUT

Your existing deployment artifacts

Keep your Helm charts, Docker Compose files, or PM2 configs. OpenTenant references versioned templates instead of forking them.

CONTROL PLANE

A manifest that declares tenancy

Platform services, tenant userspaces, config patches, and dependencies live in one reviewable YAML contract.

GUARDRAILS

Boundaries checked before runtime

Cycle, missing-link, and cross-tenant dependency checks run before the engine provisions or deploys a workload.

RUNTIME

Isolation below the application layer

Dedicated releases and namespaces separate workloads, while scoped Vault paths and NetworkPolicies separate credentials and network access.

Architecture

From a git push to a running tenant.

The manifest is a composition and bindings engine — raw execution lives in templates, secrets live in Vault, and the engine compiles it all. One Helm release per tenant, always.

STEP 01 — DECLARE

Write the manifest

Define platform services, tenant userspaces, and their deployments in one YAML file. Commit it to your GitOps repo — GitHub or GitLab.

STEP 02 — VALIDATE

Static topology audit

The engine detects dependency cycles, missing links, and unsafe cross-tenant boundaries — before anything touches runtime.

STEP 03 — PROVISION

Hydrate via Vault

Templates are fetched, config patches applied, and every tenant record written to Vault. The Vault Secrets Operator turns records into Kubernetes Secrets; Reloader rolls pods on credential rotation — automatically.

STEP 04 — DEPLOY

One release, one tenant

Each tenant gets their own Helm release, namespace, Ingress, and subdomain — routed through Cloudflare with wildcard DNS and TLS. Zero manual steps per tenant.