BigConfig | Blog

Terraform Workspaces Are Not Environments — BigConfig Makes It a Non-Issue

Sun, 26 Apr 2026 00:00:00 GMT

A thread came across my LinkedIn feed this week. The setup: someone pointed out that Terraform docs themselves say workspaces aren’t meant for environment isolation. The replies were the usual matrix of “well, actually” — separate state files, separate root modules per env, separate provider configs, separate pipelines, the WET-vs-DRY tug of war, the “we migrated 14 workspaces to isolated root modules last year” war stories.

Reading it, I had the same reaction I always have to these threads: the dichotomy itself is the tell.

“Workspaces vs separate root modules.” “WET vs sprawl.” “Shared state vs blast radius.” These aren’t real architectural choices. They’re symptoms of Terraform forcing you to pick your poison at the wrong layer.

Why the debate keeps happening

Terraform fuses two things that should be independent:

The unit of reuse — the module. A module is how you avoid copy-pasting resource definitions.
The unit of deployment — the root module plus its state file. This is what terraform apply actually operates on, and what owns blast radius, IAM, and provider config.

Because these are fused, every “how do I isolate environments?” question becomes a folder-layout question. Do I have one root module with workspaces? One root module per env? A wrapper directory per env that calls a shared module? Each answer trades one form of pain for another:

Workspaces → DRY, but shared backend, shared providers, shared blast radius. The docs themselves warn you off.
One root module per env → strong isolation, but now you’re maintaining N nearly-identical folders. Drift is inevitable. Reviewers can’t tell what actually changed across envs.
Wrapper directories calling a shared module → better, but you’re still hand-rolling the parameterization, the pipeline plumbing, and the promotion story. And count = var.env == "prd" ? 1 : 0 conditionals start showing up.

This is why the same thread gets re-litigated on LinkedIn every few months. There is no right answer inside Terraform’s model.

What BigConfig does differently

In BigConfig, environments are values, not directories.

An environment is a map of inputs passed to a package. The same package — fully reusable, version-pinned, DRY — gets instantiated N times with different inputs. Each instantiation gets its own state, its own provider config, its own IAM boundary, its own pipeline gate. Automatically. By default.

There is no workspace flag. There are no copy-pasted root modules. There are no count = var.env == "prd" ? 1 : 0 conditionals rotting in the corner of a file no one wants to touch.

What that buys you in practice:

DRY without sprawl. One package definition, parameterized. Not 14 root modules to keep in sync.
Strong isolation by default. Separate state and credentials per instance is the default, not a discipline you have to enforce in code review.
Composable. Environments are built from packages the same way packages are built from resources. Promotion = bumping a version, not diffing two folders.
Multi-instance is free. “What about per-tenant, per-region, per-cell?” stops being an architecture decision and becomes a for loop.

The deeper point

The Terraform community keeps having this argument because Terraform’s unit of reuse and its unit of deployment are the same artifact. Every workaround — workspaces, Terragrunt wrappers, generated HCL, monorepos of near-duplicate folders — is an attempt to pry them apart from the outside.

BigConfig pries them apart from the inside. A package describes what you want. An instantiation describes where and with what inputs. State, providers, and IAM follow the instantiation, not the package.

Once you have that separation, “workspaces aren’t environments” stops being a hot take and becomes a non-issue. Same for most of the other recurring DevOps debates — they’re not wrong arguments, they’re just arguments that only exist because the underlying tool conflated two concerns.

To see how your agent can operate a BigConfig package that encapsulates multiple Terraform resources and Ansible playbooks, start at the BigConfig Demo .

Why Agents Need an Infrastructure Package Manager

Sun, 26 Apr 2026 00:00:00 GMT

Kief Morris recently published Why I have my agents write infrastructure code , and it is one of the clearest articulations of Agentic DevOps I have read. His central observation is hard to argue with: when you let an agent drive the AWS CLI directly, it takes multiple tries, casually blows away data, and replaces solid implementations with slow, less-reliable alternatives. But when you ask an agent to write reusable infrastructure code instead of executing low level CLI tools, you get something much safer: a composable, auditable artifact that a human can review before anything touches production.

We agree with everything in that post. In fact, we have been building exactly the ecosystem he envisions—we just call it a package manager.

The Gap Between Intent and Execution

Morris frames the problem as an agent adapting pre-existing components to specific needs. The missing piece, as he notes, is the ecosystem of components itself. Without it, agents fall back to generating raw HCL or shell scripts from scratch, which is precisely where hallucinations and cascading failures live.

This is the same gap the web ecosystem solved between 2010 and 2015. Before React and npm, every JavaScript developer rewrote the same DOM manipulation logic from scratch. After React, the ecosystem converged on components. A developer—or today, an agent—doesn’t write a date-picker from scratch; they install one from a registry and wire it into the application.

DevOps needs the same shift. BigConfig is the attempt to make it happen.

BigConfig as the npm for Infrastructure

BigConfig is a Clojure-based infrastructure package manager. The mental model is intentionally close to npm or Maven:

Packages are versioned, composable units of infrastructure logic (compute, DNS, SMTP, Kubernetes controllers, etc.)
The lock file records the exact versions resolved, so every bb bigconfig apply is deterministic
Babashka executes the packages locally—no server, no daemon, no state machine to manage

When an agent works with BigConfig, it is not guessing Terraform resource attributes or wrestling with provider schema drift. It is composing packages the same way a React developer composes components: declare what you want, let the abstraction handle the how.

bb.edn

{:deps  {io.github.amiorin/once {:git/url "https://github.com/amiorin/once"
                                 :git/sha "8ffbbc2ea0974365575c7ee44b7d890e69447144"}}
 :tasks {:requires ([io.github.amiorin.once.package :as pkg])
         package   {:doc  "bb package create | bb package delete"
                    :task (pkg/once*
                           *command-line-args*
                           {:big-config.render/profile "online"
                            :big-config.workflow/params
                            {:domain  "bigconfig.online"
                             :package "online"
                             :once    {:applications [{:host  "www.bigconfig.online"
                                                       :image "ghcr.io/amiorin/big-config-website:latest"}]}

                             :provider-compute            "oci"
                             :oci-config-file-profile     "DEFAULT"
                             :oci-display-name            "bigconfig-online"
                             :oci-shape                   "VM.Standard.A1.Flex"
                             :oci-ocpus                   1
                             :oci-memory-in-gbs           6
                             :oci-boot-volume-size-in-gbs 50
                             :oci-boot-volume-vpus-per-gb 30
                             :oci-ssh-authorized-keys     "~/.ssh/id_ed25519.pub"

                             :provider-smtp   "resend"
                             :resend-server   "smtp.resend.com"
                             :resend-port     587
                             :resend-username "resend"

                             :provider-dns "cloudflare"

                             :provider-backend "s3"}})}}}

An agent reading this file understands the intent immediately. It does not need to know the Hetzner API, the Cloudflare zone API, or the Resend domain verification flow. Those details are encapsulated inside the package.

Why Clojure?

Morris notes that unlike static libraries, agents can adapt code to specific needs. This is where the language matters. Clojure’s data-driven programming model means that infrastructure packages are, at their core, plain data maps. An agent can read them, modify them, and reason about them without parsing a DSL or reverse-engineering a class hierarchy. The code that acts on the data is small and testable independently.

Babashka—the scripting runtime we use—runs the same Clojure source without a JVM startup penalty, which means an agent can invoke bb package create as naturally as it runs terraform apply, but with far more predictable outcomes.

Reusability Without Rigidity

One concern Morris raises is the tension between reusability and adaptability. A static library forces you into its abstractions; you fight it the moment your requirements diverge. BigConfig avoids this by treating packages as data transformations rather than black-box executables. Each package exposes its intermediate data before it runs, so an agent—or a human—can inspect and override specific values without forking the package.

This is the same principle as React’s props. You do not rewrite the component; you pass different props. In BigConfig, you pass different configuration keys.

The Ecosystem Is Already Growing

The once package is the first published example: a complete personal PaaS (compute + DNS + SMTP) that an agent can provision on Hetzner or OCI with a single command. More packages are in progress for Kubernetes namespaces, observability stacks, and database clusters.

Each new package is a node in the ecosystem Morris envisions. Each one reduces the surface area an agent must hallucinate, and increases the confidence that what gets applied to production is what was intended.

What This Means for Practitioners

Morris’s post ends with a hopeful note: if agents can adapt working, pre-built code to specific needs, we may have the basis for a healthy ecosystem of infrastructure components. We share that hope, and we think the path there is clear:

Stop asking agents to write raw Terraform. They are being asked to generate “assembly code” for infrastructure, and they will keep making assembly-level mistakes.
Build or adopt a package layer. The package is the unit of trust, not the generated file.
Let the agent compose, not author. The moment the agent’s job becomes “pick the right packages and supply the right configuration,” the error rate drops dramatically.

If you are thinking about how to structure infrastructure for an agentic world, the package manager mental model is worth exploring. BigConfig is one implementation of that idea, built in Clojure with Babashka, and it is open source.

To see how your agent can operate a BigConfig package that encapsulates multiple Terraform resources and Ansible playbooks, start at the BigConfig Demo .

Do you trust your DevOps code as much as you trust Postgres?

Fri, 24 Apr 2026 00:00:00 GMT

You shouldn’t. Most DevOps teams write Terraform from scratch, yet no Backend team would try to write their own database engine. Postgres is reliable because it has been hardened by decades of production workloads, across every imaginable failure mode.

In the age of AI agents, we are generating more Terraform code than ever. But without a standardized foundation, that code is “alpha” — as risky as using a database that was just uploaded to GitHub yesterday.

The problem: the “bespoke platform” trap

In operations, we are all solving the same fundamental problems. Yet, unlike the database world, every company “rolls their own” platform. This leads to two outcomes:

Constant babysitting: high-maintenance scripts that require manual intervention.
Low reliability: brittle infrastructure that breaks under edge cases.

BigConfig is changing this. We are building infrastructure packages that earn your trust through mass adoption. A BigConfig package isn’t just a script; it’s a hardened standard, deployed so many times it reaches the “Postgres level” of reliability.

A real-world lesson: the “latest” trap

Even with years of Terraform experience, I recently faced unplanned downtime due to a common mistake. My compute instance was set to pull the “latest” image. When Oracle released a new Ubuntu version, Terraform triggered a recreation of the VPS.

The fix? I had to refactor the resource to ignore changes to the source image, using Terraform’s lifecycle meta-argument :

lifecycle {
  prevent_destroy = <{ compute-prevent-destroy }>
}

That single block hands control of the maintenance window back to the operator, instead of letting an upstream image publish silently destroy the VM.

This is exactly how databases work — even AWS RDS requires a defined maintenance window for upgrades. Infrastructure should be no different. BigConfig bakes these hard-learned lessons into every package, so you don’t have to learn them the hard way.

