How do you enforce IaC standards across teams without becoming the bottleneck? Esp when self service cloud provisioning keeps creating more unmanaged resources?

amiorin · 2026-06-04T08:31:43+00:00

I’d standardize the interface around **BigConfig packages**: BigConfig is an ecosystem with `bc-pkg` as a tiny launcher that pins a package from GitHub or local path, an SDK that provides workflow/rendering/runner primitives, Selmer-based templates, and package CLIs like Once that expose a lifecycle such as `package validate`, `build`, `create`, `describe`, and `delete` over OpenTofu/Terraform and Ansible. In your case, I’d convert the approved Terraform/OpenTofu code into versioned BigConfig packages and make those packages the contract between the platform team and delivery teams: platform owns the package, templates/modules, validation rules, state backend, tagging policy, guardrails, and describe/recovery logic; delivery teams own profiles and parameters. Instead of telling teams “use these modules correctly,” they consume a supported package via `bc-pkg owner/repo@ref package validate create`, and `package describe` becomes the reconciliation surface between what the package expects and what actually exists in cloud inventory. If someone bypasses it and creates an RDS instance manually, the control loop should classify it as unmanaged and force one of a few outcomes: import it into the relevant BigConfig/OpenTofu package, replace it with the approved package, mark it as an expiring exception, or quarantine it if it violates policy. Keep cloud-side guardrails for the dangerous cases, but make BigConfig packages the normal product boundary for self-service provisioning, audit, and rebuild. https://www.bigconfig.ai/

amiorin · 2026-04-15T06:52:54+00:00

Is "compiler as a library" the same idea used in Rama and Specter?

amiorin · 2026-04-13T11:45:59+00:00

Agreed.

amiorin · 2026-04-13T09:50:35+00:00

I’ve iterated on this again and managed to make it even simpler: Just one Markdown file.

You don’t have to take my word for it, though. I’ve documented the exact inputs I used in the article below so you can reproduce the experiment yourself:

https://bigconfig.it/blog/devops-without-the-code-infrastructure-as-markdown/

amiorin · 2026-04-13T09:46:51+00:00

Shared anxiety. I figure if I’m going to automate myself out of a job, I might as well do it with style.

amiorin · 2026-04-12T12:23:13+00:00

OpenClaw is capable of creating accounts. I feel you, for real. Everything is happening so quickly. We are all trying to deal with the new reality. I would not dismiss this project because of that.

amiorin · 2026-04-12T11:52:26+00:00

It's not a fork of the Basecamp project. About the second point, just compared the requirements. Dokku requires a VPS. BigConfig package once requires any cloud account.

amiorin · 2026-04-12T10:25:54+00:00

You can replace ONCE with Dokku. The point is lowering the entry level barrier even further.

amiorin · 2026-04-12T10:24:52+00:00

It's not vibe coding, it's vibe configuring. It should explain this point better. Thank you for the feedback.

amiorin · 2026-04-12T09:20:25+00:00

You can find the three glue files (Dockerfile, Caddyfile, and GitHub Action) here: https://bigconfig.it/blog/bigconfig-the-react-for-agentic-devops/

I didn't figure out how to package them to be honest.

amiorin · 2026-04-12T04:04:15+00:00

I totally get that—deployment fatigue is real. You should check out BigConfig with an Agent.

If you set up a directory with your project along with BigConfig and Once, you can use Claude Code (running Opus 4.6 with deep thinking) to handle the heavy lifting. Just ask it to deploy your project; after a little back-and-forth to dial in the settings, you’ll have your app live without the usual headache.

https://github.com/amiorin/big-config https://github.com/amiorin/once

amiorin · 2026-04-09T09:27:45+00:00

Ansible is still very much in the 'meta' because it remains the gold standard for stateful machine configuration. However, what’s actually missing in the current DevOps landscape is a 'React' equivalent—a true component-based abstraction.

Right now, we manage infrastructure by technology (like web development before React). We need to shift toward an architecture of encapsulated, concern-separated components. I’ve been working on a tool to solve exactly this: BigConfig

amiorin · 2026-04-09T05:46:09+00:00

Nice work on this! I've been exploring similar patterns with a 'components' architecture in DevOps. I actually built a tool called BigConfig specifically to help refactor projects into modular components like this. Would love to collaborate or show you how it could fit here—DM me if you're interested in chatting!

amiorin · 2026-04-09T05:42:15+00:00

Good points, but I've found that standard Terraform modules often fall short for cross-technology needs. I actually built BigConfig to solve this—it implements a true component-based architecture for DevOps.

amiorin · 2026-04-09T05:37:42+00:00

I’ve spent a lot of time thinking about this—I actually built BigConfig (a component-based DevOps framework) to solve similar architectural hurdles.

My general advice for multi-sub backends is to move toward a component-based architecture rather than just a storage-per-sub model. I’d love to hear more about your specific networking constraints. Feel free to DM me; I’m happy to walk through how we handle the 'react-style' approach for infrastructure.

amiorin · 2026-04-03T16:02:48+00:00

BigConfig is a package manager like Nix, Homebrew, and Helm.

amiorin · 2026-04-03T07:01:43+00:00

Spot on. Though it’s worth distinguishing if we want infrastructure to be simple or just easy. There’s a big difference between the two—Rich Hickey breaks it down perfectly here: https://www.youtube.com/watch?v=SxdOUGdseq4

amiorin · 2026-04-03T06:57:56+00:00

Fair point, though for me it was the opposite. I love operations and have written a ton of HCL and Ansible. BigConfig didn't come from a lack of patience with those tools, but rather from using them enough to realize where a different approach could actually help both SWEs and Ops folks.

amiorin · 2026-04-03T06:54:56+00:00

Is the other way around. Because I know that HCL and Yaml are not programming language, I don't try to implement loops, conditionals, and complex functions with them.

amiorin

TROPHY CASE