Skip to main content

​
The Core Flow

Every deployment in Ctrlplane follows this flow:
  1. CI creates a version — After building, your CI tells Ctrlplane about the new version
  2. Policies are evaluated — Ctrlplane checks if approvals, dependencies, and gates are satisfied
  3. Job is dispatched — Ctrlplane tells your job agent (ArgoCD, GitHub Actions, etc.) to deploy
  4. Deployment executes — The job agent performs the actual deployment
  5. Verification runs — Ctrlplane checks metrics (Datadog, Prometheus, HTTP) to confirm health and can also validate resource presence/status (e.g., newly discovered clusters are visible and ready)
  6. Promote or rollback — If verification passes, continue; if it fails, roll back

​
The Key Entities

You only need to understand 5 things: In short: Deployments define what and how, Environments define where, and Policies define when.

​
How They Connect

When you deploy “API Gateway” to “Production” (which has 3 clusters), Ctrlplane creates 3 release targets:
  • API Gateway → Production → us-east-1
  • API Gateway → Production → us-west-2
  • API Gateway → Production → eu-west-1
Each release target can have its own policies, verification, and rollout timing. Advanced example: Version v1.2.3 of the “API Gateway” deployment targets the “Production” environment, which expands to multiple clusters including us-west-2. Ctrlplane creates one release target per cluster, so each target can be governed independently. A deployment window policy can be scoped to the us-west-2 release target so it only deploys on weekdays before 9 a.m., while other production targets follow their own timing. When a new version arrives, Ctrlplane waits for that window before dispatching the job for us-west-2, even if other targets can deploy sooner.

​
Dynamic Environments

Environments use selectors to automatically include resources:
When you add a new cluster with env: production metadata, it automatically becomes part of the Production environment. No config changes needed.

​
Policies Define When to Deploy

Policies are the rules that govern when a version is allowed to deploy: Policies use selectors to target specific releases:

​
Job Agents Execute Deployments

Ctrlplane doesn’t deploy directly—it tells job agents what to do: This means Ctrlplane works with your existing deployment tooling.

​
A Complete Example

  1. GitHub Actions builds v1.2.3 and creates a version in Ctrlplane
  2. Ctrlplane creates a release for staging
  3. ArgoCD deploys to staging
  4. Verification checks Datadog metrics
  5. Staging passes → production release is unblocked
  6. Production requires approval → team lead approves
  7. ArgoCD deploys to production
  8. Verification confirms production is healthy

​
What’s Next?

Quickstart

Build this pipeline yourself in 15 minutes

Use Cases

See specific deployment scenarios