The takeaway

So, do you trust your DevOps code as much as you trust Postgres? If the honest answer is “no,” the problem isn’t your team — it’s that every team is rewriting the same primitives from scratch. Shared, battle-tested packages are the only way infrastructure code earns the kind of trust we already give our databases.

Stop writing infrastructure from scratch. Start from a package that’s already been hardened in production.

Browse the BigConfig Marketplace

The Future of Software Distribution: How LLMs are Challenging the SaaS Dominance

Wed, 22 Apr 2026 00:00:00 GMT

For a long time, the software industry has operated under the assumption that Software as a Service (SaaS) is the undisputed king of software distribution. But this long-held belief is being called into question by the rapid rise of Large Language Models (LLMs).

The classic “buy versus build” dilemma for companies is becoming more complex. In the SaaS era, the choice was often simple: buy if you don’t want to operate it, self-host if you do. Now, LLMs and AI agents are making self-hosting more attractive and cost-effective.

The Snowflake Example and the Return to Licensing

Take Snowflake , arguably one of the most successful SaaS products. It displaced traditional, license-based data warehouses like Teradata and Vertica with a closed-source SaaS model. However, we may be on the verge of a trend reversal.

In the future, a software license for a product like Snowflake could become more appealing than a SaaS subscription for several reasons:

Data Sovereignty: Paying for a license allows a company to keep its data within its own country because it maintains control over the hardware.
Compliance and Security: Navigating regulatory requirements can be easier with on-premises or licensed software.
Simplified Legalities: Companies may be able to avoid complex data processing agreements.

The Role of the Platform Team and AI Agents

Implementing SaaS in large organizations is rarely a “plug-and-play” experience. It typically requires a dedicated internal team to act as a bridge between the company’s requirements and the SaaS provider. This team handles onboarding, ticket management, compliance, and cost optimization.

As AI agents begin to automate these tasks and even the management of hardware, the burden of running software in-house significantly decreases. Picture an agent that provisions a Postgres cluster, monitors replication lag, applies security patches during a maintenance window, rolls back a failed upgrade, and files a postmortem ticket — all without a human on call. The operational tax that once justified the SaaS premium shrinks toward zero. Since large companies are already equipped to run their own software, the transition back to licensed models, supported by AI, becomes a much smaller hurdle.

The Open-Source Illusion and the Shift in Monetization

The relationship between open-source and SaaS is also evolving. Many companies have used open-source software as a “funnel”, building a community of users who eventually become paying customers for a proprietary SaaS version. This strategy has focused on growth over immediate profitability.

However, the LLM era is disrupting this cycle. Investors and companies are starting to doubt whether they can monetize these large user bases in the future. As AI companies like OpenAI and Anthropic begin to capture more of the market with their tokens and agents, the traditional SaaS margin is being cannibalized.

A Return to Proprietary, Licensed Software?

We may be heading toward a future where:

Open-source’s role is redefined: Its synergy with SaaS is weakening as AI changes the value proposition.
Proprietary software returns: Users might download software for free for limited use (e.g., one computer or one project) but pay a license fee for larger deployments.
The database remains closed-source: While the software to manage a database might be open-source, the database engine itself — which is much harder to replicate — will likely remain closed-source and license-based.

In this shifting landscape, competition among token providers will likely remain high, which is good news for the industry. But the SaaS model of software distribution will have to adapt.

Where BigConfig Fits

This is the world BigConfig is built for. If AI agents make self-hosting cheap, the missing piece is a way to describe infrastructure declaratively enough that agents — not humans — can operate it. Take Walter , a BigConfig package for cloud development environments that competes directly with SaaS offerings like Google Cloud Workstations . Instead of paying a per-seat subscription, you install Walter on your own infrastructure and let an agent handle provisioning, lifecycle, and cleanup. The community writes the package; you run it on your own hardware; the SaaS premium disappears and the control stays with you.

Your GitHub Actions Workflow is a Waste of Time

Tue, 21 Apr 2026 00:00:00 GMT

Over the years, I’ve experimented with almost every flavor of development environment. I’ve gone from manually provisioning tools on a Mac—hoping I’d remember every brew install six months later—to exploring Docker, Nix, and remote environments.

My journey has touched it all: asdf, Brew, Docker, Nix, and Devbox. I’ve jumped between terminal emulators and multiplexers like Tmux, Kitty, WezTerm, and Zellij.

My Modern Development Environment

My latest setup is built for speed, reproducibility, and a “keyboard-first” philosophy. It lives entirely in the terminal across two environments: my local iMac and an OCI Ampere VPS.

Terminal: Ghostty
Multiplexer: Zellij
Environment Management: Devenv
Editor: Doom Emacs

Achieving CI Parity with Self-Hosted Runners

If you haven’t switched to a self-hosted GitHub runner yet, do it for your own sanity. You can thank me later.

By running your CI on your own hardware (like an OCI Ampere instance), you eliminate the overhead of public runners and gain full control over the environment. When paired with Devenv, your CI environment becomes an exact mirror of your local machine.

How to set it up:

Navigate to your GitHub repository Settings.
Go to Actions -> Runners.
Click New self-hosted runner and follow the configuration steps for your OS.
Update your workflow .yml file to use the self-hosted label.

Quantifying the Impact on Feedback Loops

By moving to a self-hosted ARM64 runner, my feedback loop became incredibly tight. My tests now finish in 24 seconds, and the entire image creation process takes just 1 minute and 22 seconds.

Here is what the streamlined job looks like:

jobs:
  test:
    runs-on:
      - self-hosted
      - Linux
      - ARM64
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0

      - name: Run tests
        id: run_tests
        run: devenv shell clojure -X:test

The Power of Declarative Environments

Because I’m using devenv shell, I don’t have to worry about whether the CI runner has Clojure, the right JDK, or specific libraries installed. If it works in my local terminal, it works in the CI. Period.

Final Thoughts: Simplify Your Workflow

The way we use GitHub Actions today is often redundant. We spend an enormous amount of time writing complex YAML configurations to install dependencies, manage versions, and configure caching—essentially re-architecting our entire development environment for every single commit.

Provisioning and caching are solved problems. If you are using tools like Devenv or Nix, you’ve already defined exactly what your project needs to run. By moving to a self-hosted runner, you stop fighting the CI and start using it as a natural extension of your workstation. You gain:

Total Parity: If the code runs in your local devenv shell, it will run in CI. No exceptions.
Instant Caching: Since the runner is persistent, you don’t need to upload or download massive cache blobs; the dependencies are already there.
Minimal Configuration: Your workflow files shrink from dozens of lines of setup boilerplate to a single command.

It’s time to stop treating CI like a special snowflake and start treating it like the high-performance terminal it should be. Stop provisioning twice, stop waiting for public runners, and start shipping faster.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

AI Speaks Terraform Like a Tourist

Tue, 14 Apr 2026 00:00:00 GMT

I recently stumbled upon a promoted post for IaCConf 2026 that gave me pause. The headline was claiming that “AI Speaks Terraform Like a Tourist”.

It’s a comforting thought for many, but it gave me cold feet. Seeing “1,000s of IaC practitioners” gathering to discuss this makes me wonder: How many of them will still easily find a new job in a year?

The “Pre-React” Era of DevOps

We often find comfort in the fact that AI currently struggles to maintain complex Terraform repositories. We assume the models just aren’t “smart” enough yet. But I think we’re misdiagnosing the problem.

The struggle isn’t a lack of AI intelligence; it’s a lack of abstraction.

DevOps today is stuck in its own “pre-React” era. Think back to early web development: we separated code by technology—a folder for JS, one for HTML, and one for CSS. Then React arrived, introducing components and encapsulation. Suddenly, the “how” was hidden behind a functional “what”.

Current DevOps often practices separation by technology instead of concerns. This creates a lack of abstraction, forcing practitioners to curate nearly identical Terraform files across different companies, requiring massive amounts of human capital just to manage the boilerplate.

Why the “Tourist” Becomes a “Superhuman”

If AI speaks Terraform like a tourist, it’s because it’s being asked a task that is hard even for human intelligence. However, I’ve noticed a shift: AI speaks BigConfig like a superhuman.

I’ve had to accept that tools like Claude Code are already operating BigConfig better than I can. The reason is simple: BigConfig provides abstractions similar to React components.

Encapsulation: AI doesn’t get lost in the weeds of low-level resource declarations.
Composition: It can compose high-level abstractions to build complex systems.
Context: When the “boring” details are abstracted away, the AI can focus on the architectural intent.

Conclusion

We are at a crossroads similar to the one web developers faced in 2013. You can either be the developer who insists on manually manipulating the DOM, or you can be the one who learns to build with components.

The “tourist” phase of AI in DevOps is a temporary byproduct of our own messy, unabstracted architectures. As we move toward higher-level abstractions like BigConfig, the barrier between “intent” and “infrastructure” will vanish. The practitioners who thrive in 2027 won’t be those who can write the most clever HCL from scratch, but those who can design the abstraction that AI is already equipped to manage today.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

DevOps Without the Code: Infrastructure as Markdown

Mon, 13 Apr 2026 00:00:00 GMT

I wanted to prove a point: you only need Markdown to build non-trivial infrastructure if your abstractions are powerful enough.

Take the once package, for example. It creates a complete platform on any cloud provider—handling DNS, SMTP, and TLS—to deploy your web applications. It’s a self-hosted alternative to Netlify, Vercel, or Fly.io that runs on your own VPS.

From Idea to Infrastructure in 3 Minutes

I started by manually drafting a simple plan in user-plan.md. I then handed that plan to Claude Code and asked it to refine the requirements. Claude generated final-plan.md, a detailed technical roadmap.

Finally, I asked the AI to execute the plan. Within three minutes, I had a working version of the once package tailored to my specific requirements.

The kicker? I didn’t write a single line of Clojure code.

Why It Works: Data Over Code

Even though the underlying engine is Clojure, the configuration is entirely declarative.

The bb.edn file feels more like a Makefile than a programming script.
The EDN format is essentially JSON with a few more superpowers.
The logic is hidden; what’s left is just a list of parameters to tailor the behavior.

I can easily imagine a non-technical user asking an AI to “fill in the missing values” and run the tasks until they work.

BigConfig as the “React of DevOps”

How is this possible? BigConfig is the React of Agentic DevOps. Just as React allows you to build complex frontends using high-level components, BigConfig encapsulates messy Terraform and Ansible code into clean, reusable “infrastructure components.” It’s like HCL (Terraform) modules on steroids because it supports any tool—Ansible, Terraform, Helm, and more—under one unified, data-driven interface.

The milestones

You don’t have to take my word for it. Below are the exact inputs I used so you can reproduce the experiment yourself.

1. The Human Draft (`user-plan.md`)

