GitOps
Continuous deployment for Kubernetes, where the only way into the cluster is a commit.
copebit has been building container platforms since 2018, across Docker, Kubernetes and ECS. As clusters grew and service counts rose, two things stopped scaling: large Terraform stacks, and push-based CD pipelines that needed credentials pointing into the cluster.
So we moved continuous delivery and in-cluster operations to GitOps. Deployments became faster, incremental and lower risk, and the same model now sits underneath the platforms we build.
How it works
Flux treats Git as the single source of truth for infrastructure and application configuration, and continuously reconciles the live cluster against it. Changes reach Kubernetes declaratively, and the deployment history writes itself.
Git hosting matters more than teams expect, because a stable repository is what makes operations stable. We use GitLab.com or GitHub.com, or a self-hosted equivalent. Secrets stay in AWS Secrets Manager or HashiCorp Vault, and Flux status appears inside GitLab, where developers already work.
Secure operation
Flux pulls, nothing pushes in. Clusters stay fully private with no exposed endpoint, and DevOps engineers run with reduced permissions because Git is the interface.
Pull based
Flux runs as a Kubernetes controller connected to a Git repository. Changes are applied as native Kubernetes objects using standard manifests, with no extra abstraction layer in between.
Complete control
The cluster reconciles against the repository continuously, and anything changed by hand is reverted automatically. That is the immutability firewall: the only way in is a commit, so configuration drift has nowhere to hide.
Native developer tools
Developers commit, review and merge in the tools they already use. Once review completes, the controller pulls the change into the cluster. There is no new console to learn.
Deployment options
Kubernetes manifests, Helm charts and Kustomize files. Flux syncs from Helm registries and other OCI-compliant repositories as well as Git, and the same artifact types work with other GitOps controllers such as Argo CD.
Promoting changes across environments
Git branching strategies roll a change through staging, then prod-eu, then prod-us in sequence. Each environment reconciles from its own branch, so a change is proven in one before it reaches the next, and rolling back is a revert rather than an incident.
Still changing clusters by hand?
Most GitOps reviews start with what happens when someone edits the cluster directly.