ArkCD: continuous delivery with rollback that actually fires
Declare the desired state, let ArkCD reconcile it, and watch a progressive rollout that halts itself on the metrics you chose rather than on someone noticing.
What is ArkCD?
ArkCD is the DevOpsArk continuous delivery engine that reconciles environments against a declared desired state, runs progressive rollouts, detects configuration drift and rolls back automatically when release health degrades.
What ArkCD is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- Deployments succeed and the service still breaks, because "deployed" and "healthy" are not the same check.
- Rollback is a manual runbook executed under pressure by whoever is awake.
- Configuration drifts between what is in Git and what is in the cluster, and nobody finds out until the next deploy overwrites a hotfix.
- Canary releases are talked about but not run, because wiring metrics into the rollout is a project of its own.
- Multi-environment promotion is a sequence of copied YAML files with hand-edited differences.
ArkCD holds the desired state for each environment and continuously reconciles the live environment against it. When a new artifact is released, the rollout strategy for that environment decides how traffic moves: all at once for a development namespace, canary with a metric gate for production. During a progressive rollout ArkCD watches the success rate, latency and error signals you nominated, and if any of them degrade past its threshold it stops advancing and reverts, without waiting for a human. Between deployments it keeps comparing live state against desired state, so a manual change made directly in a cluster is reported as drift with a diff, and can be reverted or adopted deliberately rather than discovered by accident.
What ArkCD does
The 8 capabilities that make up ArkCD.
Declarative reconciliation
Desired state is the source of truth. ArkCD converges the environment towards it continuously, not only at deploy time.
Progressive rollouts
Canary, blue/green and rolling strategies with per-environment configuration, traffic weighting and pause points.
Metric-gated promotion
A canary advances only if the success rate, latency and error metrics you nominated stay inside their thresholds.
Automatic rollback
A rollout that breaches its gate reverts to the last known-good revision on its own, and records why.
Drift detection
Live state is compared against desired state continuously. Manual cluster changes surface as a diff you can revert or adopt.
Environment promotion
Promote the same digest from development to staging to production, with per-environment configuration held separately from the artifact.
Approval and change windows
Require named approval or restrict deployment to a change window, enforced by the delivery engine rather than by convention.
Deployment provenance
Every release records the digest, the approver, the strategy, the gate results and the outcome.
How ArkCD fits together
Outcomes
- Bad releases stop themselves before most users see them.
- Rollback is a property of the system, not a runbook someone has to find.
- Cluster drift is reported the day it happens instead of the next time a deploy overwrites it.
- The same artifact moves through every environment, so staging genuinely tests production.
- Deployment approvals and change windows are enforced instead of documented.
Using ArkCD, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Declare desired state
Point ArkCD at the repository, chart or overlay that describes the environment.
- 2Release an artifact
A verified image digest from ArkBuilder or your CI system is released to the environment.
- 3Roll out progressively
Traffic shifts according to the environment strategy, pausing at each configured step.
- 4Check the gate
Success rate, latency and error metrics are compared against thresholds before the rollout advances.
- 5Promote or revert
A healthy rollout completes; a breached gate reverts to the last known-good revision automatically.
- 6Reconcile continuously
ArkCD keeps comparing live against desired state and reports drift.
Where teams apply ArkCD
Run canary releases with a real gate
Nominate the success-rate and latency signals that define a healthy release and let the rollout enforce them.
Standardise promotion across environments
Promote one digest through every environment with configuration held per environment rather than per copy of the manifest.
Enforce change windows
Restrict production deployment to approved windows, with break-glass recorded rather than untracked.
Recover from a bad release without a runbook
The rollout reverts itself and posts the gate result that triggered it.
What ArkCD works with
Named integrations link to their own page. The rest are supported runtimes and formats.
ArkCD: frequently asked questions
The 10 questions teams ask most often before adopting ArkCD.
ArkCD is the DevOpsArk continuous delivery engine. It reconciles each environment against a declared desired state, runs progressive rollouts with metric gates, detects configuration drift, and rolls back automatically when a release degrades.
It follows the GitOps model (the desired state lives in a repository and the platform converges the environment towards it), and adds progressive rollouts, metric gates and automatic rollback on top of plain reconciliation.
You nominate the signals that define a healthy release, typically success rate, latency percentile and error rate. During a progressive rollout ArkCD evaluates them at each step. If a threshold is breached, the rollout stops advancing and reverts to the last known-good revision, and records the gate result that caused it.
A canary deployment sends a small share of traffic to a new version while the rest continues to the current one. If the new version behaves correctly under real traffic, its share increases in steps until it takes everything. If it does not, only the small share was exposed.
Drift is the difference between the state you declared and the state actually running, usually caused by a manual change made directly in a cluster. ArkCD compares the two continuously and reports the diff, so you can revert it or adopt it deliberately.
Yes. A single release can target Kubernetes clusters across AWS, Azure, Google Cloud and on-premises, each with its own rollout strategy, configuration and approval requirements.
Yes. ArkCD can operate alongside an existing Argo CD installation, reading its applications and sync status into the DevOpsArk inventory, or it can take over reconciliation entirely. Teams commonly start with the first.
Yes. Desired state can be expressed as plain manifests, a Helm chart with values per environment, or a Kustomize base with overlays.
Configuration is held per environment and separately from the artifact, so the same image digest is promoted from development to production unchanged. Only the configuration differs.
Pipelines produce and verify the artifact: build, test, scan, package. ArkCD delivers it: reconcile, roll out, gate, roll back. The handover between them is an image digest, so what was verified is exactly what is deployed.
See ArkCD against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.