Where React for IaC came from

mrduguo — Sun, 17 May 2026 09:47:27 +0000

This is the first technical post in the Dinghy series, and it is the one I had to write before any of the others made sense. It is the origin story of the project — how a Terraform codebase that had grown beyond what copy-paste could maintain ended up being rendered out of TSX — and the core concept the rest of Dinghy is built on.

How I ended up here

Back in the day, I was maintaining a Terraform codebase across several environments. Most of the configuration was duplicated between them — the same resources, the same modules, repeated for every environment with only the inputs changing. Every change had to land in every environment. Every difference between them was either a deliberate choice or a bug waiting to happen.

Modules helped. For a while. Then the modules themselves became the maintenance burden — a layer of indirection that still couldn't express what I actually wanted to say.

HCL is HashiCorp Configuration Language. The keyword is configuration. It describes resources. It does not let you reason about them.

I wanted a real language.

The first move: CDKTF

CDKTF — Cloud Development Kit for Terraform — was the obvious next stop. Write infrastructure in TypeScript, render to Terraform JSON, deploy with the regular Terraform tooling. I tried it. It did what it said on the tin: real loops, real functions, real imports, real IDE support.

But two things kept nagging.

Construct boilerplate. CDKTF inherits AWS CDK's construct pattern: new Vpc(this, 'vpc', {...}), then new Subnet(this, 'subnet', { vpc, ... }). Every resource needs a parent scope and a unique id, hand-passed. It is faithful to AWS CDK, but it never stopped feeling like extra steps around the thing I actually wanted to write.

Cross-resource wiring. When two resources needed to talk to each other, I was still threading handles by hand. Pass the VPC into the subnet. Pass the subnet into the EC2. Pass the EC2 into the security group rule. The hierarchy in my head — VPC contains subnets contains instances — was nowhere visible in the source.

CDKTF had solved the programmable-language problem. It had not, for me, solved the expressing nesting problem.

The click: TSX nests the way infrastructure nests

When you draw a cloud architecture diagram, you naturally nest things inside containers — the VPC box wraps the subnet boxes; the subnet boxes wrap the instances. That nesting is how the infrastructure composes.

The moment that turned this into a project rather than a complaint was noticing that TSX is already nested in the same way. When you write:

<Vpc>
  <Subnet>
    <Ec2 />
  </Subnet>
</Vpc>

The source code shape matches the runtime shape. The thing you write looks like the thing you mean. No new X(parent, id, {...}). No explicit handle threading. The parent is right there — it is the JSX element containing you.

The next step was obvious. React looks like a tool for building web pages, but underneath, it is a general-purpose engine for building trees. The part that turns your TSX into HTML doesn't actually need to produce HTML — it can produce anything, as long as you tell it how. Tell it to produce Terraform JSON, and that is what you get.

Don't worry about React's complexity

If React's hooks, lifecycle, and state-management debates have put you off, you can relax. Dinghy uses almost none of that.

Dinghy renders once. You write the TSX, Dinghy walks the tree from top to bottom one time, writes the Terraform JSON, and stops. No reactivity. No re-renders. No state to manage. No lifecycle.

So none of the modern React you might have struggled with applies here:

~~useState~~ — no local state
~~useEffect~~ — no side effects or lifecycle
~~useMemo~~ — nothing to memoise

Dinghy only keeps the bits that make the nesting work:

TSX — the authoring syntax
The tree-walker that turns TSX into output
useContext — for letting a child component reach a surrounding parent (the bucket trick you will see in the next section)

Most of what React has accumulated for browser UI doesn't apply here, and you don't need to know it.

Context fixes the wiring problem

Here is the bit that finally felt right. With CDKTF I was threading a bucket handle down through props. With Dinghy:

const BucketVersioning = () => {
  const { s3Bucket } = useAwsS3Bucket()
  return (
    <AwsS3BucketVersioning
      bucket={s3Bucket.bucket}
      versioning_configuration={{ status: 'Enabled' }}
    />
  )
}

