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:
EntityQuestion It AnswersExample
ResourceWhat infrastructure exists?prod-us-east-1 K8s cluster
DeploymentWhat to deploy and how”API Gateway” deployed via ArgoCD
EnvironmentWhere to deploy”Production” = all clusters with env: prod
VersionWhich build to deploy?v1.2.3 or sha-abc123
PolicyWhen to deploy”After staging succeeds and SRE approves”
In short: Deployments define what and how, Environments define where, and Policies define when.

​
How They Connect

Deployment × Environment × Resource = Release Target
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: 
type: Environment
name: Production
resourceSelector: resource.metadata["env"] == "production"
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:
PolicyWhat It Does
ApprovalRequire sign-off before deploying
Environment ProgressionWait for staging before prod
Gradual RolloutDeploy to targets one at a time
VerificationCheck Datadog/Prometheus metrics
Deployment WindowOnly deploy during certain hours
Policies use selectors to target specific releases: 
type: Policy
name: production-approval-policy
description: Production Approval Policy
selectors:
  - environments: environment.metadata['requires-approval'] == 'true'
rules:
  - approval:
      required: 1

​
Job Agents Execute Deployments

Ctrlplane doesn’t deploy directly—it tells job agents what to do:
AgentWhat It Does
GitHub ActionsTriggers workflow dispatch
ArgoCDCreates/syncs ArgoCD Applications
Terraform CloudTriggers Terraform runs
KubernetesApplies manifests directly
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