user-plan.md

You need to create a project to deploy a web application.
This project contains only three files: a `bb.edn` file, a `deps.edn` file, and a `.envrc` file
The deps.edn will contain the dependency https://github.com/amiorin/once
You can download https://github.com/amiorin/once to see how it works.
https://github.com/amiorin/once is built on top of https://github.com/amiorin/big-config
You can download https://github.com/amiorin/big-config to see how it works.
The bb.edn contains a dependency :local/root to the current directory containing the file deps.edn that contains a dependency to https://github.com/amiorin/once
The domain is bigconfig.online.
The host is www.bigconfig.online.
The container is ghcr.io/amiorin/big-config-website:latest
The compute provider is OCI with 6 GB, 1 core, and 50 GB of disk.
The dns provider is Cloudflare.
The smtp provider is Resend.
The backend provider is S3.
You need to need to create the `.envrc` environment variable for the credentials, I will provide the values later.

2. The AI-Refined Plan (`final-plan.md`)

Claude expanded my draft into a robust plan:

final-plan.md

# Deployment plan: bigconfig.online

A three-file project that uses `amiorin/once` to provision OCI + Cloudflare DNS + Resend SMTP + an S3 tofu backend, and hands off container lifecycle + TLS to `basecamp/once` running on the VM.

`amiorin/once` is built on top of `big-config`. Before wiring anything, clone both repos locally and confirm the assumptions in the "Open questions" section below — several env-var names and behaviors here are placeholders until verified against the source.

- https://github.com/amiorin/once
- https://github.com/amiorin/big-config
- https://github.com/basecamp/once (installed on the VM; runs the container + handles TLS)

## Files

- **`deps.edn`** — depends on `io.github.amiorin/once` via `:git/sha`. No `:paths`, no override namespaces.
- **`bb.edn`** — `:deps {:local/root "."}` to pull the sibling `deps.edn`, `:tasks` that `:require` once's tasks so `bb once create` / `bb once delete` are exposed, and a top-level Clojure data structure holding the project options (profile, host, container image, "don't create APEX", etc.) that once's tasks consume.
- **`.envrc`** — exports the variables listed below. Follow once's convention of sourcing `.envrc.private` for secrets, and add `.envrc.private` to `.gitignore`.

## Targets

- **Domain**: `bigconfig.online`
- **Host**: `www.bigconfig.online` — **do not create an APEX record**; if once's `website` profile creates one by default, override it from the `bb.edn` options
- **Container**: `ghcr.io/amiorin/big-config-website:latest` — must publish a `linux/arm64` variant, since the OCI free tier is Ampere A1
- **Compute**: OCI `VM.Standard.A1.Flex`, 1 OCPU, 6 GB RAM, 50 GB boot volume, Ubuntu LTS
- **DNS**: Cloudflare
- **SMTP (domain provisioning + outbound mail)**: Resend
- **Tofu backend**: S3 — the state bucket must exist before the first `tofu init`; pre-create it manually or add a bootstrap task in `bb.edn`

## Container lifecycle

`amiorin/once` provisions the VM and (via Ansible) installs `basecamp/once` on it. `basecamp/once` then pulls and runs the container and handles TLS via Let's Encrypt. As a result, `amiorin/once` does **not** need a `docker run` role, a systemd unit, or a compose file of its own — but `basecamp/once` has its own configuration surface that must be wired through.

## Environment variables (`.envrc`)

Values to be supplied later. `BC_PAR_*` are once/big-config parameter overrides; exact spellings must be confirmed against `src/` in `amiorin/once`.

**Domain & tofu backend**
- `BC_PAR_DOMAIN=bigconfig.online`
- `BC_PAR_HOST=www.bigconfig.online`
- `BC_PAR_PROVIDER_BACKEND=s3`
- `BC_PAR_S3_BUCKET`
- `BC_PAR_S3_REGION`
- `AWS_ACCESS_KEY_ID`
- `AWS_SECRET_ACCESS_KEY`

**OCI (compute)** — once's OCI module will read some combination of these; confirm exact names:
- tenancy OCID
- user OCID
- API key fingerprint
- API private key path
- region
- compartment OCID
- availability domain
- SSH public key (authorized on the VM)
- SSH private key path (used by Ansible to log in)

**Cloudflare (DNS)**
- `BC_PAR_CLOUDFLARE_API_TOKEN`
- `BC_PAR_CLOUDFLARE_ZONE_ID`

**Resend**
- `BC_PAR_RESEND_API_KEY` — provisioning SPF/DKIM records on the domain
- `BC_PAR_RESEND_PASSWORD` — SMTP auth, passed into the container so the website can send mail

**basecamp/once (on the VM)**
- `BC_PAR_ONCE_LETSENCRYPT_EMAIL` — Let's Encrypt registration address
- `BC_PAR_ONCE_LICENSE_KEY` — only if `big-config-website` is deployed as a licensed Basecamp product; omit if it's a bring-your-own container

**Container registry (ghcr.io)** — only if the image is private:
- `GHCR_USERNAME`
- `GHCR_TOKEN`

## Guideline

Avoid writing Clojure source files. Everything is data: project options live in `bb.edn` as a Clojure map, secrets live in `.envrc` / `.envrc.private`. The only "code" is the `:tasks` wiring in `bb.edn` that hands the options map to once's tasks.

## Open questions to resolve before implementing

1. **Options loading.** Does `amiorin/once` accept project options as a data arg passed from `bb.edn`, or does it require a Clojure namespace on the classpath? Determines whether the "no source files" guideline is achievable as-is.
2. **Profile.** Does once's `website` profile already target `bigconfig.online` / `www` / the ghcr image? If not, how is it overridden from the `bb.edn` options map?
3. **Exact `BC_PAR_*` names** for OCI, SSH keys, container image, and basecamp/once inputs — derive from once's source rather than guessing.
4. **basecamp/once scope.** Does it host arbitrary containers, or does it require a product manifest? What does it actually need at install time (email, license, domain)?
5. **Image.** Is `ghcr.io/amiorin/big-config-website:latest` public, and does it publish `linux/arm64`?
6. **APEX.** Does the `website` profile create an apex record by default? If yes, wire the override through the `bb.edn` options map.
7. **S3 bucket bootstrap.** Pre-create manually, or automate via a bootstrap task in `bb.edn`?

3. The Result: `bb.edn`

This is the heart of the deployment: a concise mix of requirements, data structures, and tasks. Notice how it reads like a declarative configuration manifest rather than a complex program.

bb.edn

{:deps {bigconfig/online {:local/root "."}}
 :tasks
 {:requires ([big-config.render :as render]
             [big-config.workflow :as workflow]
             [io.github.amiorin.once.package :as package]
             [io.github.amiorin.once.params :as params]
             [io.github.amiorin.once.tools :as tools])

  :init (def bigconfig-online
          {:big-config.render/profile "online"
           :big-config.workflow/params
           {:package "online"
            :domain  "bigconfig.online"

            :provider-compute           "oci"
            :oci-config-file-profile    "DEFAULT"
            :oci-compartment-id         "FILL-ME-IN"
            :oci-subnet-id              "FILL-ME-IN"
            :oci-availability-domain    "FILL-ME-IN"
            :oci-display-name           "bigconfig-online"
            :oci-shape                  "VM.Standard.A1.Flex"
            :oci-ocpus                  1
            :oci-memory-in-gbs          6
            :oci-boot-volume-size-in-gbs 50
            :oci-boot-volume-vpus-per-gb 30
            :oci-ssh-authorized-keys    "~/.ssh/id_ed25519.pub"

            :provider-smtp   "resend"
            :resend-server   "smtp.resend.com"
            :resend-port     587
            :resend-username "resend"

            :provider-dns "cloudflare"

            :provider-backend "s3"
            :s3-bucket        "FILL-ME-IN"
            :s3-region        "eu-west-1"

            :once {:applications [{:host  "www.bigconfig.online"
                                   :image "ghcr.io/amiorin/big-config-website"}]}}})

  once           {:doc  "bb once create | bb once delete"
                  :task (package/once* *command-line-args* bigconfig-online)}
  tofu           {:doc  "bb tofu render tofu:init tofu:apply:-auto-approve"
                  :task (tools/tofu* *command-line-args* (params/once-opts bigconfig-online))}
  tofu-smtp      {:doc  "bb tofu-smtp render tofu:init tofu:apply:-auto-approve"
                  :task (tools/tofu-smtp* *command-line-args* (params/once-opts bigconfig-online))}
  tofu-dns       {:doc  "bb tofu-dns render tofu:init tofu:apply:-auto-approve"
                  :task (tools/tofu-dns* *command-line-args* (params/once-opts bigconfig-online))}
  tofu-smtp-post {:doc  "bb tofu-smtp-post render tofu:init tofu:apply:-auto-approve"
                  :task (tools/tofu-smtp-post* *command-line-args* (params/once-opts bigconfig-online))}
  ansible        {:doc  "bb ansible render -- ansible-playbook main.yml"
                  :task (tools/ansible* *command-line-args* (params/once-opts bigconfig-online))}
  ansible-local  {:doc  "bb ansible-local render -- ansible-playbook main.yml"
                  :task (tools/ansible-local* *command-line-args* (params/once-opts bigconfig-online))}}}

Final Thoughts

By treating infrastructure as pure data, we remove the “syntax tax” of Clojure. Whether you are a seasoned developer or a non-technical founder, BigConfig provides a path to professional-grade DevOps without the steep learning curve.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

BigConfig: The "React" for Agentic DevOps

Sun, 12 Apr 2026 00:00:00 GMT

When you ask an AI to write a 500-line Terraform file, you are essentially asking it to write assembly code for your deployment. It’s brittle, verbose, and prone to “hallucinated” parameters.

The shift is simple: stop using DevOps tools like Terraform and Ansible directly. Instead, ask your Agent to use React-style components for DevOps. By shifting the Agent’s focus from “writing code” to “composing components,” you gain the same benefits developers got when they moved from jQuery to React: reusability, predictability, and a massive reduction in logic errors.

Enter BigConfig: the “React for DevOps.” It allows you to use high-level abstractions that ensure your Agent’s output is deterministic, modular, and cost-effective.

The Vision: Agentic + Data-Driven DevOps

By combining Claude Code (Max Effort with planning) with BigConfig and the once package, you create a platform-as-a-service (PaaS) experience—like Vercel or Netlify—but running on your own hardware. You don’t need to master Clojure or complex DSLs; you just provide the intent, and the Agent handles the implementation using reliable components.

The root directory

Your App source code: An Astro managed via pnpm. But Claude can adapt it to Rails/Django/Next/Phoenix/Spring.
BigConfig source code: The framework for “infrastructure components.” It reduces token consumption by using high-level abstractions.
Once source code: A pre-built component implemented in BigConfig that turns any VPS into a personal PaaS.
The Glue files: GitHub Actions and Docker to bridge your code to your cloud.

