Reimagining How to Deploy Infrastructure with Infraweave
Deploying infrastructure has always felt more complicated than it needs to be. You write Terraform, run Terraform, and cross your fingers it finishes cleanly. It works, but the whole process can feel clunky - too many moving parts, too many places where things can go wrong.
Infraweave grew out of a simple idea: what if deploying infrastructure could be truly streamlined? Not stripped-down in capability, but designed so every step flows naturally into the next - with fewer surprises, fewer dependencies, and a workflow you actually enjoy using.
Why I Built It
In almost every team I’ve worked with, there’s a familiar tension. Infrastructure engineers know Terraform inside out and care deeply about doing it right. Application teams just want to ship their app without having to master the fine details of HCL.
The current solutions tend to fall into extremes. Either you throw raw Terraform at the app teams and hope for the best, or you hide everything behind a heavy control plane that’s slow to change, hard to maintain, and often demands a Kubernetes cluster you didn’t even want.
And when deploying an application feels complex, you add a new problem: constant context switching. App teams end up splitting their attention between their own work and infrastructure concerns they don’t really want to deal with. Infra teams get pulled into deployment firefighting instead of perfecting the infrastructure modules that make everything run smoothly.
Infraweave is my way of rethinking that balance - keeping the flexibility of Terraform while making the entire process streamlined from definition to deployment, so infra teams can focus on building great building blocks and app teams can focus on using them.
Where and How It Runs
A big part of making things streamlined is reducing distance - both in complexity and in where code runs. With Infraweave, Terraform doesn’t run “somewhere out there.” It runs inside your own cloud, in the same account where the resources are created. That cuts out unnecessary hops, avoids network and cross-account authentication headaches, and makes deployments faster and more predictable. Also, complexity adds security flaws.
Another key goal was avoiding lock-in to a single Git provider or CI system. Infraweave is built to work the same way whether you trigger deployments from the CLI, a Git push, inside Kubernetes, a Python SDK, or some other workflow entirely. You can mix and match entry points, and you’ll still get a full, centralized overview of what was deployed, when, and by which method - all without forcing your team to standardize on one pipeline tool just to make deployments possible.
You don’t need Kubernetes to use Infraweave - it runs on ephemeral job runners with a centralized deployment database that tracks exactly what was deployed, where, and when. No hunting through logs, no guessing what happened last week.
That said, Infraweave is heavily inspired by Kubernetes. It uses Kubernetes-compatible manifests so if you do want to run it inside a cluster, you can. The concepts and structure will feel immediately familiar to anyone who’s worked with Kubernetes, while still working perfectly in non-Kubernetes environments.
How It Works in Practice
You package Terraform into clear, reusable modules. You assemble them into stacks - opinionated combinations tailored from the start. When you deploy, Infraweave spins up a short-lived runner in the target account, executes Terraform there, records the result in the central database, and tears everything down when it’s done.
Everything about that flow is designed to be streamlined: no manual state juggling, no brittle pipelines, no hidden steps. Just a direct path from “I need infrastructure” to “It’s deployed and tracked.”
Why I Keep Working on It
I’ve been tinkering with Infraweave on weekends - building, breaking, refining - and every iteration makes it feel smoother. The more I work on it, the more it feels like the right mental model for delivering infrastructure: close to the resources, policy-aware by default, easy to track, and flexible enough to fit into different environments.
If the old way of deploying felt like wrestling an octopus, Infraweave aims to feel like sliding pieces into place. Still structured, but clean and predictable enough that you can focus on building instead of fighting your tools.
I don’t know yet if Infraweave will run the world’s production workloads or just remain my favourite side project. But I do know this: it’s already changed how I think about deployments, and it’s hard to imagine going back.
If you want to see what a more streamlined infrastructure workflow looks like, check out GitHub and explore the pieces for yourself.