{ Safety layer for agentic infrastructure }

AI agents can write infrastructure. Teams still cannot trust them to change it.

Developers are getting comfortable letting agents change application code, but infrastructure is different: the blast radius is higher, feedback loops are slower, and a bad change can break production. InfraFactory gives teams a safe validation loop before agentic infrastructure changes touch real cloud accounts.

View on GitHub Get started

infrafactory

$ make build
$ make mocks-up
$ ./bin/infrafactory run scenarios/training/gcp-full-stack.yaml

scenario       gcp-full-stack
cloud          gcp
generation     plan -> hcl -> self-review
validation     static -> fakegcp -> destroy

Status: success
terminal_reason: target_reached

Safe local validation before real cloud changes

Fast agent repair loop for infrastructure failures

Proof state, policy, topology, and destroy evidence

Control optional promotion to real cloud accounts

Why now

Infrastructure is becoming the trust bottleneck for AI software development.

Coding agents are moving from suggestion to execution. That works when tests are fast, rollback is simple, and failures are contained. Infrastructure changes are different: they touch networks, identity, databases, cost, compliance, and production availability.

The current gap

Agents can generate plausible infrastructure code
Developers still have to manually judge whether it is safe
Real cloud feedback is slow, expensive, and risky
Plan output misses failures that only appear after apply
Infrastructure lessons are scattered across incidents and senior engineers

The InfraFactory wedge

Give agents a safe place to attempt infrastructure changes
Validate generated Terraform/OpenTofu against realistic cloud behaviour
Inspect the resulting state, not just the generated code
Feed failures back into the next agent attempt
Build a growing control plane for safe agentic infrastructure work

How it works

A safety loop for AI-generated infrastructure.

InfraFactory lets an agent propose infrastructure, run it through controlled execution, inspect what actually happened, and repair failures before the change reaches production.

Intent contract

Describe the infrastructure outcome and the evidence required to prove it worked.

Terraform/OpenTofu output

The agent plans architecture, writes HCL, and self-reviews before execution.

Safe execution

Run changes against realistic local cloud environments before real accounts.

Evidence gates

Check planned state, applied state, connectivity, policy, and teardown behaviour.

Topology checks

Ask operational questions like whether compute can reach databases on the right ports.

Agent repair loop

Failures become machine-readable context for the next attempt instead of vague logs.

Controlled promotion

Run the same workflow against real cloud APIs only when explicitly enabled.

Destroy verification

Prove cleanup by destroying resources and checking for costly or risky orphans.

Scenario contract

Intent goes in. Provider-specific HCL comes out.

The scenario is not a replacement for Terraform. It is the contract the agent works against: resources describe intent, acceptance criteria describe evidence, and the validation loop decides whether the generated infrastructure is good enough.

scenario: full-stack-paris
cloud: scaleway

resources:
  compute:    { purpose: web-server, size: small }
  networking: { vpc: true, private_network: true }
  database:   { engine: postgresql, size: small }
  redis:      { purpose: cache, size: small }

acceptance_criteria:
  - type: policy
    check: encryption_at_rest
    expect: pass
  - type: destruction
    expect: no_orphans

Validation

More than `terraform validate` or `tofu validate`.

Static

`terraform`/`tofu init`, `validate`, `plan`, provider schema checks, and OPA rules over plan JSON.

Mock deploy

Apply against a deterministic cloud twin and inspect the resulting state.

Real deploy

Optional sandbox apply against real AWS, GCP, or Scaleway APIs with probes.

Destroy

Run destroy, check for orphans, and keep the run artefacts as evidence.

Demo

CLI and UI use the same loop.

Get started

Run a full-stack scenario locally.

Clone

InfraFactory expects sibling mock repositories for local cloud validation.

git clone https://github.com/redscaresu/infrafactory.git

Build and start mocks

Start mockway, fakegcp, and fakeaws on local ports.

make build && make mocks-up

Run a scenario

No cloud credentials are required for Layer 2 mock validation.

./bin/infrafactory run scenarios/training/gcp-full-stack.yaml

Why this exists

From manual review to controlled execution.

Without InfraFactory

Agents generate infrastructure that looks plausible
Engineers manually inspect diffs and hope they caught the risk
Meaningful feedback requires slow real-cloud attempts
Teams avoid agentic infrastructure because the failure cost is too high
Cloud-specific pitfalls stay trapped in senior engineers' heads

With InfraFactory

Agents get a controlled environment to attempt infrastructure changes
Generated Terraform/OpenTofu is applied before it is trusted
Failures become precise feedback for the next agent iteration
Policy and topology are checked against actual resulting state
Repeated lessons become reusable infrastructure knowledge

FAQ

Frequently asked questions.

Is InfraFactory a Terraform replacement?

No. InfraFactory generates Terraform/OpenTofu-compatible HCL, executes it, validates it, and stores the evidence.

Does it require cloud credentials?

No for local mock validation. Real cloud deployment is optional and explicitly gated.

Which clouds are supported?

InfraFactory currently targets AWS, GCP, and Scaleway through fakeaws, fakegcp, and mockway.

What problem does this solve for AI agents?

It addresses the trust gap. Agents can generate infrastructure, but teams need a safe way to execute, inspect, repair, and prove those changes before they touch production.

Let agents work on infrastructure without gambling on production.

Open source, validation-first, and designed for teams building agentic engineering workflows.

View on GitHub