The Workflow: Zero-Touch Deployment

I use Claude Code (4.6 Max Effort with planning) to manage the entire lifecycle. I create a directory containing everything and then I simply ask Claude to deploy.

Out of the box, this setup supports OCI, DigitalOcean, and Hetzner for compute, Resend for email, and Cloudflare for DNS. If you need a different provider, you don’t write the code; you just ask Claude to implement the main.tf for you.

1. The Web Server (Caddyfile)

We use Caddy for serving the Astro SSG website. This handles our health checks too.

Caddyfile

:80 {
    handle /up {
        header Content-Type text/plain; charset=utf-8
        respond `OK` 200
    }

    handle {
        root * /srv
        file_server
    }
}

2. The Container (Dockerfile)

A multi-stage build that keeps our final image slim and secure. Note the inclusion of D2 for documentation as an example of a build of Astro with a plugin.

Dockerfile

FROM node:22-alpine AS builder

RUN apk add --no-cache curl make && \
    curl -fsSL https://d2lang.com/install.sh | sh

RUN corepack enable && corepack prepare pnpm@latest --activate

WORKDIR /app

COPY package.json pnpm-lock.yaml* ./
RUN pnpm install --frozen-lockfile

COPY . .
RUN pnpm build

FROM caddy:2-alpine

COPY Caddyfile /etc/caddy/Caddyfile
COPY --from=builder /app/dist /srv

EXPOSE 80

3. The Pipeline (GitHub Action)

This action builds the image for ARM architecture (optimized for modern VPS providers) and pushes it to the GitHub Container Registry (GHCR). Remember to make the image public.

.github/workflows/docker-publish.yml

name: Build and Publish Docker Image

on:
  push:
    branches:
      - main # Adjusted to standard branch naming
  workflow_dispatch:

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-push:
    runs-on: ubuntu-24.04-arm
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract Docker metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=raw,value=latest
            type=sha

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Summary

To deploy, you simply point Claude to your root folder and say:

“Adapt my Astro project to create a GHCR docker image and update the Once project to use this container on a Hetzner VPS.”

Because of BigConfig, Claude isn’t guessing how to configure a server—it’s just filling in the props for a “Component” that already knows how to work. This is the future of DevOps: high level abstraction and Agents.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

The Evolution of DevOps: From Separation by Technology to Separation by Concerns

Thu, 02 Apr 2026 00:00:00 GMT

The current state of DevOps feels eerily similar to the dark ages of Frontend development before the React revolution.

In the early days of the web, we practiced Separation by Technology. We kept our CSS in one folder, our HTML in another, and our JavaScript in a third. We were told this was clean, but in reality, it was a nightmare to maintain. To change a single button, you had to hunt through three different files in three different directories.

React changed the game by introducing Separation by Concerns. It recognized that a Component is the natural unit of work. A component encapsulates its logic, structure, and styling into a single, cohesive module.

The Modern DevOps Bottleneck

Today, DevOps is still stuck in the Separation by Technology phase. We segregate our logic by the tools we use:

Terraform/OpenTofu for infrastructure.
Ansible for configuration.
Kubernetes for orchestration.

While Kubernetes has moved us toward immutability, it has also introduced the YAML trap . Furthermore, the real world isn’t always immutable. We don’t discard a developer’s machine every time we need a minor package upgrade, and stateful services (like databases) require delicate, mutable handling that pure-container strategies struggle to manage.

Enter BigConfig: The Component-Based Approach

BigConfig applies the React philosophy to DevOps. Instead of managing a Terraform repo and an Ansible repo you manage Packages.

For example, the BigConfig Package once utilize four Terraform projects and two Ansible projects under the hood, but to the user, it is a single, functional unit.

The Coupling Problem: A Practical Example

Consider a simple task: checking if the the server can send emails. Ansible needs to create a .mailrc file so the operator can use s-nail CLI to test the SMTP connection during an incident.

The Traditional Way: The infrastructure (SMTP infrastructure) is defined in OpenTofu, but the .mailrc configuration lives in an Ansible folder. This creates strong coupling. If you change your SMTP provider or port, you must manually update two different repositories.
The BigConfig Way: Responsibility is delegated, not segregated. The Tofu SMTP component is responsible for generating the configuration data, while Ansible is simply the delivery mechanism that places the file on the server. The file source path acts as a clean interface. One change in the SMTP component automatically flows through the system.

Modularity and Referential Transparency

The power of a Separation of Concerns architecture lies in its modularity. In the BigConfig Package once, we categorize providers into functional types: Compute, DNS, and SMTP.

Interchangeability: Our Compute component has three implementations: OCI, Hetzner, and DigitalOcean. Because these are built as components, you can swap one for another without touching your DNS or SMTP logic.
Referential Transparency: We utilize “no-infra” components as placeholders. This allows you to bring your own pre-existing infrastructure into the system. You can replace a live resource with its values without changing the behavior of the rest of the stack. In programming, this is called referential transparency; in DevOps, it makes brownfields easier to support.
No Degradation of Experience: Usually, abstractions make debugging harder. BigConfig is designed so that the composition of components doesn’t hide the underlying tools. You can manage the entire Composition as one, or drop down to debug a single component (like a specific Tofu component) without any additional configuration overhead.

Conclusion

We are moving past the era of “Tool-First” DevOps. By adopting a component-based mindset, we can stop managing scripts and start building systems that are as modular, testable, and maintainable as our modern frontend applications.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

Vibe Coding Meets Vibe Ops: Automating the Last Mile of Deployment

Wed, 01 Apr 2026 00:00:00 GMT

Vibe coding has made building web applications faster and more intuitive than ever, but the Ops side of the house hasn’t quite kept up. While 37signals’ ONCE simplified the deployment architecture for vibe coders, managing the underlying infrastructure—Compute, DNS, and SMTP—remains a fragmented, manual process.

Enter the BigConfig once : the missing link that automates the manual out of your deployment pipeline.

Zero-Friction Infrastructure

BigConfig turns complex infrastructure provisioning into a few simple terminal commands. No more hunting for IP addresses or manually editing SSH configs.

Provision your VPS instantly

git clone https://github.com/amiorin/once
cd once
bb once create

Jump straight into your server (SSH config is auto-populated)
```
ssh once
```
Start ONCE TUI in your server to deploy your vibe coded application
```
sudo once
```

1. Compute

While Oracle and Hetzner are supported out of the box, BigConfig is built for extensibility. Adding a new compute provider is trivial, ensuring you aren’t locked into a single ecosystem.

2. DNS

Cloudflare integration is ready to go. Point your domain and let BigConfig handle the records, ensuring your application is reachable as soon as the compute instance is live.

3. SMTP

Transactional email is handled via Resend by default. Like the other modules, swapping this for another SMTP service is simple and straightforward.

The Vision: Dev & Ops in Plain English

The roadmap for BigConfig is headed toward a Natural Language Infrastructure. The next milestone is teaching Claude Code to utilize the BigConfig once .

Soon, a vibe coder won’t just write code in English—they will manage their entire production environment through conversation, blurring the line between development and operations entirely.

Current Manual Hurdles

We’ve automated the heavy lifting, but a few Human-in-the-Loop steps remain—mostly due to provider security and billing requirements. In the age of agentification, these hurdles may not last long:

Domain Registration: Snagging budget domains (like .website or .online for $0.85) via Namecheap is still a manual checkout process.
Oracle Cloud Setup: Creating an account requires a physical credit card. To unlock the Always Free tier (4 cores, 24 GB RAM), you must manually switch to a Pay-As-You-Go account and generate your API credentials.
The Namecheap-Cloudflare Bridge: Because Namecheap doesn’t offer an API for smaller accounts, pointing your Namecheap domain to Cloudflare DNS and generating an API token remains a manual task.
Resend Setup: Account creation and initial API key generation must be done via their web dashboard.

Conclusion

The gap between vibe coding a masterpiece and actually shipping it to a live URL is narrowing. By wrapping the fragmented worlds of VPS provisioning, DNS routing, and SMTP configuration into a unified, programmable workflow, BigConfig transforms deployment from a weekend chore into a minor detail. While a few manual gates like billing and domain registration remain—reminders of the physical world we still inhabit—the path toward a fully conversational, Natural Language Infrastructure is clear.

We are rapidly approaching a reality where the Ops in DevOps is as effortless as the Dev. If you’re ready to stop wrestling with dashboards and start shipping at the speed of thought, it’s time to give the BigConfig a spin.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

The Power of Framing: Why BigConfig is Rebranding as a Package Manager

Fri, 13 Mar 2026 00:00:00 GMT

BigConfig began as a simple Babashka script designed to DRY up a complex Terraform project for a data platform. Since those humble beginnings, it has evolved through several iterations into a robust template and workflow engine. But as the tool matured, I realized that technical power wasn’t enough; the way it was framed was the true barrier to adoption.

The Language Barrier (and the Loophole)

BigConfig is powerful as a library, but I’ve faced a hard truth: very few developers will learn a language like Clojure just to use a library. However, history shows that developers will learn a new language if it solves a fundamental deployment problem.

People learned Ruby to master Homebrew ; they learn Nix for reproducible builds. Meanwhile, tools like Helm force users to juggle the awkward marriage of YAML and Go templates—a “solution” many endure only because no better alternative exists. To get developers to cross the language barrier, you have to offer more than a tool; you have to offer a total solution.

The “Package Manager” Epiphany

I noticed a significant shift in engagement depending on how I framed the project. When I describe BigConfig as a library, it feels abstract—like “more work” added to a developer’s plate. When I introduce it as a package manager, the interest is immediate.

In the mind of a developer, a library is a component you have to manage. A package manager is the system that manages things for you. By shifting the perspective, BigConfig goes from being a “Clojure utility” to an “Infrastructure Orchestrator.”

How BigConfig Differs

Like Nix and Guix , BigConfig embraces a full programming language. However, it avoids the “two-language architecture” common in those ecosystems—where you often have a compiled language for the CLI and a separate interpreted one for the user.

BigConfig is Clojure all the way down (in the spirirt of Emacs). This allows it to support three distinct environments seamlessly:

The REPL: For interactive development and real-time exploration.
The Shell: For traditional CLI workflows and CI/CD pipelines.
The Library: For embedding directly into your own control planes or APIs.

Beyond the language, BigConfig introduces robust client-side coordination, featuring an Atlantis-style locking mechanism that uses GitHub tags to prevent developer collisions in shared environments.

Limitless Abstraction

The level of abstraction is where BigConfig truly shines. When you adopt the system, you aren’t locked into a rigid schema; you can adapt the entire engine to your specific needs. Complex tasks—like deploying the same architecture across different hyperscalers—are reduced from massive refactors to simply updating a property. It moves the conversation from how to deploy to what to deploy.

