aiac: turning plain-English prompts into Terraform, Pulumi and CI/CD files

What aiac generates and who it is aimed at

aiac is a library and command line tool to generate IaC templates, configurations, utilities, queries and more via LLM providers such as OpenAI, Amazon Bedrock and Ollama. The README frames the core loop plainly: the CLI allows you to ask a model to generate templates for different scenarios (e.g. "get terraform for AWS EC2"), composes an appropriate request to the selected provider, and stores the resulting code to a file and/or prints it to standard output.

The intended user is an engineer who already knows the target format and wants to skip the boilerplate. The example prompts in the README span six categories: IaC (terraform, pulumi golang, cloudformation), configuration files (dockerfile, k8s manifest), CI/CD pipelines (jenkins pipeline, github action), policy as code (opa policy), utilities (python, bash) and command builders (kubectl, awscli, mongo, elastic, sql). That breadth is the point. A team that writes Terraform on Monday and a Mongo aggregation on Tuesday uses one tool for both.

What aiac is not is a validator. Nothing in the README suggests the generated output is checked against a provider schema before it is written. The tool's job ends when the model's response is stored. Everything after that is yours.

How the backend, model and request path fit together

The architecture is a thin routing layer over provider SDKs. The go.mod file lists the aws-sdk-go-v2 bedrock and bedrockruntime clients, a generic HTTP request library (ido50/requests), BurntSushi/toml for configuration parsing, adrg/xdg for locating the config directory and alecthomas/kong for CLI parsing. There is no local model, no cache and no intermediate representation of the generated code. The prompt goes out, the text comes back, and it lands in a file or on stdout.

Configuration is a list of named backends. Each backend has a type identifying the LLM provider ("openai", "bedrock" or "ollama"), plus provider-specific settings. The README notes that multiple backends of the same provider can be configured, for example for staging and production environments. That is the design decision worth noticing: environment selection is a config concern, not a flag on every invocation. You pick a backend once and the same prompt behaves differently depending on which credentials and region it resolves to.

The README is explicit about one failure mode. Every backend can have a default model via the configuration key default_model, and if it is not provided, calls that do not define a model will fail. There is no silent fallback to a provider default. For OpenAI-compatible endpoints, the openai backend also accepts url, api_version, auth_header (defaulting to Authorization) and extra_headers, which is how Azure OpenAI is wired in. Ollama needs only a URL including the /api path prefix, defaulting to http://localhost:11434/api.

Installing aiac and generating your first Terraform file

Four install paths are documented. Homebrew, Docker, go install and a source build. The go install route pins the v5 module path:

go install github.com/gofireflyio/aiac/v5@latest

After that, aiac is on your PATH. The Docker image is published to GHCR and the Dockerfile shows the entrypoint is the aiac binary itself, with ca-certificates and git added to an Alpine base, so the container expects arguments to be passed straight through.

docker pull ghcr.io/gofireflyio/aiac

Before the first prompt you need a config file. Unless a specific path is provided, aiac looks for ${XDG_CONFIG_HOME}/aiac/aiac.toml, which on Unix-like systems defaults to ~/.config/aiac/aiac.toml. The --config or -c flag overrides that. A minimal single-backend file looks like this:

default_backend = "official_openai"

[backends.official_openai]
type = "openai"
api_key = "$OPENAI_API_KEY"
default_model = "gpt-4o"

The README shows both a literal API key and the $OPENAI_API_KEY form, so environment expansion is supported. Note that default_backend is what makes a bare aiac call work; without it you have to name the backend.

Now the actual use. The README's own example is the shortest path to a result:

aiac terraform for a highly available eks

The response is written to a file and/or printed to standard output. Read it before you apply it. The README also documents listing models, which is the command to reach for when a call fails because the model name is not available to your account.

Where aiac stops being the right tool

