TACOS unify plan, policy, drift, and team collaboration in one platform. This episode reviews OpenTofu support in Spacelift, env0, and Scalr, then introduces Digger, an open-source GitOps tool that executes OpenTofu directly in CI without external SaaS.

In the previous episode 13 we built a full GitOps pipeline on GitHub Actions and GitLab CI: the official setup-opentofu action, tofu fmt, tofu validate, security scan, tofu plan with PR comments, an approval gate, and tofu apply via OIDC. Pipelines like that are great — but building and maintaining them for dozens of repositories is ongoing work. The larger the team, the higher the need for things that are exhausting to build yourself: policy enforcement, drift detection, cost tracking, and fine-grained access control. That's where the managed TACOS ecosystem takes over.
In episode 14 we review the managed platforms that support OpenTofu — Spacelift, env0, and Scalr — then introduce Digger, an open-source GitOps tool that executes OpenTofu directly inside your CI without external SaaS.
TACOS stands for Terraform/OpenTofu Automation and Collaboration Software. The idea is simple: instead of managing init, plan, apply, state locking, policy, and approvals separately, all of it is centralized in a single layer on top of the IaC engine. Terraform Cloud once held this role, but it's a commercial HashiCorp product — and the OpenTofu community naturally doesn't want to depend on the same ecosystem that made Terraform change its license. So TACOS vendors supporting OpenTofu from the start emerged as the alternative.
All three are SaaS platforms (Scalr can also be self-hosted on your infrastructure) that run the tofu binary behind the scenes. All support OpenTofu natively since the fork launched — and they were also early sponsors of the project:
Spacelift — the strongest in policy and automation. It has OPA/Rego-based Policy as Code to control who can plan and apply, scheduled drift detection, and a rich plan view. Many production teams use it as a Terraform Cloud replacement.
env0 — stands out for ease of use: UI templates, RBAC, cost estimation, and integrations with many tools. Great for teams that want to quickly enable non-IaC engineers.
Scalr — can be installed on your own infrastructure, supports an OpenTofu-compatible remote state backend, and focuses heavily on governance and fine-grained RBAC.
| Platform | Model | Main strength | OpenTofu |
|---|---|---|---|
| Spacelift | SaaS | Policy as Code, drift, rich plan | Native |
| env0 | SaaS | UI templates, cost estimation | Native |
| Scalr | SaaS / self-hosted | Remote backend, fine-grained RBAC | Native |
Note
There are no dedicated icons for Spacelift, env0, or Digger in this blog's icon set. Their configurations in this episode use the generic available icons instead: iTofu, iBash, iGithubactions, and iGitlab.
If Spacelift and company are SaaS you pay for, Digger takes the opposite path: open-source and runs in the CI you already have. Digger reads a digger.yml configuration, listens to pull request and issue comment events from GitHub or GitLab, then executes OpenTofu directly on the runner — no external cloud, no data leaving the repository, and no subscription cost.
Digger's configuration is based on projects and workflows. Each project points to a directory and the workflow it uses, and each workflow defines the plan and apply steps:
projects:
- name: dev-vpc
dir: terragrunt/dev/vpc
workflow: dev
- name: prod-app
dir: tofu/prod/app
workflow: prod
workflows:
dev:
plan:
steps:
- init
- plan
apply:
steps:
- apply
prod:
plan:
steps:
- init
- plan
apply:
steps:
- apply
auto_merge: true
comment_on_pr: trueThe key to GitOps is that infrastructure state follows repository state. With Digger, plan runs automatically when a PR is opened or updated, the result is commented directly on the PR, and apply happens after merge — or can add manual approval via a comment. Authorization is handled by built-in OPA Policy as Code, and drift can be detected with a scheduled job.
Integration into GitHub Actions is just the diggerhq/digger action:
name: Digger
on:
pull_request:
types: [opened, synchronize, reopened, closed]
issue_comment:
types: [created]
jobs:
digger:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: diggerhq/digger@v0.7.10
with:
setup-aws: true
env:
GITHUB_CONTEXT: ${{ toJson(github) }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}Tip
Digger also has direct CLI commands: digger plan and digger apply run on your local runner. This makes onboarding very light — just install the action, write digger.yml, and let the first PR post its first plan.
There's no universal answer. Managed platforms save you time developing exhausting features — policy engines, drift schedulers, and UIs — but hand execution to a third party and add per-user costs. Digger returns full control and zero cost, but you're responsible for maintaining CI workflows and adding the features managed platforms give for free. The rule of thumb: small teams with a few repos start with Digger; large teams with serious governance needs look at Spacelift or Scalr.
In episode 14 we:
digger.yml and connected it to a CI workflow.All the platforms in this episode — both SaaS and Digger — assume the secrets sent to OpenTofu are safe. In the next episode, episode 15, we secure that assumption: secret management & state hardening by combining client-side state encryption and sensitive variables, then pulling dynamic secrets from HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager during apply. See you there!