The Roadmap

The next phase is focused on expanding the ecosystem and making package discovery seamless:

Hyperscaler Support: Having already added DigitalOcean , Hetzner , and Oracle Cloud , I am now prioritizing AWS , Google Cloud , and Azure .
Application Packages: While the first “app”—a remote development environment—is a niche use case, I’m expanding into high-demand stacks like Airflow and Rama .
The Ecosystem: I am currently defining the formal package manifest and building a registry where users can discover, version, and publish their own infrastructure packages.

Conclusion

The evolution of BigConfig is a testament to the idea that the right abstraction is just as important as the right code. By reframing the tool from a utility you have to manage into a system that manages for you, we bridge the gap between complex cloud resources and developer productivity.

As we expand our hyperscaler support and formalize our package registry, the goal remains the same: to move infrastructure management away from the “how” and toward the “what.” Whether you are deploying a niche remote environment or a massive data stack like a Data Lake, BigConfig provides the language and the logic to make your infrastructure as versionable and reproducible as your software.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

Simple over easy for operations

Wed, 11 Mar 2026 00:00:00 GMT

Building a workflow engine for infrastructure operations is not trivial. Most people start with a simple mental model: a desired state and a sequence of functions that produce side effects. In Clojure, this looks like a simple thread-first macro:

(-> {}
    fn1
    fn2
    ...)

Your state {} is threaded through fn1 and fn2. However, real-world operations are rarely linear. They require complex branching, error handling, and conditional jumps (e.g., “if success, continue; otherwise, jump to cleanup”).

Wiring the Engine

To handle non-linear flows, we associate functions with qualified keywords (steps). Together with the next step, they form the “wiring”. You can override sequential execution by providing a next-fn to handle custom branching.

The core execution loop looks like this:

(loop [step first-step
       opts opts]
  (let [[f next-step] (wire-fn step step-fns)
        new-opts (f opts)
        [next-step next-opts] (next-fn step next-step new-opts)]
    (if next-step
      (recur next-step next-opts)
      next-opts)))

Workflow Example

Here is how we use this engine to create a client-side lock for Terraform using Git tags. The opts map represents our “World State”, shared across all functions.

We invoke it like this: (lock [] {}). The first argument is a list of middleware-style step functions, and the second is the starting state.

(->workflow {:first-step ::generate-lock-id
             :wire-fn (fn [step _]
                        (case step
                          ::generate-lock-id [generate-lock-id ::delete-tag]
                          ::delete-tag [delete-tag ::create-tag]
                          ::create-tag [create-tag ::push-tag]
                          ::push-tag [push-tag ::get-remote-tag]
                          ::get-remote-tag [(comp get-remote-tag delete-tag) ::read-tag]
                          ::read-tag [read-tag ::check-tag]
                          ::check-tag [check-tag ::end]
                          ::end [identity]))
             :next-fn (fn [step next-step opts]
                        (case step
                          ::end [nil opts]
                          ::push-tag (choice {:on-success ::end
                                              :on-failure next-step
                                              :opts opts})
                          ::delete-tag [next-step opts]
                          (choice {:on-success next-step
                                   :on-failure ::end
                                   :opts opts})))})

Debugging Made Simple

In many CI/CD systems, debugging is a nightmare of “print” statements and re-running 10-minute pipelines. Because Clojure data structures are immutable and persistent, we can use a debug macro provided by BigConfig and a “spy” function to inspect the state at every step.

(comment
  (debug tap-values
    (create [(fn [f step opts]
               (tap> [step opts]) ;; "Spy" on every state change
               (f step opts))]
            {::bc/env :repl
             ::tools/tofu-opts (workflow/parse-args "render")
             ::tools/ansible-opts (workflow/parse-args "render")})))

Using tap>, you get the result “frozen in time”. You can render templates and inspect them without ever executing a side effect.

Solving the Composability Problem: Nested Options

Operations often require calling the same sub-workflow multiple times. If every workflow uses the same top-level keys, they clash. We solve this with Nested Options.

By using the workflow’s namespace as a key, we isolate state. However, sometimes a child needs data from a sibling (e.g., Ansible needs an IP address generated by Terraform). We use an opts-fn to map these values explicitly at runtime.

The specialized ->workflow* constructor uses this next-fn to manage this state isolation:

(fn [step next-step {:keys [::bc/exit] :as opts}]
  (if (steps-set step)
    (do
      (swap! opts* merge (select-keys opts [::bc/exit ::bc/err]))
      (swap! opts* assoc step opts))
    (reset! opts* opts))
  (cond
    (= step ::end) [nil @opts*]
    (> exit 0)     [::end @opts*] ;; Error handling jump
    :else
    [next-step (let [[new-opts opts-fn]
                     (get step->opts-and-opts-fn next-step [@opts* identity])]
                 (opts-fn new-opts))]))

This logic ensures that if a step is a sub-workflow, its internal state is captured within the parent’s state under its own key. The opts-fn allows us to bridge the gap—for instance, pulling a Terraform-generated IP address into the Ansible configuration dynamically.

The Working Directory and the Maven Diamond Problem

In operations, you must render configuration files before invoking tools. If you compose multiple workflows, you run into the “Maven Diamond Problem”: two different parent workflows sharing the same sub-workflow. To prevent them from overwriting each other’s files, we use dynamic, hashed prefixes for working directories:

.dist/default-f704ed4d/io/github/amiorin/alice/tools/ansible

The hash f704ed4d is dynamic. If a workflow is moved or re-composed, the hash changes, ensuring total isolation during template rendering.

Conclusion: Simple over Easy

Tools like AWS Step Functions , Temporal , or Restate are powerful workflow engines, but for many operational tasks, they are not a good fit. BigConfig has an edge because it is local and synchronous where it counts. It turns infrastructure into a local control loop orchestrating multiple tools.

In the industry, “Easy” (using the same language as the backend, like Go) often wins over “Simple”. But Go lacks a REPL, immutable data structures, and the ability to implement a debug macro that allows for instantaneous feedback.

Infrastructure eventually becomes a mess of “duct tape and prayers” when the underlying tools aren’t built for complexity. If you choose Simple over Easy, Clojure is the best language for operations—even if you’re learning Clojure for the first time.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

Composability: Orchestrating Infrastructure with Babashka and BigConfig Package

Tue, 10 Mar 2026 00:00:00 GMT

In the world of Clojure and DevOps, Babashka has become the gold standard for fast, scripted automation. Today, we’re exploring how to leverage the BigConfig Package with Babashka to create highly composable infrastructure workflows that are as flexible as they are powerful.

Getting Started

One of BigConfig Package’s greatest strengths is its CLI-first approach. You can invoke the walter package directly from your terminal to run complex sequences in a single line. For example, to cycle through an environment lifecycle:

bb walter create delete create delete

bb: The Babashka runtime.
walter: The specific task defined in your configuration.
create/delete: Individual steps within the workflow. You can chain these steps in any order or frequency required by your pipeline.

Configuration

To integrate walter package into your project, define your dependencies and tasks in your bb.edn file. This acts as the central configuration for your automation.

bb.edn

{:deps {io.github.amiorin/walter {:git/sha "4ea205299cf34c29fa289eacb512a31bfe604d93"}}
 :tasks
 {:requires ([io.github.amiorin.walter.package :as package]
             [io.github.amiorin.walter.tools :as walter]
             [io.github.amiorin.alice.tools :as alice])

  tofu {:doc "Render and apply OpenTofu (Terraform) plans"
        :task (walter/tofu* *command-line-args* (package/walter-opts {:big-config.workflow/params {:hyperscaler "oci"}}))}

  ansible {:doc "Run Ansible playbooks"
           :task (walter/ansible* *command-line-args* (package/walter-opts {}))}

  ansible-local {:doc "Run local Ansible playbooks via the 'alice' package"
                 :task (alice/ansible-local* *command-line-args* (package/walter-opts {}))}

  walter {:doc "Primary Walter workflow"
          :task (package/walter* *command-line-args* {:big-config.workflow/params {:hyperscaler "oci"}})}}}

Key Components

:deps: Targets the specific Git SHA of the walter package for reproducible builds.
Workflow Structure: A package typically splits logic between package.clj and tools.clj. The former composes multiple tools—like OpenTofu and Ansible—into a unified, high-level workflow.

Parameters and Composability

The walter task utilizes a primary parameter: :hyperscaler. Currently, the package offers out-of-the-box support for Oracle Cloud (OCI) and Hetzner.

Uniformity across workflows

The function (package/walter-opts ...) is the “glue” of the system. It handles two critical requirements:

Directory Mapping: Every tool needs a specific location to render configuration files. This function ensures these are correctly mapped based on the parent workflow.
Options Consistency: By populating the :big-config.workflow/params, it ensures that all tasks—whether tool-specific or package-wide—share the same options.

Cross-Package Integration

BigConfig Package excels at mixing and matching. While tofu and ansible are defined inside the walter package, you can seamlessly pull in tasks like ansible-local from entirely different packages (such as alice).

Developer Tip: Even when nesting workflows inside a larger process, you retain the ability to invoke sub-workflows interactively. This makes debugging specific infrastructure segments significantly faster.

Conclusion

By transforming standard Terraform and Ansible code into a managed workflow, you gain the ability to invoke resources multiple times with surgical precision. Since the only persistent state is the Terraform state (ideally stored in an S3 backend), your entire team can operate the same resources from different machines.

Beyond standard deployment, BigConfig Package provides built-in coordination steps like git-check, git-push, lock, and unlock-any. These utilities ensure that whether you are working in a tool-specific workflow or a massive package-wide deployment, your team remains in sync and your iing and configuration management, BigConfig Package removes the friction typically found in multi-cloud deployments. This modular anfrastructure remains stable.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

BigConfig Package Walter Fork this package or use the package template.

Universal Infrastructure: Solving the Portability Gap with BigConfig

Mon, 09 Mar 2026 00:00:00 GMT

The primary challenge with Terraform and Ansible has always been portability. It is notoriously difficult to take a solution written for one environment and apply it to another without significant manual adjustments. Kubernetes achieved its massive success by leveling this playing field. With tools like Helm, you have a package manager that allows you to install applications without worrying about whether you are on-prem or using a specific hyperscaler.

However, in the world of Kubernetes, a common sentiment is to avoid stateful applications like databases unless you have mastered every technical nuance. Most internal platforms use Kubernetes for stateless services while relying on managed databases provided by the hyperscaler.

BigConfig Package changes this dynamic by enabling the creation of universal applications that are both stateful and stateless. Walter , the first application built with BigConfig, demonstrates this by deploying seamlessly across Oracle Cloud and Hetzner.

The Portability Challenge

Infrastructure is rarely uniform. When moving between providers, you encounter several inconsistencies:

