> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Push vs Pull Based Deployments
> Explains push versus pull (GitOps) Kubernetes deployment models, comparing workflows, access patterns, benefits, and secret and credential management.
What are push- and pull-based deployments?
Deployment workflows for Kubernetes generally follow one of two patterns: push-based (traditional CI/CD) or pull-based (GitOps). Both move built container images to a registry, but they differ in who applies the changes to the cluster and where deployment intent is stored.
## Push-based deployments (CI/CD-driven)
In a push-based model the CI/CD system builds the application, publishes container images to a registry, and then actively pushes the resulting manifests or executes `kubectl`/`helm` commands against the cluster to deploy changes.
Typical access patterns:
* CI/CD system:
* Read-only access to the Git repo (source code and manifests).
* Read-write access to the container registry (to push images).
* Read-write access to the Kubernetes API (to apply manifests or run `kubectl`/`helm`).
* Kubernetes cluster:
* Pulls images from the container registry (read-only to registry).
Benefits of push-based workflows:
* Flexible tooling and integrations (e.g., [Jenkins](https://www.jenkins.io/), GitHub Actions) with direct `kubectl`/[Helm](https://helm.sh/) support.
* Pipelines can inject secrets stored in the CI system to simplify deployments.
* Centralized control: build artifacts and deployment jobs live together in the CI environment.
Common challenges with push-based workflows:
* Deployment logic is coupled to the CI system; migrating CI platforms often requires reimplementing deployment steps.
* CI must hold cluster credentials (a `kubeconfig` or token) with write privileges, increasing attack surface if the CI system is compromised.
* Managing multi-tenant or team-scoped deployments from a single CI pipeline becomes complex.
## Pull-based deployments (GitOps)
Pull-based deployments, often called GitOps, move the act of applying changes into the cluster. A GitOps operator (for example [Argo CD](https://argo-cd.readthedocs.io/) or [Flux](https://fluxcd.io/)) runs inside Kubernetes and reconciles the cluster state against a declared desired state stored in Git or a registry. The operator watches for manifest changes or new image tags and applies updates automatically.
In a pull-based model:
* CI/CD still builds images and pushes them to the container registry (read-write to registry).
* The in-cluster operator has read access to Git (or the registry) and the permissions necessary to apply changes to the cluster — external CI systems do not directly write to the Kubernetes API.
* No external system needs routine write access to the Kubernetes API.
Benefits of pull-based (GitOps) workflows:
* Decouples deployment from CI: any CI system can build and push artifacts; the cluster decides when to apply them.
* Reduces the need to store cluster write credentials outside the cluster.
* Easier multi-tenancy: operators can sync different repos to different namespaces or clusters.
* Declarative infrastructure: manifests and encrypted secrets live in Git and are reconciled by the operator. Operators can also detect new image tags and drive automated rollouts.
Challenges with pull-based workflows:
* Secrets must be encrypted before committing to Git (tools such as [Mozilla SOPS](https://github.com/mozilla/sops), [Bitnami Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets), or integration with [HashiCorp Vault](https://www.vaultproject.io/) are common solutions). An operator or sidecar controller needs the ability to decrypt or inject secrets at deploy time.
* Rendering templated artifacts (for example [Helm](https://helm.sh/) charts) can require an extra rendering step or an operator extension to supply secret values securely prior to applying manifests.
Avoid placing long-lived cluster admin credentials in your CI system. If CI must access the cluster, prefer short-lived tokens, least-privilege RBAC, and strong auditing.
Not only for Helm charts, these same secret-management trade-offs apply to generic secret deployments and other templated workloads.
Choose push-based workflows when you need tight control from the CI runner and simple secret injection from the pipeline. Choose pull-based (GitOps) workflows when you want declarative, cluster-driven reconciliation, better separation of concerns, and fewer external systems holding cluster write access.
## Quick comparison
| Aspect | Push-based (CI/CD) | Pull-based (GitOps) |
| - | - | - |
| Who applies changes | CI server runs `kubectl`/`helm` or API calls | In-cluster operator (e.g., Argo CD, Flux) reconciles desired state |
| Where deployment intent lives | CI pipeline or artifact | Git repository / container registry |
| Cluster credentials | Stored in CI (write access) | Only operator in-cluster needs write access |
| CI portability | Tightly coupled to CI implementation | CI-agnostic — any CI can build and push artifacts |
| Secret management | CI injects secrets at runtime | Secrets must be encrypted in Git or injected by a controller |
| Templating (Helm) | CI can render & apply templates | May require pre-render or operator support to render securely |
## References and further reading
* [GitOps — The Vendor Neutral Guide](https://www.gitops.tech/)
* [Argo CD Documentation](https://argo-cd.readthedocs.io/)
* [Flux CD](https://fluxcd.io/)
* [Mozilla SOPS](https://github.com/mozilla/sops)
* [Bitnami Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets)
* [HashiCorp Vault](https://www.vaultproject.io/)
That is the difference between push- and pull-based deployment models.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.