Code-Infrastructure-as-Code (CIaC): one source file, five targets, full simulation, no (required) infrastructure

[jrcalgo]

Most backend generators are optimized for getting you from zero to a working project. You generate the initial code, take ownership of it, and over time the generated structure and your application code can diverge enough that regenerating becomes difficult or undesirable.

CIaC takes a different bet. You write one .ciac file describing your system and keep that file as the architectural source of truth. CIaC is structured around services, APIs, records, event streams, workers, pipelines, and their infrastructure dependencies. The compiler owns the generated wiring, while your business logic lives in generated stubs that remain yours to edit and are preserved across builds.

One spec, five idiomatic targets

The same .ciac file compiles to functioning code in five languages, each idiomatic to its own ecosystem, byte-identical on every rebuild:

CIaC concept	Python	Rust	TypeScript	Go	Java
API	FastAPI router	Axum router	Fastify plugin	net/http ServeMux	Spring MVC @RestController
Database	SQLAlchemy async	SQLx pool	Drizzle	database/sql pool	Spring JdbcClient
Queue	nats-py / aiokafka	async-nats / rdkafka	nats transport / kafkajs	nats.go / franz-go	jnats / spring-kafka

Here's examples/multi-service-media.ciac from the repo: a real five-service system, not a toy: an upload API that charges through a Billing service via a typed cross-service call, a Transcoder worker that consumes the resulting event and republishes success or failure, a Notifier that emails on success and archives on failure, and a ProgressFeed service pushing live updates over WebSocket:

service UploadApi {
    use { queue bus NATS; }
    api Upload: Video { method: PUT; path: "/videos"; }
    pipeline Upload:
        call Billing.Charge
        -> StoreVideo
        -> publish Uploaded
        -> Return;
}

service Transcoder {
    use { queue bus NATS; object_store media S3 { bucket: "videos"; } }
    worker Transcode on Uploaded;
    pipeline Transcode:
        TranscodeVideo
        -> match status {
            Ready -> publish Transcoded;
            Failed -> publish DeadLetters;
        };
}

That one file compiles to functioning code in five languages, each idiomatic to its own ecosystem, byte-identical on every rebuild:

ciac build examples/multi-service-media.ciac --target python --out ./build
ciac build examples/multi-service-media.ciac --target go --out ./build-go

Pick a target with a flag, nothing else changes.

Test the whole system before a container exists

The most exciting part: CIaC ships with a deterministic simulator that runs your generated code against in-memory fakes for the database(s), queue(s), object store(s), and email(s). No Docker, no infra in CI.

Here it is exercising the full upload -> charge -> transcode -> notify flow across all five services at once:

ciac sim examples/multi-service-media.ciac --target python --out ./build \
    --scenario sim/multi-service-media.ciac-sim.json
# [PASS] 28-m3-upload-charges-transcodes-notifies

When you're ready for the real thing, ciac verify builds and boots the actual generated project, and ciac build --deploy k8s (or terraform, or ci) emits real deployment artifacts.

Who is this (not) for?

CIaC fits best in systems that are naturally a typed graph of services, APIs, pipelines, and streams, just as the media example above displays.

It's a poor fit if your architecture doesn't map onto this ontology, or if you're working with existing handwritten services rather than starting fresh; CIaC assumes greenfield development.

Try it

cargo install --path crates/ciac
ciac new demo && cd demo && ciac check main.ciac

Full walkthrough and language reference in the README and docs/.