The IP address property is named differently depending on the provider.
The default SSH user varies.
The UID of the default user is often inconsistent.

The solution involves defining a standardized schema for output parameters in every main.tf file:

Gluing Infrastructure to Configuration

This approach effectively glues the OpenTofu infrastructure step to the Ansible configuration step. By parsing the JSON output from the infrastructure layer, we can pass critical connection data directly into the workflow:

(defn opts-fn
  [opts]
  (let [dir (workflow/path opts ::tools/tofu)]
    (merge-with merge opts {::workflow/params (if (fs/exists? dir)
                                                (-> (p/shell {:dir dir
                                                              :out :string} "tofu output --json")
                                                    :out
                                                    (json/parse-string keyword)
                                                    (->> (s/select-one [:params :value])))
                                                {:ip "192.168.0.1"
                                                 :sudoer "ubuntu"})})))

As long as the OpenTofu step adheres to the schema by providing an ip, sudoer, and uid, any new hyperscaler can be integrated into this BigConfig Package.

Handling Distribution Differences

What about variations in Linux distributions? This can be handled within Ansible or, similar to our Terraform approach, by using different source files based on the distribution.

(defn tofu
  [step-fns opts]
  (let [opts (workflow/prepare {::workflow/name ::tofu
                                ::render/templates [{:template (keyword->path ::tofu)
                                                     :overwrite true
                                                     :hyperscaler "hcloud"
                                                     :transform [["{{ hyperscaler }}"]]}]}
                               opts)]
    (workflow/run-steps step-fns opts)))

The power lies in the dynamic folder pathing. By using the template variable "{{ hyperscaler }}" for the hyperscaler, the directory containing the infrastructure code becomes dynamic. This allows us to share core Ansible logic while diverging where necessary, ensuring the code remains clean and manageable.

Conclusion

By standardizing the handshake between infrastructure provisioning and configuration management, BigConfig Package removes the friction typically found in multi-cloud deployments. This modular approach ensures that your automation remains truly portable, allowing stateful workloads to run wherever they are needed most without being locked into a single provider’s ecosystem.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

BigConfig Package Walter Fork this package or use the package template.

The YAML Trap: Escaping Greenspun’s Tenth Rule with BigConfig

Thu, 26 Feb 2026 00:00:00 GMT

Greenspun’s Tenth Rule is a famous (and delightfully cynical) adage in computer science. While it was born in the era of C and Fortran, it has never been more relevant than it is today in the world of Platform Engineering.

If you’ve ever felt like your CI/CD pipeline is held together by duct tape, YAML-indentation prayers, and sheer willpower, you’ve lived this rule.

What is Greenspun’s Tenth Rule?

In the early 90s, Philip Greenspun stated:

“Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.”

The core insight is that once a system reaches a certain level of complexity, it inevitably requires high-level abstraction, automation, and dynamic logic. Instead of starting with a powerful, established language (like Lisp) built for those tasks, developers often “accidentally” reinvent a mediocre version of one using brittle configuration files and makeshift scripts.

The Rule in the DevOps Ecosystem

In DevOps, we strive for Infrastructure as Code (IaC). However, because we started with static configuration formats (YAML/JSON) and tried to force them to perform complex logic, we’ve essentially proven Greenspun right.

1. The YAML “Programming” Trap

Tools like Terraform, Ansible, Helm, and GitHub Actions began as simple configuration formats. But as users demanded loops, conditionals, and variables, these tools evolved into “accidental” languages.

The Problem: You end up writing complex business logic inside strings within a YAML file.
The Reality: You are using a “bug-ridden implementation” of a real programming language, but without the benefit of a debugger, a compiler, or proper unit testing.

2. Kubernetes as a Distributed Lisp

Some architects argue that Kubernetes is the ultimate manifestation of this rule. Its control loop the constant cycle of reconciling desired state vs. actual state mimics the recursive nature of Lisp environments. It is, in essence, a programmable platform designed to manage other programs.

Escaping the Trap: Putting Lisp Back in Ops

The industry has invested massive human capital into building Ansible roles, Helm charts, and Terraform modules. We shouldn’t throw them away, but we must stop trying to make them do things they weren’t designed for.

How do we escape Greenspun’s trap without rebuilding everything from scratch? By assimilating these tools (to borrow a 90s Star Trek reference).

This is the core design principle of BigConfig. Instead of fighting against limited YAML DSLs, BigConfig uses Clojure a modern, production-grade Lisp to wrap and orchestrate existing tools.

The BigConfig Philosophy: Express infrastructure logic with the most powerful dynamic language available, while still leveraging the ecosystem you already have.

Why it Matters: The Power of Assimilation

The Tenth Rule is a warning: Don’t reinvent the wheel poorly. If your infrastructure requires complex logic, stop forcing it into a flat config file.

From Static Files to Fractal Architecture

While a standard Helm package is limited strictly to Kubernetes, a BigConfig package is a Clojure function. Because BigConfig assimilates Ansible and Terraform alongside Helm, it isn’t siloed.

Truly Cloud Native: A Kubernetes application that requires specific cloud resources (like an S3 bucket or an RDS instance) can be abstracted into a single, cohesive unit.
First-Class Functions: In BigConfig, everything is a function. This leads to a fractal architecture where every layer from a single container to a multi-region cloud deployment is governed by the same recursive logic: Observe, Diff, and Act.

Ready to stop writing logic in YAML?

Operations is a hard problem. YAML is too rigid, and Go is too low-level for rapid infrastructure iteration. While Python and JavaScript are popular, they lack the REPL-driven development flow that makes infrastructure-as-code feel truly interactive.

Clojure is the most robust Lisp available today and it won’t let you down.

Conclusion

Greenspun’s Tenth Rule isn’t just a witty observation; it’s a technical debt warning. When we try to solve 21st-century infrastructure challenges using static configuration files, we inevitably end up building “shadow” programming languages that are difficult to test, impossible to debug, and fragile to scale.

By embracing a functional, Lisp-based approach through BigConfig, we stop fighting the limitations of YAML and start leveraging the power of actual logic. Instead of building a “bug-ridden implementation of half of Common Lisp,” we use the real thing Clojure to orchestrate, automate, and scale.

The goal of Platform Engineering shouldn’t be to write more scripts; it should be to create elegant, recursive systems that can manage themselves. It’s time to move past the duct tape and prayers and give our infrastructure the robust, dynamic foundation it deserves.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

Introducing BigConfig Package

Mon, 23 Feb 2026 00:00:00 GMT

Helm has long been the gold standard for Kubernetes, but it hits a wall the moment you step outside the cluster. While there are projects to bridge this gap, they never quite achieved Helm’s level of ubiquity.

BigConfig Package is taking a different path. It aims to deliver both infrastructure and software as a unified, cohesive delivery.

The Case Against the “CLI Proliferation”

One of the most radical aspects of BigConfig Package is what it lacks: a dedicated CLI. In BigConfig’s philosophy, a CLI is just another tool that end-users should tailor to their specific needs. We argue that the current explosion of specialized CLIs is actually a symptom of unsolved underlying problems:

Bash Limitations: The fragility of shell scripting forces developers to wrap logic in binaries.
Interoperability Gaps: Integrating multiple CLI tools via scripting is often easier than managing complex library dependencies, leading to “scripting fatigue.”
The Go Paradox: While static languages like Go are excellent for single binary deployments, they force the creation of monolithic tools that make composition more difficult (e.g., Terraform plugin is based on GRPC).

BigConfig solves these issues by leveraging Clojure and Babashka. By using a dynamic, high-performance language, we replace rigid tools with flexible Babashka tasks, offering the power of a library with the convenience of a script.

The Three Environments: Shell, REPL, and Lib

Most DevOps professionals only interact with tools (like Helm) in the Shell environment. BigConfig expands this to three distinct planes:

Shell: For quick, command-line execution.
REPL: For real-time, interactive debugging and experimentation. No more “edit-coffee-fail” loops.
Lib: For deep automation. You can orchestrate complex scenarios without reimplementing anything when switching gear from CLI tool to in-house solution.

What is a BigConfig Package?

There is no need to reinvent the wheel. A BigConfig Package is simply a Clojure repository, and the package itself is just a Clojure function written with BigConfig Workflow .

Our first application, Walter , tackles a challenge Helm simply wasn’t built for: Remote Development Environments on machines instead of containers.

While devcontainers are popular, containerizing a full development environment on Kubernetes has significant overhead and limitations. Nix is the superior choice here. Its native multi-user support makes it ideal for high-powered “beefy” machines shared by multiple developers.

In this setup, Terraform and Ansible do the heavy lifting but remain completely hidden once development is complete, leaving behind a clean interface that doesn’t “leak” its underlying complexity.

The use case of Remote Development Environment is getting traction and by integrating a Linux user to run a self-hosted GitHub runner, you unlock massive efficiency:

Cost Reduction: Run Dev and CI on the same hardware.
Instant Caching: CI pipelines never miss a cache hit because the environment is shared.
Absolute Parity: “Works on my machine” becomes a reality because the Dev and CI environments are identical.
Native Speed: Docker runs natively, eliminating the virtualization overhead found on macOS or Windows.

Comparison: Helm vs. Babashka

The Helm Way

In this paradigm, you manage repositories and install charts. It typically requires juggling YAML, Go templates, and Bash.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-redis bitnami/redis

The Babashka Way

With BigConfig, helm install becomes bb redis create. The CLI is defined by the package creator but can be customized by the user.

We use create instead of install in this case because the infrastructure is part of the delivery. Using bb instead of bash provides a unified environment where everything is written in Clojure, replacing the fragmented mix of Bash, Compiled Go, and YAML.

;; bb.edn
{:deps {io.github.amiorin/redis {:git/sha "eaff6f"}}
 :tasks
 {:requires ([redis :as redis])
  redis {:doc "Provision a Redis instance"
         :task (comp-wf/redis* *command-line-args*)}}}

bb redis create
bb redis delete

Conclusion

The era of managing a dozen different CLIs just to deploy a single stack is reaching its breaking point. BigConfig offers a way out, not by building a bigger tool, but by providing a more flexible foundation. By unifying the way we handle infrastructure and applications through Clojure, we aren’t just deploying software; we are creating a more cohesive, reproducible, and developer-friendly ecosystem.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

My Keyboard Endgame: 34 Keys, 3 Layers, and a Macropad

Fri, 13 Feb 2026 00:00:00 GMT

I spend a lot of time analyzing other people’s “endgame” setups, and I honestly don’t understand why so many users accept such steep learning curves.

The secret to a sustainable workflow is simplicity. If your layout is so complex that a month away from your desk “drives you nuts” when you return, it’s not an endgame—it’s a chore. Here is how I stripped my setup down to the essentials without losing productivity.

