Deploying Containers from CI/CD

Once a container image is built, scanned, and pushed to a registry, the pipeline's final job is to get that image running in a target environment — a Kubernetes cluster, a serverless container platform like AWS Fargate or Cloud Run, or a simpler VM-based Docker host. How this happens varies enormously across organizations, ranging from a pipeline directly issuing imperative commands against an API, to a fully declarative GitOps model where the pipeline's only job is to update a manifest and a separate controller handles the actual rollout. Understanding these patterns, and their tradeoffs around auditability, blast radius, and rollback speed, is central to designing dependable container deployments.

In a push-based model, the CI pipeline itself has credentials to the target environment and directly issues the update — running kubectl set image, calling a cloud provider's deploy API, or executing a Helm upgrade. This is simple to set up and gives immediate feedback within the pipeline about whether the deployment succeeded. The tradeoff is that the pipeline now holds powerful, often broad, credentials to production infrastructure, and any pipeline misconfiguration, malicious code injection, or compromised CI runner has a direct path to modifying production. Push-based deployment also means the actual state of the cluster can drift from what's declared in git if anyone runs manual kubectl commands outside the pipeline.

In the GitOps model, the CI pipeline's only responsibility after pushing an image is to update a manifest in a separate 'deploy' git repository (or a designated path in the same repo) to reference the new image tag, then open or auto-merge a commit. A cluster-resident controller — Argo CD or Flux are the dominant tools — continuously watches that repository and reconciles the live cluster state to match it, pulling the change rather than the pipeline pushing it. This inverts the trust model: the CI pipeline never holds cluster credentials at all, only git write access, while the in-cluster controller holds the deployment credentials and is the only thing that can modify the cluster. This significantly shrinks the blast radius of a compromised CI pipeline and gives a full audit trail of every deployment as git commits.

Regardless of push or pull model, a responsible deployment pipeline does not consider the job done the moment a new image reference is applied — it must verify the new version is actually healthy before declaring success. This typically means polling readiness/liveness probes, checking that the expected number of replicas reached Ready state within a timeout, and optionally running smoke tests against the newly deployed endpoint. Pipelines that skip this step can report a false 'deployment successful' status while pods are actually crash-looping in production.