Blog
Articles about Agentic DevOps, infrastructure packages, Clojure workflows, and self-hosted operations.
Terraform is excellent at standing infrastructure up, but Day 2 work often begins after apply: DNS updates, cache purges, configuration, notifications, and handoffs to other tools. BigConfig packages keep Terraform as a powerful implementation detail while exposing code-first, local-first, and agent-first lifecycle verbs. The BigConfig SDK supports TypeScript, Python, and Clojure.
This tutorial shows how to install and try the three Claude Code skills that scaffold minimal, launcher-conformant BigConfig packages in TypeScript, Python, and Clojure. Each starter package includes validate and build verbs, a root run file, packaged resources, tests, and the shape needed to run through bc-pkg.
Crossplane makes Kubernetes the public runtime for platform operations. BigConfig replaces that boundary with executable packages that humans, agents, CI, scripts, and backend control planes can all run.
Delivery teams and agents ask product-level questions: can I deploy this, is it valid, what changed, can I roll back, is it healthy? Platform teams often answer with tool verbs like terraform apply, helm upgrade, and kubectl apply. BigConfig exists to replace that mismatch with executable package interfaces.
Raw Terraform often gives users and package authors the same workflow: clone the source repo, make a change, and run Terraform. BigConfig separates those roles. Users operate a package instance through lifecycle verbs, while authors develop the package source through render and tool loops.
The BigConfig Package Spec defines the small contract a repository needs in order to be pinned, initialized, and run by bc-pkg: one language manifest, one root run file, installable package code, and the lifecycle verbs agents, humans, shells, and CI can all share.
DevOps is still stuck in a world where the public interface to operations is a low-level tool command: plan, apply, destroy. But when an infrastructure package becomes a program, agents, shells, CI, and control planes can run the verbs the domain actually needs.
After reading that Bun was rewritten from Zig to Rust, I tried a similar experiment on BigConfig: port the broader stack across TypeScript, Python, and Clojure with an agent, then redeploy the public BigConfig website with the agent-written version.
A skill and a BigConfig package are both containers for procedural knowledge: how to do something. The difference is that skills are agent-native, while BigConfig packages are shell-native, library-backed software packages that agents, humans, CI, and scripts can all run.
Agentic DevOps is an operating model decision, not a tooling experiment. For a CTO the question is not whether agents are powerful, but whether the blast radius is bounded. Sandbox the agent, scope credentials to read-only, keep create and delete under human authority, and you get the leverage without betting production on a prompt.