The Hardware Philosophy

34 Keys is Enough: I’m a Ferris Sweep MX devotee. You can buy the the Silakka54 from Aliexpress if you are on a budget.
2 Thumb Keys: You don’t need a cluster; two well-placed keys are sufficient.
Externalize the Complexity: Don’t cram multimedia into layers. Use a dedicated macropad like the Elgato Stream Deck (or the budget-friendly Ajazz AKP03E). This gives you physical dials and buttons for the stuff that doesn’t belong on a typing layer.
The Trackpad: The Apple Magic Trackpad remains king. I use Mouseless to reduce dependency, but I refuse to add clunky mouse layers to my keyboard.

The Three-Layer Rule

Most people over-engineer their firmware. I’ve cut out the “magic” (No Macros, No Tap Dance, No Key Overrides) in favor of logic.

Layer 0: Alpha. Standard typing.
Layer 1: Numbers & Navigation. I use the zxcv row for numbers. This leaves 15 keys free for my Tiling Window Manager of choice, AeroSpace .
Layer 2: Symbols. I don’t understand splitting symbols across layers. There are exactly 29 essential symbols—they fit perfectly on one layer. Keep them together so your brain doesn’t have to hunt.

Taming the “Necessary Evils”

Home Row Mods: These can be a headache. I’ve contained the “evil” by only using two keys for mods (Z/X and comma/dot).
Combos: Only one—F+J for CAPS WORD.
Input Methods: Stick to Tap-Hold and Layer Toggle only. Anything else increases the likelihood of misfires.

The Terminal-Centric Stack

If you live in the terminal, your hardware is only as good as your software’s ability to interpret it. My stack focuses on modern protocols and efficiency:

Protocol: Use Kitty Keyboard Protocol (kkp) for better key handling.
Terminal: Ghostty (fast, native, modern).
Multiplexer: Zellij over tmux.
Editor: Doomemacs (Vi bindings forever).

My skhd Configuration

Since I avoid complex firmware overrides, I handle my application-specific shortcuts via skhd . This keeps my keyboard “dumb” and my configuration portable.

# Use xxd -psd to find the hex code and remove 0a

# Navigation: Prev/Next tab in Chrome
cmd - i : skhd -k "shift + cmd - 0x21"
cmd - o : skhd -k "shift + cmd - 0x1E"

# Organization: Move tab left/right in Chrome
shift + cmd - i : skhd -k "shift + ctrl - 0x74"
shift + cmd - o : skhd -k "shift + ctrl - 0x79"

# History: Back and Forward
cmd - 0x2B : skhd -k "cmd - 0x21"
cmd - 0x2F : skhd -k "cmd - 0x1E"

# Terminal Fix: Emacs in terminal doesn't support M-[
# Mapping M-5 as a workaround
alt - 0x21 : skhd -k "alt - 5"

Final Thoughts

Keep it simple. If you can’t explain your layout to yourself in 30 seconds, it’s too complicated. Externalize your macros to a macropad, keep your symbols on one layer, and let your software do the heavy lifting.

Replacing Integrant and Docker Compose with BigConfig System

Tue, 10 Feb 2026 00:00:00 GMT

In the Clojure ecosystem, we’ve grown accustomed to a structural divide. We manage our application architecture with libraries like Integrant and our external dependencies (databases, queues, caches) with Docker Compose or Process Compose .

While effective, this separation creates a constant “context switch.” Your application lives in the REPL, but its foundation is buried in YAML and EDN files. One requires evaluating expressions; the other requires multiple steps to refresh, start, or stop using Emacs or a Shell.

To bridge this gap, I’ve been developing BigConfig System. It is a library inside the BigConfig ecosystem that treats system lifecycles as programmable workflows rather than static dependency graphs.

The “Emacs” Philosophy

I view BigConfig through the lens of the Emacs philosophy: the environment is something you should never have to leave.

As projects scale, we traditionally reach for external orchestrators. However, from the perspective of a running REPL, they have foreign interfaces. By keeping the orchestration logic strictly within Clojure I’ve unified the application and its dependencies. Now, I can manage the entire stack, from environment variables to database migrations, without ever dropping out of my REPL session.

Solving the Postgres Dependency

To test the limits of BigConfig System, I moved away from static Postgres containers in favor of a dynamic, code-driven workflow. I needed to handle multiple profiles (like dev for long-running sessions and test for transient fixtures) simultaneously without port collisions or state pollution.

Instead of a binary “started/stopped” toggle, BigConfig manages a granular execution sequence:

Environment Prep: Dynamically set variables for project-root/.postgres/[profile].
Filesystem Cleanup: Ensure a clean slate by wiping stale data from previous runs.
Initialization: Programmatically execute initdb.
Smart Startup: Launch Postgres via babashka/process, grepping logs for the “ready to accept connections” regex.
Provisioning: Chain-load createuser, createdb, and sql-migrate.
Teardown: A dedicated stop-fn ensures the process tree is destroyed cleanly.

Abandoning the “Refresh” Cycle

Many Clojure developers rely on cider-ns-refresh, but for a refined flow, I find it a bit heavy-handed. My development style centers on evaluating expressions directly within (comment ...) blocks.

By using cider-eval-defun-at-point and cider-inspect-last-result, I gain high-granularity control. The beauty of BigConfig is that the CIDER inspector updates automatically as the system state changes. I can see the system evolve in real-time, directly within my editor, without the jarring reset of a full namespace refresh.

The Workflow in Action

Here is how BigConfig System expresses a managed process as a programmable workflow. Notice how the system lifecycle is defined as a series of step functions (background-process and stop):

