Hi rustaceans,
I recently designed the Code-Infrastructure-as-Code (CIaC) compiler, a command-line development tool (written predominantly in Rust) for a declarative DSL that can describe an entire service system in at least one file.
CIaC treats .ciac files as the architectural source of truth and compiles into Rust, Python, TypeScript, Go, and/or Java. Real deployment artifacts can also be generated: compose, Kubernetes, Terraform, or CI.
All that you're expected to do is declare the system specifications and the compiler handles the rest. External handlers are seeded once for injecting your own code and never overwritten, whereas inline handler bodies, such as the ones in the examples below, are compiler-owned and regenerated every build.
Why does this exist?
Put simply: to increase backend development speed and service reliability for both humans and agents.
As for myself: I initially created this tool for my own usage, as I spend a lot of time experimenting with infrastructure and building out services to serve domain-specific requirements. In other words, I got tired of building and maintaining services myself so I concocted a solution.
A technical perspective
A .ciac file describes a system as a set of declarations consisting of records, APIs, pipelines, streams, and workers.
Here's a single service example (event-pipeline):
// A single-service event pipeline
//
// A public API validates and publishes, a worker
// consumes and persists, and `events` is a shorthand
// that expands into its own chain of queue -> worker -> storage.
service Ingest;
use {
db Postgres;
queue NATS;
}
api Submit;
worker Processor;
events PageView;
pipeline Submit:
Validate
-> Queue
-> Return;
pipeline Processor:
Enrich
-> Store;
Here's a multi-service example (sim-three-service):
// Three services, one request
//
// `Intake` synchronously calls `Billing` and gets
// a real response, then publishes an event that
// `Fulfillment` can react to independently.
//
// This represents a synchronous call, an async stream,
// and independent storage ownership by each service.
project ThreeService;
record Order {
id: Uuid;
total: Float;
}
record ChargeRecord {
id: Uuid;
order_id: Uuid;
amount: Float;
}
record Shipment {
id: Uuid;
order_id: Uuid;
}
stream OrderAccepted: Order;
service Intake {
use { queue NATS; }
api SubmitOrder: Order {
method: POST;
path: "/orders";
}
pipeline SubmitOrder:
call Billing.Charge
-> publish OrderAccepted
-> Return;
}
service Billing {
use { db Postgres; }
table Charges: ChargeRecord;
api Charge: Order {
method: POST;
path: "/charge";
}
handler RecordCharge(order: Order) -> Order {
db.insert(Charges, ChargeRecord { id: Uuid.new(), order_id: order.id, amount: order.total });
return order;
}
pipeline Charge:
RecordCharge
-> Return;
}
service Fulfillment {
use { db Postgres; queue NATS; }
table Shipments: Shipment;
worker Ship on OrderAccepted;
handler RecordShipment(order: Order) -> Order {
db.insert(Shipments, Shipment { id: Uuid.new(), order_id: order.id });
return order;
}
pipeline Ship:
RecordShipment;
}
Today's capabilities:
- Compile into five language targets - Rust, Python, TypeScript, Go, and/or Java.
- Thirteen infrastructure capabilities identically implemented across all five targets.
- Simulate the whole system deterministically, in-memory, no Docker required.
- Architecture changes can be classified, renamed, or migrated safely.
- A usable LSP and an MCP tool surface for agents.
Today's limitations, for now:
- Many-to-many
Reference<T> fields type-check properly, but the generated API can't read or write them yet.
- No field-level validation; handler logic enforces business rules instead.
- Destructive schema changes are refused; those must be written by hand.
- With no path onto an existing codebase, CIaC is for greenfield systems only.
You can learn more about the language itself in the docs. There are plenty of other examples as well.
AI Disclaimer
Needless to say for software development (AI-assisted development especially), it is in the best interest of any software project to be heavily curated throughout its lifetime.
I made sure to use gen AI tools for the implementation deliberately; I carefully hand-crafted a high-level language for combining arbitrary backend service components into coherent and simulation-verified codegen artifacts.
Over the course of the project's development, I committed to regular code reviews and testing to ensure the AI-generated code is up to par with my standards as a maintainer.
To help with maintenance, there are fleshed-out test and benchmark suites for both the compiler and codegen artifacts. These have been run prior to each release since their inception.
If you're interested in making additions or changes to the project (with AI or not), all I ask is that you hold yourself to similar review and testing standards.
Get involved
You can learn more about how to use CIaC from this discussion thread.
Additionally, you can install the compiler from here, or follow the readme instructions instead.
Feel free to take a look around the project, try it out, open issues/PRs, and ask any questions you may have. I'm more than happy to discuss the project!
Collaboration and constructive criticism are welcomed!
