Skip to main content

The "GitOps-Lite" Pattern for Small Projects

· 3 min read
Ivan Baha
Ivan Baha
Software Team Lead & Architect

When setting up CI/CD for test or staging environments, we immediately want to reach for managed Kubernetes clusters like EKS or GKE. However, for small teams of 1-5 developers and tight budgets, it may not be the best way. A dedicated DevOps specialist and a $70-$100 monthly overhead just for the control plane, on top of main resource costs, sounds a bit extra.

The "GitOps-Lite" Pattern​

You can achieve the reliability of GitOps - versioned infrastructure state and automated reconciliation - without the heavy tooling. By utilizing GitHub Actions, Docker Compose, and a simple cloud VM, you completely decouple your application code from your infrastructure state.

Here is how the three-stage pipeline allows that:

  1. Build & Publish (The Source): Pushing (merging) to the main branch executes automated quality gates and tests. Then, it builds a semantically tagged Docker image and pushes it to your container registry.

  2. Update State (The Handshake): A CI workflow automatically updates the docker-compose.yml in a dedicated Infrastructure Repository. It uses basic Linux tools like sed or yq to modify the deployment manifest to the new version.

  3. Surgical Deployment (The VM): The infrastructure update triggers a final SSH deployment to the Virtual Machine. A bash script uses "Smart Routing" by reading the commit message to pull and restart only the newly updated service, leaving the rest of the environment untouched.

Real-World Application​

I've utilized this setup extensively because the efficiency is unbeatable for staging environments. A brief, sub-5-second deployment downtime is acceptable in this case. Secrets are kept simple using service-specific .env files stored directly on the VM filesystem. The operational cost stays extremely low while Git history acts as a perfect, atomic audit log.

Best of all, it scales naturally. If a service becomes too resource-heavy, you can split it onto a dedicated VM while keeping the centralized configuration repo. If you eventually need zero downtime, you simply place a Load Balancer in front of two identical VMs and update the action to deploy to them sequentially.

In addition, if you need to move the environment to another cloud provider or cut it down while development is on pause, you’ll be able to spin it up again very easily, as all needed configs (except for sensitive creds, of course) are stored in the Infra repo.

That’s how it has worked for me for more than 2 years, and it can be adopted by almost anyone effortlessly. Find more details in the full Reference Architecture, including the docker-compose and GitHub Actions workflow templates.

DOI