(comment
  (let [kill-timeout 150
        shutdown-timeout 100
        clj-timeout 3000]
    ;; Define a managed background process with a specific lifecycle
    ;; Start the process in the background and block the main thread
    ;; until the regex is found or the timeout triggers.
    (defn background-process [opts]
      (let [re-opts (into {} [[:cmd (format "clj -X big-config.system/main :shutdown-timeout %s" shutdown-timeout)]
                              [:regex #"token"]
                              [:timeout clj-timeout]
                              [:key ::proc]])
            opts (re-process re-opts opts)]
        (add-stop-fn opts (fn [{:keys [::proc] :as opts}]
                            (when proc
                              (destroy! proc kill-timeout))))))
    ;; Define the system as a stateful, wired workflow
    (def ->system (->workflow {:first-step ::start
                               :wire-fn (fn [step _]
                                          (case step
                                            ::start [background-process ::end]
                                            ::end [stop]))}))
    ;; sys1 starts and stops the system. It useful during the development of the system itself.
    ;; sys2 starts only. This is useful in all the other cases.
    (into {} [[:sys1 (into (sorted-map) (->system [log-step-fn] {::bc/env :repl}))]
              [:sys2 (let [system (atom (into (sorted-map) (->system [log-step-fn] {::bc/env :repl
                                                                                    ::async true})))]
                       (stop! @system)
                       @system)]])))

(defn main [& {:keys [shutdown-timeout]}]
  (assert shutdown-timeout)
  (.addShutdownHook (Runtime/getRuntime)
                    (Thread. (fn []
                               (println "\n[Shutdown Hook] Cleaning up resources before exit...")
                               (Thread/sleep shutdown-timeout))))
  (println "Script is running... (Press Ctrl+C to stop)")
  (println "token")
  @(promise))

Is it better than Integrant and Docker Compose?

It is still early days, and I am currently refining the library. One major advantage is that there is no longer a split between EDN, YAML, and CLJ files—it’s now just a single CLJ file. The shift in developer experience is already palpable. By replacing the fragmented mix of Docker Compose, Process Compose, and Integrant with a unified Clojure-based workflow, I’ve gained a level of introspection and speed that configuration-based tools and libraries simply cannot provide.

Conclusion

My quest to eliminate configuration files has reached a new milestone with system.edn and compose.yaml. By committing to a “never leave the REPL” philosophy, I’ve replaced traditional CLI tools and libraries with direct evaluation. While abandoning namespace reloading in favor of evaluating only the final expression isn’t for everyone, it has fundamentally transformed my productivity.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

Beyond the Shell: Reimagining DevOps with the Clojure REPL

Mon, 02 Feb 2026 00:00:00 GMT

We are all familiar with the standard REPL experience provided by shells like Bash, Zsh, or Fish. However, far fewer developers have experienced the power of a Clojure REPL. I built BigConfig in Clojure because I believe we should stop relying on fragmented shell environments for operations and development. By moving to a unified Clojure REPL, we can significantly boost productivity.

The Problem: The “Edit/Run” Loop

Let’s look at the standard workflow for a tool like Terraform:

cd into the project root.
Edit the .tf files.
Run terraform plan in the shell.
Repeat until it works.

Now, imagine scaling this across multiple tools. Suddenly, you aren’t just running Terraform; you’re managing ansible, kubectl, and helm. Each tool lives in a different directory. The cognitive cost of switching directories and managing multiple shell sessions becomes a massive bottleneck. You either waste time cd-ing back and forth or you end up with twenty terminal tabs, losing track of which is which.

The BigConfig Alternative: “Edit/Evaluate”

With BigConfig, this friction disappears. Instead of a “shell-per-directory” approach, we use a single, persistent JVM:

Jack-in once: Like a shell, the JVM stays running, but you only need one instance for your entire project.
Unified Workspace: Clojure files and tool-specific configurations (YAML, HCL, etc.) live in the same project.
Instant Feedback: You evaluate Clojure code directly within your editor. No context switching is required.

In the traditional model, “Edit” and “Run” happen in two different programs (the editor and the shell). In BigConfig, “Edit” and “Evaluate” happen in the same program, your editor. Whether you are managing one tool or a hundred, the workflow remains identical.

Workflow: A New Type of Flow Control

To make this possible, BigConfig introduces a specialized flow control: the workflow.

While if is the classic example of flow control in code, a BigConfig workflow operates on a workbench map. You define a series of steps (specialized functions) that execute sequentially, reading from and writing to this shared map.

For example, the workbench map might contain a sequence like ["terraform init", "terraform plan"]. A specific step reads those commands and executes them in a directory defined elsewhere in the map. Even if you prefer writing HCL or YAML manually rather than generating it, BigConfig’s workflow engine automates the orchestration, so you don’t have to.

Real-World Application: Developing Terraform Providers

I use BigConfig for both operations and core development. Currently, I’m building a Terraform Provider in Clojure . Because the gRPC protocol documentation can be sparse, I built a BigConfig workflow to log and analyze traffic.

I use two primary workflows for this:

The hcloud workflow: This starts the Hetzner Terraform Provider in dev mode, launches a gRPC “man-in-the-middle” to log traffic, renders a test main.tf, executes Terraform, and transforms the resulting gRPC Java classes into readable Clojure maps.
The dev workflow: This is identical to the first, but it swaps the Hetzner provider for my own Clojure-based provider in development.

(def hcloud-wf (->workflow {:first-step ::start
                            :wire-fn (fn [step step-fns]
                                       (case step
                                         ::start [start-hcloud ::start-proxy]
                                         ::start-proxy [start-proxy ::prepare]
                                         ::prepare [prepare ::render]
                                         ::render [render/render ::exec]
                                         ::exec [(partial run/run-cmds step-fns) ::fix-messages]
                                         ::fix-messages [fix-messages ::end]
                                         ::end [stop]))}))

(comment
  (into (sorted-map) (hcloud-wf {::bc/env :repl
                                 ::test-name "hcloud"})))

(def dev-wf (->workflow {:first-step ::start
                         :wire-fn (fn [step step-fns]
                                    (case step
                                      ::start [start ::start-proxy]
                                      ::start-proxy [start-proxy ::prepare]
                                      ::prepare [prepare ::render]
                                      ::render [render/render ::exec]
                                      ::exec [(partial run/run-cmds step-fns) ::fix-messages]
                                      ::fix-messages [fix-messages ::end]
                                      ::end [stop]))}))
(comment
  (into (sorted-map) (dev-wf {::bc/env :repl
                              ::test-name "first"})))

Goodbye, Debuggers

I don’t need a traditional debugger for this. Because these workflows are just pure functions that transform a map, I can “attach” any value I want to inspect to the workbench map at any step.

Thanks to Clojure’s qualified keywords, I never have to worry about naming conflicts between different steps. I can see the entire state of my infrastructure and my code in one place, instantly.

Conclusion

Traditional DevOps workflows are often bogged down by the “Edit/Run” loop, requiring developers to constantly switch between editors, directories, and terminal tabs. BigConfig solves this by leveraging a persistent Clojure REPL to create a unified “Edit/Evaluate” environment. By orchestrating tools like Terraform through a centralized “workbench map,” BigConfig eliminates context switching and replaces traditional debugging with instant, stateful feedback. It transforms fragmented operations into a seamless, code-driven flow where infrastructure and development live in a single, interactive workspace.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

Update

I received an interesting question and wanted to share my response here.

Question

The REPL often suffers from reproducibility issues due to out-of-order execution. Does BigConfig address this in some way?

Answer

This is addressed both by Clojure itself and within BigConfig’s architecture.

Clojure provides the foundation because out-of-order execution would be detrimental to any serious development. By using Clojure for operations—rather than Python or Node—we can leverage the same robust patterns used in traditional Clojure REPL-driven development.

BigConfig specifically solves this by introducing a new control flow: the workflow. A workflow is a function that invokes other functions, called steps, similar to AWS Step Functions (which served as an inspiration for BigConfig). If you are modifying a specific step, such as prepare, you would edit it like this:

(comment
  (do
    (defn prepare [opts]
      ; you are developing the code of this step
      )
    (into (sorted-map) (hcloud-wf {::bc/env :repl
                                   ::test-name "hcloud"}))))

In my editor, I simply press C-c C-c to evaluate everything in the correct order. I can then inspect the workbench map in one window and the stdout in another, ensuring a predictable and reproducible state every time.

Hypermedia: The New/Old Architecture Set to Revolutionize Web and Mobile Development

Tue, 18 Nov 2025 00:00:00 GMT

Hypermedia is the tech everyone is talking about, yet it remains a bit of a mystery for many. After diving deep, I’m convinced this new/old approach is not just a trend—it’s poised to disrupt how we build applications on both the web and mobile.

Here are my thoughts, inspired by the powerful concepts driving this shift.

What is a Hypermedia Driven Application (HDA)?

The Hypermedia Driven Application (HDA) architecture—championed by projects like htmx —is an ingenious fusion of old and new.

It takes the simplicity and flexibility of traditional Multi-Page Applications (MPAs) and marries it with the smooth user experience (UX) typically found only in complex Single-Page Applications (SPAs).

After struggling to grasp this concept myself, I decided the best way to understand it was to build one. That journey led me to the fascinating world of Hyperlith and Datastar . The ideas behind Hyperlith are truly revolutionary. Hyperlith stands for Hypermedia and Monolith.

The Philosophy: Dumb Terminals, Smart Backend

In the HDA model, your application’s logic, state, and rendering all reside in the backend.

Your distributed application runs entirely on the server.
The browser or mobile app becomes a dumb terminal.

Pages are conceptually replaced by views (for both web and mobile). When a user interacts with a control (like a button), it triggers an action on the server. This action recalculates the current view, which is then pushed to all relevant users.

Think about a traditional leaderboard implemented as a web page: instead of polling or building complex real-time infrastructure, the view automatically updates for all online users as soon as the data changes on the server. The multiplayer capabilities are practically trivial!

The Disruption: Why HDAs Win

This server-side approach has several game-changing implications for development:

Unified Codebase for Web and Mobile

With frameworks like Hyperlith and Datastar, you can achieve amazing results without starting from scratch. Instead of managing separate SPAs or native mobile apps, you manage a single backend that renders views suitable for any client.

Lightning-Fast Mobile Development

Mistake a typo in your app? Need to tweak a UI element? In the HDA model, you simply fix the code on the server. You don’t have to upload a new mobile app version and wait for store approval. The changes are live instantly for all users.

Effortless A/B Testing

Since all rendering happens on the server, implementing server-side A/B testing becomes incredibly simple. You can easily serve different versions of a view to different user segments without complicated client-side routing or code splitting.

Simplified Shared & User-Specific Views

The HDA architecture makes it easier to create views that are shared among users (like a stock ticker) and then progressively make portions user-specific (like a profile widget).

It’s easier to start with a shared view and then make it specific than to start with isolated pages and struggle to add shared portions later.

Efficient Updates and Network Performance

Many people worry that sending the complete HTML on every change won’t scale, especially on mobile networks. This concern is often misplaced.

Instead of thinking of it as constant full-page refreshes, imagine it as a stream of bytes, highly compressed with algorithms like Brotli.

The compression acts as your caching and diffing mechanism, achieving compression ratios of 100 or more! This efficiency is critical: a $1.5 MB/s sustained throughput on the server is equivalent to handling $150 MB/s without compression, drastically reducing infrastructure costs.

Seamless User Experience with DOM Morphing

Modern apps like YouTube and Spotify offer that polished mini-player experience, letting you keep watching content while navigating to a new page. This amazing user experience is a natural fit for HDAs, thanks to a technique called DOM morphing.

Instead of completely swapping out the entire page (like in a traditional MPA) or relying on complex client-side routing (like in an SPA), the HDA backend sends the new rendered view. The client then intelligently morphs the existing DOM to match the new version. This means that persistent elements—like an ongoing video player or music widget—can retain their place, focus, and internal state, resulting in a smooth, interruption-free user flow.

BigConfig and Internal Developer portals

The strategic shift towards Hypermedia Driven Applications (HDA) fundamentally alters the economics of development, making internal solutions significantly more viable. As the cost of building web and mobile experiences drops, so too does the traditional calculus of “build vs. buy.”

To capitalize on this change, our next major step is integrating Internal Developer Portal capabilities directly into BigConfig. This addition completes BigConfig’s transformation into the essential, comprehensive library for scalable operations, providing core building blocks like configuration as code, workflow orchestration, scaffolding, robust persistency, auditing, control planes, and now, internal developer portals.

I’m working on the code right now. Stay tuned, I will update the blog post as soon as I have the first version.

See it in Action

I built a simple HDA example to prove the concept. When you open it in two separate browser tabs and interact with one, the other updates instantly.

The most incredible part? Zero JavaScript was required to implement the real-time, multiplayer capabilities. The state is managed centrally and seamlessly on the server.

The future of application development is here, and it looks a lot like the past—just smarter, faster, and much more scalable.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.

BigConfig | Blog

Terraform Workspaces Are Not Environments — BigConfig Makes It a Non-Issue

Why the debate keeps happening

What BigConfig does differently

The deeper point

Why Agents Need an Infrastructure Package Manager

The Gap Between Intent and Execution

BigConfig as the npm for Infrastructure

Why Clojure?

Reusability Without Rigidity

The Ecosystem Is Already Growing

What This Means for Practitioners

Do you trust your DevOps code as much as you trust Postgres?

The problem: the “bespoke platform” trap

A real-world lesson: the “latest” trap

The takeaway

The Future of Software Distribution: How LLMs are Challenging the SaaS Dominance

The Snowflake Example and the Return to Licensing

The Role of the Platform Team and AI Agents

The Open-Source Illusion and the Shift in Monetization

A Return to Proprietary, Licensed Software?

Where BigConfig Fits

Your GitHub Actions Workflow is a Waste of Time

My Modern Development Environment

Achieving CI Parity with Self-Hosted Runners

How to set it up:

Quantifying the Impact on Feedback Loops

The Power of Declarative Environments

Final Thoughts: Simplify Your Workflow

AI Speaks Terraform Like a Tourist

The “Pre-React” Era of DevOps

Why the “Tourist” Becomes a “Superhuman”

Conclusion

DevOps Without the Code: Infrastructure as Markdown

From Idea to Infrastructure in 3 Minutes

Why It Works: Data Over Code

BigConfig as the “React of DevOps”

The milestones

1. The Human Draft (user-plan.md)

2. The AI-Refined Plan (final-plan.md)

3. The Result: bb.edn

Final Thoughts

BigConfig: The "React" for Agentic DevOps

The Vision: Agentic + Data-Driven DevOps

The root directory

The Workflow: Zero-Touch Deployment

1. The Web Server (Caddyfile)

2. The Container (Dockerfile)

3. The Pipeline (GitHub Action)

Summary

The Evolution of DevOps: From Separation by Technology to Separation by Concerns

The Modern DevOps Bottleneck

Enter BigConfig: The Component-Based Approach

The Coupling Problem: A Practical Example

Modularity and Referential Transparency

Conclusion

Vibe Coding Meets Vibe Ops: Automating the Last Mile of Deployment

Zero-Friction Infrastructure

1. Compute

2. DNS

3. SMTP

The Vision: Dev & Ops in Plain English

Current Manual Hurdles

Conclusion

The Power of Framing: Why BigConfig is Rebranding as a Package Manager

The Language Barrier (and the Loophole)

The “Package Manager” Epiphany

How BigConfig Differs

Limitless Abstraction

The Roadmap

Conclusion

Simple over easy for operations

Wiring the Engine

Workflow Example

Debugging Made Simple

Solving the Composability Problem: Nested Options

The Working Directory and the Maven Diamond Problem

Conclusion: Simple over Easy

Composability: Orchestrating Infrastructure with Babashka and BigConfig Package

Getting Started

1. The Human Draft (`user-plan.md`)

2. The AI-Refined Plan (`final-plan.md`)

3. The Result: `bb.edn`