GitOps is a new way of managing cloud infrastructure and deploying applications. Built on some familiar and recognizable developer workflows, GitOps helps you automate infrastructure changes, improve system reliability, and simplify continuous delivery.
In this tutorial, you’ll learn what GitOps is, how it works, the tools behind it, and how to implement a GitOps pipeline using Kubernetes and Hostman-compatible workflows.
GitOps working scheme
GitOps is a set of practices that uses Git repositories to manage both application code and infrastructure configurations. With its help, developers can get rid of using traditional manual revisions or ad hoc scripts, GitOps relies on Git as the authoritative source for your system’s desired state. This means your cluster configuration, deployment manifests, Helm charts, and more are stored and managed within a single Git repo.
So, when you need to update infrastructure or release a new application version, you simply commit a change to Git. GitOps controllers then detect the change and automatically update the live environment to match. This shift brings the principles of software development—such as version control, collaboration, and CI/CD—to operations teams.
GitOps is especially valuable in cloud-native environments, where teams work with Kubernetes or similar orchestration tools.
GitOps is a kind of workflow where infrastructure is treated as code (not as a full app or environment), stored in Git. It also reconciles with the actual running environment. This ensures consistency, traceability, and security throughout the deployment lifecycle.
GitOps was created as the main tool to control your apps and infrastructure like the unified entity, which you control from a single Git repository. But how does it work? It’s simple - continuous reconciliation. A GitOps controller constantly checks for differences between the actual state of your infrastructure and the desired state stored in Git.
If the live state drifts (due to unnecessary or planned changes) the controller detects the inconsistency and automatically reverts the environment back to the last known perfect state as defined in Git. This is something that makes GitOps a very useful tool.
GitOps relies on several open-source tools that integrate with your existing CI/CD stack. Here's a quick overview of the most popular options:
Argo CD is a declarative continuous delivery tool built for Kubernetes. It syncs your manifests from Git to your clusters and helps you visualize deployment status.
Flux automates Kubernetes deployments using Git as the source of truth. It's lightweight and integrates well with Helm charts.
Helm is a Kubernetes package manager. It makes application definitions simpler and is often used in GitOps to manage complex deployments.
Let’s not forget that Terraform is not GitOps-native, It’s mainly used in GitOps pipelines for managing infrastructure outside Kubernetes, for example DNS.
A typical GitOps workflow involves several tightly integrated steps that form a reliable deployment pipeline. Let’s walk through the process from code commit to live deployment.
The separation between CI and CD in this model ensures that your team remains focused on writing and testing code, while deployment and environment reconciliation are fully automated. This reduces risk, accelerates delivery, and improves infrastructure transparency.
GitOps offers several advantages for modern DevOps teams:
Here’s a basic example of setting up a GitOps pipeline using Argo CD on a Kubernetes cluster. For Hostman, you can adapt these steps using custom infrastructure.
Create a namespace for Argo CD:
kubectl create namespace argocd
Install Argo CD:
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Forward the Argo CD API server port:
kubectl port-forward svc/argocd-server -n argocd 8080:443
Visit https://localhost:8080 in your browser. Login with the default admin user and password (retrieved from the secret).
Now let’s connect your Git repository to Argo CD to start syncing Kubernetes manifests.
In your Git repo, create a Kubernetes manifest, for example deployment.yaml
:
apiVersion: apps/v1
kind: Deployment
metadata:
name: hostman-web
spec:
replicas: 2
selector:
matchLabels:
app: hostman-web
template:
metadata:
labels:
app: hostman-web
spec:
containers:
- name: web
image: hostman/web-app:latest
Commit and push the file to Git.
Use the Argo CD CLI or web UI to create a new application:
argocd app create hostman-web \
--repo https://github.com/your-user/your-repo.git \
--path ./k8s \
--dest-server https://kubernetes.default.svc \
--dest-namespace default
Synchronize the app:
argocd app sync hostman-web
Argo CD will now monitor your repo and update the deployment automatically.
While GitOps offers many benefits, there are some challenges to consider:
Git conflicts: When multiple teams edit code it can lead to some troubleshooting.
Secret management: Git is a more “social” tool, when it comes to storing your secrets, so it’s better to use something else.
Complexity at scale: Managing many environments and repositories sometimes becomes chaotic without proper management.
Planning ahead and using a modular approach (e.g., mono or multi-repo strategies) can help mitigate these issues.
GitOps the bringer of power of Git to your infrastructures. GitOps is seeing your infrastructure as code and automates reconciliation, also let’s not forget that this instrument can enhance visibility, consistency, and deployment speed of your state of art work.
GitOps is a tool to manage infrastructure and deployments using Git as the single source of truth.
While GitOps is a perfect fit for Kubernetes (because of its declarative nature), it’s not limited to it. You can apply GitOps principles to other infrastructure types too.
Popular GitOps tools include Argo CD, Flux, and Jenkins X. If you're using Hostman, you can easily integrate Git-based workflows with Kubernetes and start automating deployments right away.
Not really. GitOps works with the Git workflows you're already using — like branches, pull requests, and commits. What changes is how those commits impact your infrastructure: once merged, your environment syncs with your repo automatically.