Burrito is open source Apache-2.0 Kubernetes Operator, written Go, that watches Terraform, OpenTofu, and Terragrunt code continuously and plans or applies it, sold by maintainers as "Argo CD for Terraform" and aimed at platform and infrastructure teams that already run Terraform and Kubernetes but have no GitOps control loop for state drift.

What it is

Burrito is a TACoS Kubernetes Operator, where TACoS stands for Terraform Automation Collaboration Software. It runs inside a Kubernetes cluster, keeps planning Terraform code on a continuous basis, and runs applies when the plan calls for them. It also renders the modifications a run makes to state in a simple Web UI, so an operator can read what terraform apply changed instead of reconstructing it from log output. The project is developed by Theodo Cloud, licensed Apache-2.0, written in Go, and documented at docs.burrito.tf.

The concrete problem is that Terraform itself ships no built-in answer to state drift, and wiring a CI/CD pipeline for Terraform is fiddly work that changes shape with every tool choice. Teams end up hand-rolling pipelines per repository and per environment, and they lose visibility into the state diff once the job finishes. Burrito replaces that hand-written CI/CD pipeline layer: continuous planning, applying when needed, and out-of-the-box PR/MR integration mean a team does not have to author Terraform pipelines again. It complements Terraform and OpenTofu rather than replacing them, and it covers Terragrunt repositories as well.

Key capabilities

• Continuous planning of Terraform code, with applies run when the plan requires them, driven by a Kubernetes reconciliation loop rather than a job queue.
• Out-of-the-box PR/MR integration, so pull and merge requests carry plan output without a team-authored pipeline.
• Web UI that shows how a run modifies state, addressing the lack of an easy way to navigate state changes.
• Support for Terraform, OpenTofu, and Terragrunt repositories, per the project topics.
• Kubernetes Operator packaging, meaning deployment and lifecycle follow standard operator patterns in a cluster.
• Documented at docs.burrito.tf, with a public Discord for support and a contribution guide for contributors.
• Apache-2.0 licensed Go codebase, with CI signals including Go Report Card and codecov coverage.

Who uses it and how

• Platform teams running Terraform on Kubernetes that want drift detection without building their own scheduled plan jobs.
• Teams that maintain many Terraform or Terragrunt repositories and are tired of duplicating CI/CD pipeline definitions per repository.
• Infrastructure engineers who need reviewers to see the state diff on a merge request rather than trusting a green pipeline.
• Organizations standardizing on GitOps patterns from Kubernetes onto infrastructure-as-code, extending the reconciliation model into Terraform.
• Teams already using OpenTofu as a Terraform replacement and wanting the same continuous planning behavior around it.

Getting started

The README does not name a package, Docker image, or compose file; it directs readers to the complete documentation at https://docs.burrito.tf, which is the supported path for installation and setup. The README also warns to use released versions only, since the main branch can be broken.

How it compares

Burrito is not a Terraform, Terragrunt, or OpenTofu replacement: it sits above those binaries and drives them continuously, so the comparison that matters is with Argo CD, whose GitOps reconciliation model Burrito applies to Terraform rather than to Kubernetes manifests. No other comparable product is named in the facts supplied here, so beyond that Argo CD analogy it stands alone in this registry.

When to use it — and when not to

A self-hoster must operate a Kubernetes cluster plus the operator itself, and the README does not spell out the supporting dependencies, so teams without Kubernetes operational capacity should look elsewhere. The project is explicitly pre-release: minor versions will introduce breaking changes until 1.0, which makes it a poor fit for anyone needing a stable interface today. Teams that want a managed service, or that cannot pin to releases and track main, should not pick it up yet.