<AwsS3Bucket ...>
  <BucketVersioning />
</AwsS3Bucket>

BucketVersioning does not need to be told which bucket it is enabling versioning on. It asks the surrounding AwsS3Bucket via context. Drop it anywhere under a bucket and it Just Works.

That is the kind of composition HCL fundamentally cannot give you. CDKTF can do it, but only by passing the parent reference by hand.

Beyond Web

The other thing that fell out of choosing React: the output can be anything. React doesn't care whether the result is HTML, native mobile widgets, terminal UI, or Terraform JSON. Point it at a different kind of output, and it produces that.

React started as a web library, but it has long since moved beyond the web:

Web — the original
Native — iOS and Android apps
CLI — Ink, Claude Code, and similar tools render terminal interfaces with React-like trees
Infrastructure — Dinghy, rendering diagrams and Terraform

Same model, different output. That is why a single engine can sensibly cover diagrams and infrastructure under one roof — what the tree renders to is just a detail.

Introduction to Dinghy: a Swiss-army knife for everyday engineering

mrduguo — Tue, 12 May 2026 20:39:11 +0000

If you ship anything for a living — diagrams, infrastructure, docs, slide decks — you have probably noticed that each of those things lives in its own world, with its own toolchain, its own opinionated editor, and its own subtle ways to drift out of sync.

Dinghy is an open-source toolchain that puts all of them under one roof. One CLI. One install. One consistent way to describe what you want as code and let the tools deliver the final artwork.

What it is

A Swiss-army knife for engineers who like writing code more than clicking through dialogs:

Diagram as Code — render architecture diagrams to draw.io.
Infrastructure as Code — render OpenTofu / Terraform from React TSX.
Site Builder — author docs sites with Docusaurus, live-preview them, deploy to S3.
Slide Builder — author RevealJS presentations in YAML / Markdown / HTML, with Prezi-style zoom-and-pan as a Dinghy-exclusive bonus.

It is powered by Deno and Docker, so you do not need to babysit Node versions, Python virtualenvs, Terraform providers, or any of the rest of it.

From a DevOps engineer's bench

Dinghy was built by a DevOps engineer, so it is shaped to walk with your code across the whole software development lifecycle — from local development through to CI/CD — instead of stopping at the edge of one stage.

How it is shaped

Dinghy splits cleanly into a thin CLI and a fat engine that runs in Docker. The CLI is what you install on your machine; the engine is a versioned image that ships every dependency Dinghy needs.

curl -fsSL https://get.dinghy.dev/install.sh | sh

That single command gets you the CLI. From then on, everything Dinghy does happens inside the engine image — which means every machine on your team gets the exact same versions of Deno, Node, OpenTofu / Terraform, and every TF provider, pinned through a single .dinghyrc file.

DINGHY_ENGINE_VERSION=0.1...

One lock. Predictable versions. No more "it works on my laptop" — and no more two-year-old projects you can't rebuild because the dependencies have rotted away.

Who it's for

Anyone who needs to write code for any of this work — a diagram, a piece of infrastructure, a docs site or web app, a slide deck. You do not need to use them all, and you do not need to use them all the time. Reach for one when that is all you need; pull in a few when the work spans more than one.

If any of that sounds useful for what you are building, the rest of this series digs into each capability one post at a time (coming soon — links will go live as each post is published):

Where React for IaC came from — the origin of the Dinghy project and core concept.
Diagram as Code with draw.io — author architecture diagrams as TSX components.
Infrastructure as Code — 248 lines of Terraform from 8 lines of source.
Site Builder — from one Markdown file to a deployed site.
Slide Builder — RevealJS in YAML, with Prezi-style zoom.
Dinghy in the AI age — still relevant? How it works alongside AI.

Ready to set sail?

curl -fsSL https://get.dinghy.dev/install.sh | sh

Guides and examples are at https://dinghy.dev.

Forem: mrduguo