Deployment Zones
Map your topology.
Define the logical environments where your customer instances run — cloud regions, private VPCs, on-premises clusters, or any logical grouping.
Orchestration & Deployments
Map your contracts to your clusters.
Track which release runs for which customer, in which deployment zone. Kaiten doesn't replace your GitOps — it keeps the record your pipelines report, next to the license each customer runs.
Your deployment pipeline is contract-blind.
Argo CD deploys. Flux syncs. GitHub Actions runs. But none of them knows which customer runs which release, under which license.
What Sales knows
Acme Corp
Enterprise Plan
Zone: EU-West
What DevOps sees
k8s-eu-west-1
namespace: acme
version: ???
What actually runs
??? v1.9 or v2.1
entitlements: ???
license: ???
With Kaiten: one source of truth for all three.
Your infrastructure, orchestrated by the business.
Instance Management
Every customer deployment, accounted for.
An instance binds a customer, the license version it runs with its dates, and the deployment zone it runs in, into one tracked entity with a health status and a lifecycle.
Component & Release Tracking
Know exactly what's running, everywhere.
Model your delivery chain with components and immutable releases. Record the release each zone runs — your pipeline deploys it — and know exactly which version of which service runs for which customer.
GitOps Integration Loop
We don't replace your pipelines. We keep their record.
Business events reach your CI/CD — as signed webhooks on Kaiten Cloud, on the event stream when you self-host. Your pipeline deploys, then reports through the API the release a zone now runs. The console shows what your pipelines reported.
Event-Driven Automation
55 events. Any automation you write.
Every state change commits a typed event through the transactional outbox, delivered at least once — as a signed webhook on Kaiten Cloud, on the event stream when you self-host. Trigger any downstream system.
The GitOps integration loop.
kaiten CLI
# Step 1: Kaiten emits an event on business changes
# (a signed webhook on Kaiten Cloud, the event stream when you self-host)
# → Your CI/CD provisions the namespace, deploys the release
# Step 2: Your pipeline records which release the zone now runs
$ kaiten deployment-zones update eu-west-1 --file zone.yaml
# Step 3: And reports what the instance consumes
$ kaiten instances usage report acme-production seats \
--value 187 --behavior set
# ✓ Loop closed: the console shows what your pipeline reported.# Step 1: Kaiten emits an event on business changes
# (a signed webhook on Kaiten Cloud, the event stream when you self-host)
# → Your CI/CD provisions the namespace, deploys the release
# Step 2: Your pipeline records which release the zone now runs
$ kaiten deployment-zones update eu-west-1 --file zone.yaml
# Step 3: And reports what the instance consumes
$ kaiten instances usage report acme-production seats \
--value 187 --behavior set
# ✓ Loop closed: the console shows what your pipeline reported.Two models. Same control plane.
The same Kaiten API records both ways of running your SaaS. Your SDKs, console and automation logic are identical.
Multi-tenant SaaS
Customers on shared infrastructure
- Instances are logical — one per customer, on shared infrastructure
- One deployment zone serves many customers
- A release reaches every customer in the zone at once
Dedicated deployments
Isolated infrastructure per customer
- Instances are physical — dedicated VPCs, isolated clusters, on-premises
- Each customer can run its own release, in its own zone
- Common in regulated industries: healthcare, defense, finance