Rhodd and Terraform: different layers

In almost every evaluation of Rhodd, someone asks whether it replaces Terraform. It's a reasonable thing to ask — both tools sit near the word "infrastructure," both take a declarative file and turn it into something real. The answer is no, and the reason is more useful than the answer.

Rhodd and Terraform work at different layers. Terraform manages infrastructure resources. Rhodd compiles software-system architecture. These are not two takes on the same job; they are two different jobs that happen to be neighbours. Judging a tool by the layer it sits next to, rather than the one it actually works at, is a layer collision — and it's the source of most of the confusion about where Rhodd fits.

Two different questions

Terraform answers a question about resources. Given a cloud account, what should exist in it — which networks, clusters, databases, roles — and how do you converge reality onto that target. It is very good at this, and it is the kind of thing you genuinely do not want to reinvent. Rhodd has no intention of doing it.

Rhodd answers a question that comes earlier. What is this system? Which services exist, what kind is each one, which modules do they share, how do they depend on one another, who owns which paths. That description — the graph, the ownership boundaries, the contracts between services — is the architecture, and it exists whether or not you have provisioned a single resource. It is true before there is a cloud account to point Terraform at.

You hold both at once without conflict. The architecture says there is an api service that owns a postgres module. Terraform, later and separately, decides what a Postgres instance actually is in your account — which size, which region, which network. Rhodd does not reach down into that decision, and Terraform does not reach up into the first one.

What Rhodd actually emits

This is the part that's easy to get wrong, so it's worth being blunt about it. Rhodd does not output Terraform. It never has, and there is no flag to make it.

What Rhodd generates is the software-system baseline: service scaffolds, a Docker Compose file, Kubernetes manifests, env files, generated docs — plus the .rhodd/ state that records how it got there. When you want a deployment representation, Rhodd exports manifest files: an Argo CD Application, a Flux Kustomization, or plain generic Kubernetes YAML.

# .rhodd/export/argocd/api.application.yaml — a file, not a deploy
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api
spec:
  source:
    repoURL: https://github.com/rhodd-fdn/rhodd
    path: k8s/api
  syncPolicy: {}   # manual — nothing applies on its own

Those are files. Rhodd writes them and stops. It makes no cluster calls by default; applying them is a separate, deliberate step you take with your own tools, when you decide to.

If you use Terraform, you keep using it. The manifests Rhodd writes describe applications meant to run on a cluster that already exists. Terraform is one good way to make that cluster exist in the first place. The two meet at the boundary — a cluster that is provisioned on one side and targeted on the other — and they do not overlap.

The layered future

It's common to want one tool that does everything, and just as common to regret it a year later, when the all-in-one tool is mediocre at the six jobs you now actually have. The arrangement that holds up over time is the opposite: layers that each do one thing well and hand off cleanly to the next. Architecture compiles to a baseline. Infrastructure gets provisioned. Applications get deployed onto it. Each layer produces exactly what the next one needs, in a format that layer already understands, and stays quiet about everything else.

Rhodd owns the first of those layers and is deliberately quiet about the other two. It compiles the architecture and writes the artifacts the later stages consume — manifests for your deployer, a baseline for your build — and then it gets out of the way and lets you choose the tools for provisioning and deploying.

So the honest answer to "does Rhodd replace Terraform" is that the question has a layer collision built into it. Rhodd no more replaces Terraform than a blueprint replaces a foundation. It is the thing you compile before either one has anything to do — and the sharper that boundary stays, the better every tool on both sides of it gets to be at its own job.

Docs · Proof · Join the beta