The clearest limitation is stated in the README rather than discovered in production: Ollama does not provide an authentication mechanism, but one may be in place in case of a proxy server being used, and this scenario is not currently supported by aiac. If your only reachable model endpoint sits behind an authenticating proxy, the ollama backend is not a workaround. You either run Ollama directly or use a different provider.

The second limitation is the default_model requirement. A backend without it fails any call that does not name a model. In a shared config checked into a repository, that turns a missing line into a runtime error for everyone who uses that backend, not just the person who added it.

The third is scope. aiac composes a request and stores text. It does not diff against existing infrastructure, does not know your module registry, and does not check whether the generated Terraform references a provider version your project pins. For a greenfield example file that is fine. For a change to a production module with remote state and a locked provider set, the generated draft is a starting point that a human still has to reconcile line by line. If your team's bottleneck is review capacity rather than first-draft typing speed, aiac moves the work around instead of removing it.

How aiac differs from Terraform's own module registry and from Copilot-style editors

The nearest alternative for the IaC half of the problem is the Terraform Registry and the module ecosystem around it. A registry module is a reviewed, versioned, parameterised artifact: you call it with inputs and you get a known graph. aiac produces a flat, one-off file from a sentence. The difference is reproducibility. Two runs of the same prompt can return different code, and nothing in the repository indicates the output is cached or hashed. If you need the same result twice, a module wins outright.

The other comparison is an editor-integrated assistant. Those tools see the file you are editing and suggest inline. aiac runs in the terminal, has no knowledge of your repository, and emits a whole file rather than a completion. That is a real advantage for the command-builder use cases in the README, such as aiac kubectl that gets ExternalIPs of all nodes, where there is no file to edit and you just want the invocation. It is a disadvantage when the correct answer depends on conventions already established in your codebase, because aiac cannot read them.

For teams already on Bedrock, the practical difference from a generic OpenAI-backed tool is the backend abstraction. The same CLI reaches aws_profile and aws_region through the AWS SDK, so credentials come from the standard chain rather than a separate key file.

Upgrades, the v4 to v5 break, and what the Apache-2.0 licence means here

The README devotes a section to upgrading from v4 to v5 and lists four areas of change: configuration, CLI invocation, model usage and support, and other changes. That tells you the v5 release was not a drop-in. If you are on v4, read that section before bumping, because the config file format and the invocation are both in scope. The most recent tagged release listed in the repository is v5.3.0, dated 2024-10-29; the last push to the default branch was on 2026-03-24. Releases and commits have moved at different rates, so do not assume a new tag accompanies every change on main.

The dependency surface is moderate and mostly first-party Go tooling: the AWS SDK v2 modules, a TOML parser, the XDG directory helper, kong, clipboard, a spinner and a colour library. There is no plugin system and no runtime dependency on a database or daemon. Upgrading aiac means replacing a binary or re-running go install; the cost sits almost entirely in the config file and in re-reading generated output, not in migration scripts.

aiac is licensed under Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices, but I am not giving legal advice and your organisation's policy on Apache-2.0 dependencies is the thing that decides whether you can ship it. One detail worth flagging for anyone redistributing it: the Dockerfile copies a prebuilt aiac binary into an Alpine image, so if you build your own image on top, you are redistributing the compiled program and the licence notice obligations attach to that.

Editorial conclusion

Adopt aiac if you already have an OpenAI key, a Bedrock-enabled AWS account or a local Ollama server, and you want a first draft of a Terraform module, a Dockerfile or a kubectl command without leaving the terminal. Skip it if your workflow requires deterministic output or a provider with authentication in front of it, because the README states that Ollama behind a proxy is not currently supported and that a backend without a default_model fails any call that does not name a model. Before rolling it out, verify three things: that your TOML backends resolve their api_key values, that the model you set as default_model is actually enabled for your account, and that the generated file passes terraform validate or your linter before anyone applies it.

Frequently asked questions

Official sources

1. gofireflyio/aiac on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases