I’ve been staring at a Terraform module for the last ten minutes, and I can’t stop thinking about a question that would have been absurd two years ago: why am I writing this?

Not “why am I provisioning this infrastructure.” That part makes sense. But why am I writing HCL, a domain-specific language that exists to describe infrastructure in a way that humans can read, when I have an AI agent sitting in my terminal that can call the AWS API directly?

It’s the kind of question that sounds naive until you realise the same logic is playing out across every layer of the stack. And the more I look at it, the more I think we’re watching the early stages of a fundamental shift in how we interact with machines.

This is the start/index post for a series of blog posts about the internals of Terraform. In this series, I will deep dive into different parts of Terraform and explain how they work under the hood.

The end-goal of this is to enable the reader to develop a deeper understanding of Terraform and how it works. After reading this, I would hope you are able to contribute to Terraform itself, add a new block to the language, or change existing behavior. I will not try to cover every single detail of Terraform, but I will try to cover the most important parts and give you a good overview of how different parts of Terraform work together.

My hope is that this series helps the reader to at least get a step closer to understanding the internals of Terraform. I won’t be covering anything related to language design and graph theory here; there are too many holes in my knowledge there as well. Maybe I’ll write something to that end in the future as well, probably not.

Open-source platform replacement for Terraform Enterprise.

In this article, I'll show how the Argo Workflows Executor Plugin lets you extend the Argo Workflows controller without maintaining your own fork—simply by implementing a small HTTP server in any language. As a bonus, this same mechanism reduces the number of extra pods in your DAGs and lightens the load on the Kubernetes scheduler. If you're new to Argo, I'll briefly cover the architecture and where plugins fit in. We'll finish with practical examples and key configuration details.

K8sQuest is a local, game-based Kubernetes training platform with an interactive GUI-like terminal interface. Each mission breaks something in Kubernetes. Your job is to fix it.

kimspect is a kubernetes container image inspection tool that provides comprehensive visibility into container images running inside your cluster. kimspect can get image information by pod, namespace, and node. Built for performance and reliability, kimspect enables container image insights with a simple, intuitive command-line interface.

KAOS is a Kubernetes-native framework for deploying and orchestrating AI agents with tool access, multi-agent coordination, and seamless LLM integration.

A K9s-inspired terminal UI for monitoring Flux GitOps resources in real-time.

Mount /nix into Kubernetes pods using the CSI Ephemeral Volume feature. Volumes share lifetime with Pods and are embedded into the Podspec.

Cartography is a Python tool that maps infrastructure assets and their relationships into a Neo4j-backed graph view.

Morgan Stanley explains how it scaled Flux across 500+ clusters over five years, including security, performance, and observability lessons.

Every container image you pull from registry.k8s.io got there through kpromo, the Kubernetes image promoter. It copies images from staging registries to production, signs them with cosign, replicates signatures across more than 20 regional mirrors, and generates SLSA provenance attestations. If this tool breaks, no Kubernetes release ships. Over the past few weeks, we rewrote its core from scratch, deleted 20% of the codebase, made it dramatically faster, and nobody noticed. That was the whole point.

This covers safer Kubernetes debugging with least-privilege RBAC, short-lived identity-bound credentials, and audited SSH-style access paths.