# Burrito, a Kubernetes operator that keeps Terraform plans running > padok-team/burrito is a TACoS operator that plans Terraform continuously, applies when the plan calls for it and opens pull requests from the result, aimed at the state drift problem Terraform leaves open. It supports Terraform and OpenTofu, runs on Kubernetes with a controller-runtime backend, and its own README warns that versions below 1.0 can introduce breaking changes. **padok-team/burrito** — 🌯 Burrito is a TACoS Kubernetes Operator - "Argo CD for Terraform" - Repository: https://github.com/padok-team/burrito - Website: https://docs.burrito.tf - Stars: 762 · Forks: 69 - Language: Go - License: Apache-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/padok-team-burrito ## The problem Burrito is aimed at Burrito is a TACoS Kubernetes Operator, which the README expands as Terraform Automation Collaboration Software, and it describes itself as an Argo CD for Terraform. The three problems it names are the ones that make Terraform operationally awkward. The first is state drift. Terraform is a tremendous tool to manage infrastructure as code, the README says, but it lacks built-in solutions for managing state drift, meaning the reality of a cloud account diverging from what the code says. Terraform only notices when someone runs plan, and by then the drift has been there for however long. The second is the CI/CD pipeline. Configuring a pipeline for Terraform is described as challenging and as often varying depending on the selected tools, which means every organisation reinvents the same plan-and-apply pipeline. The third is visibility. There is no easy way to navigate your Terraform state to truly understand the modifications it undergoes when running terraform apply, so a reviewer looking at a pull request has to trust the plan output rather than understand the state change. Burrito's three answers map to those three problems: it plans your Terraform code continuously and runs applies if needed, it offers an out-of-the-box pull request or merge request integration so you do not write CI/CD pipelines for Terraform ever again, and it shows your state's modifications in a simple web UI. The pull request integration is the design decision that makes the whole thing different from a cron job running plan. If a plan produces a diff, the change arrives as something a human reviews and merges, which means the drift is fixed through the same review path as any other code change. That is the Argo CD analogy working: a controller that reconciles reality against a desired state, and a change in reality becomes a change in the repository. ## How it is built and what it depends on Burrito is a Go operator on Kubernetes, and the module path in go.mod is github.com/padok-team/burrito with Go 1.26.0 and a toolchain directive for go1.27.1. The Kubernetes side uses controller-runtime v0.25.1 with client-go and apimachinery at 0.37.1, which is the standard operator stack: a controller that watches resources, reconciles them and owns their lifecycle. The Terraform side is not a Terraform plugin. Burrito drives the tool from outside, and the dependency list shows how: hashicorp/hcl/v2 and hashicorp/terraform-json for parsing configuration and plan output, tofuutils/tenv/v4 for provisioning the OpenTofu binary itself, and gruntwork-io/go-commons as the shared library that tool wrappers tend to use. The cloud SDKs are what let it read the real infrastructure for drift detection rather than relying only on the plan. There is aws-sdk-go-v2 with smithy-go, the Azure SDK with azidentity and azblob, and cloud.google.com/go/storage with google.golang.org/api. So it can look at what is actually deployed in AWS, Azure and Google Cloud and compare it against the plan. The remaining dependencies are the ordinary parts of a Go service: ghodss/yaml for configuration, blang/semver for version handling, hashicorp/go-multierror for aggregating failures, sirupsen/logrus for logging, and stretchr/testify plus ginkgo and gomega for tests. google/go-github and bradleyfalzon/ghinstallation are for the GitHub integration, and labstack/gommon provides the colour and terminal helpers. The GitHub dependencies are worth noting because they point at the shape of the tool. Burrito reads Terraform plans from somewhere, compares them against a branch, and opens a pull request, which means it needs to clone the repository, run the tool, and push a branch. That is a lot of permissions to grant a controller in your cluster, and it is the operational consideration to weigh before deploying it. The topics also list Terragrunt, which tells you the community around Burrito is the Terragrunt and OpenTofu ecosystem rather than the older Terraform Cloud one. ## Building it, the UI and the documentation pipeline The Dockerfile is a multi-stage build that shows the project's structure without needing to read the tree. The first stage builds the UI with pnpm from the ui/ directory, installs dependencies with a frozen lockfile and sets VITE_API_BASE_URL to /api before running the build, so the front end talks to the backend through the same origin. The second stage builds the manager binary with Go on Alpine, copying go.mod and go.sum first and running go mod download so that source changes do not invalidate the dependency layer. The UI build output is then copied in as internal/server/dist, which means the compiled front end is embedded in the Go binary and served from it. There is no separate UI container to deploy. The build arguments are deliberate. BUILD_MODE can be Debug or Release, and PACKAGE names the Go package path. The comment on the TARGETOS and TARGETARCH arguments explains the reasoning: the GOARCH has no default value so that the binary is built for the platform the command was called on, which ensures the container and the binary shipped on it match rather than producing an amd64 binary on an Apple Silicon machine. The repository top level shows the rest. There is api/, cmd/ and internal/ for the Go code, ui/ for the front end, manifests/ for the Kubernetes manifests, deploy/ for deployment configuration, docs/ for the documentation, hack/ for development scripts, testdata/ for fixtures, a Makefile, a Dockerfile, and a main.go. There are also a VERSION file and a PROJECT file, the latter being the Kubebuilder convention for operator metadata. The tooling is a mix of languages, which is normal for a project with a Kubernetes operator, a web front end and a documentation site. The root package.json is minimal and handles commit linting, with pnpm and Node 26 pinned through devEngines. The pyproject.toml is the documentation build, using zensical and mike, with mike pulled from a pinned git revision. There is a mise.toml for tool versions, renovate.json for dependency updates, an AGENTS.md and a CLAUDE.md for agent instructions, and codecov.yml for coverage. The documentation itself is at docs.burrito.tf, and the README points at a contribution guide there rather than in the repository. Two blog posts from Theodo Cloud explain the thinking, one on what a TACoS is and one on what challenges the project solved, and there is a Devoxx France 2025 presentation video with the note that the English version is auto-translated. ## What running Burrito in a cluster actually involves The operational side is worth thinking through before you install it, because an operator with cloud credentials is a different security proposition from a CI job. Burrito needs to reach your repositories. It clones the Terraform code, runs the tool, and pushes a branch to open the pull request, which is why the go.mod includes google/go-github and bradleyfalzon/ghinstallation for GitHub authentication. In a GitHub-flavoured setup that means a GitHub App or a token with write access to the repositories you point it at, and that credential lives inside the cluster. It also needs credentials for the cloud providers, because detecting drift means reading the deployed infrastructure rather than only comparing plans. The AWS, Azure and Google Cloud SDKs in the dependency list are there for that. The good practice is to give it read-only credentials for the provider accounts and let the pull request be the mechanism by which changes get applied, rather than giving it apply rights, but the README does not prescribe this and you have to decide it yourself. The Kubernetes side needs a namespace with an operator deployment and the usual RBAC, plus somewhere for the state to live. Because Burrito reads and writes Terraform state, that state has to be reachable from the cluster, and if it is in a cloud object store, the operator needs access to that too. The storage SDKs in the dependency list cover AWS, Azure and Google Cloud buckets for exactly this. Two practical consequences follow. First, a continuous planning loop means continuous cost: an operator that plans every repository on a schedule is running terraform plan against every account it watches, and plan is not free on large estates. The alternative, planning on a webhook from the repository instead of on a timer, is a design decision you would want to make in your own configuration rather than inherit. Second, the pull requests it opens are noise if nobody reviews them. The value of the model depends on a human merging them, and a team that merges them without reading has built a faster path to unintended changes. That is true of any drift-reconciliation tool, and it is worth stating before deploying one. ## The pre-release warning and how it compares The first thing in the README is a warning, and it should shape any adoption decision. The project is still in a pre-release state, minor versions will introduce breaking changes until 1.0, and you should only use releases, as the main branch can be broken. That is an unusually blunt statement to put at the top of a README, and it is more useful than the usual pre-1.0 hedging. The release history backs it up: v0.13.0 in July 2026, v0.14.0 in September, v0.14.1 days later. Minor bumps landing within days of each other, with breaking changes, is the pattern of a project still finding its API. The comparison to make is with Terraform Cloud, which is the product this positions against. Terraform Cloud runs plans and applies for you, with a hosted UI for reviewing state and changes. The difference in approach is where the work happens: Terraform Cloud is a hosted service you point at, while Burrito is an operator you run in your own cluster, which means the plan output and the credentials stay inside your infrastructure and the pull requests go to your repository rather than to a vendor's review interface. The other comparison is with plain CI. A GitHub Actions workflow that runs terraform plan on pull requests and terraform apply on merge is the standard answer, it is a few dozen lines, and it does not need a Kubernetes operator. What it does not do is continuous planning, so drift outside a pull request is invisible until someone opens one, and that is the gap Burrito is aimed at. Argo CD is the third comparison and the one the project names. Argo CD continuously reconciles Kubernetes clusters against Git and opens pull requests when reality drifts. Burrito applies the same pattern to Terraform, which is why the description works. The honest summary is that Burrito is an interesting and well-engineered answer to a real gap, in a pre-1.0 state, from a team at Theodo Cloud, with the main remaining risk being that the API will keep moving and the operational complexity of running an operator with cloud credentials in your cluster. ## Conclusion Adopt Burrito if you already run Terraform on Kubernetes and want drift detected continuously with changes proposed as pull requests rather than applied from a laptop. Skip it if your Terraform runs from a CI pipeline that already does plan-then-apply, because that is the workflow Burrito is meant to replace, and skip it if you cannot accept breaking changes between minor versions before 1.0. Verify first by pointing it at a non-production workspace, watching one plan cycle, and confirming the pull request it opens matches what terraform plan prints locally. ## FAQ ### What is Burrito and what does TACoS stand for? Burrito is a TACoS Kubernetes Operator, which the README expands as Terraform Automation Collaboration Software. It describes itself as an Argo CD for Terraform, continuously planning Terraform code, opening pull requests and showing state changes in a web interface. ### Which problems does Burrito set out to solve? Three: Terraform lacks built-in solutions for managing state drift, configuring a CI/CD pipeline for Terraform is challenging and varies by toolchain, and there is no easy way to navigate your Terraform state to understand the modifications it undergoes during an apply. ### Is Burrito safe to use yet? The README carries a warning that the project is still in a pre-release state, that minor versions will introduce breaking changes until 1.0, and that you should only use releases because the main branch can be broken. The recent releases v0.13.0, v0.14.0 and v0.14.1 show the cadence that produced the warning. ### Which technologies does Burrito support for infrastructure as code? Terraform and OpenTofu. The go.mod includes hashicorp/hcl/v2 and hashicorp/terraform-json for configuration and plan parsing, and tofuutils/tenv/v4 for provisioning the OpenTofu binary, and the repository topics list Terraform, OpenTofu and Terragrunt. ### How is the Burrito web interface built and served? The Docker build compiles the ui/ directory with pnpm and sets VITE_API_BASE_URL to /api, then copies the built assets into internal/server/dist so the front end is embedded in the Go manager binary and served from the same origin as the API, with no separate UI container. ## Sources - [License: Apache-2.0](https://github.com/padok-team/burrito/blob/main/LICENSE) - [padok-team/burrito on GitHub](https://github.com/padok-team/burrito) - [Project website](https://docs.burrito.tf) - [README](https://github.com/padok-team/burrito/blob/main/README.md) - [Releases](https://github.com/padok-team/burrito/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/padok-team-burrito