Clanker CLI: an agent swarm for cloud inventory and deploys

The gap Clanker fills between provider CLIs and a chat window

Cloud work is split between two awkward modes. You either type provider CLI commands from memory, or you paste console output into a chat window and hope the model understands the account context. Clanker takes a third route: it keeps the provider CLIs as the execution layer and puts an agent in front of them. The README describes it as an agent swarm powering Clanker Cloud, and the CLI itself is positioned as something you ask questions of. The example is direct: clanker ask --aws --profile clankercloud-tekbog "what lambdas do we have?". The audience is engineers who already have working AWS, GCP, Azure or Cloudflare credentials on their machine and want an agent that can read them rather than a new credential store. The onboarding subcommands make that explicit. clanker onboarding scan detects local credentials and missing provider CLIs, then returns install docs, auth commands and token URLs. That is a tool designed for a machine that is already half-configured.

Two execution paths: static list commands and the agent loop

The architecture visible in the README is a split between deterministic reads and AI-mediated work. On the deterministic side, each provider exposes list subcommands that the documentation says are read-only inventory without AI interpretation: clanker aws list resources, clanker gcp list services, clanker azure list resource-graph, clanker cf list pipelines. Each provider advertises its full supported resource list through its own help text (clanker aws list --help and so on), which means the surface area is discoverable without reading source. This is the part of the tool that behaves like a normal CLI. On the other side sits the agent: ask questions about infrastructure, optionally including GitHub, and the maker and deploy flows that generate or apply infrastructure plans. The README does not spell out the internal orchestration, so how the swarm decomposes a request is not something I can describe from the supplied material. What is clear is the trust boundary. Static list commands return provider data. The agent path can generate and apply changes, which is a different risk class entirely.

Install, update channel and the config file that changes defaults

Installation is Homebrew or source. The README is unusually candid that brew tap clankercloud/tap followed by brew install clanker can lag, and that building from master with make install is the better option. Self-update is clanker update, which by default pulls the latest GitHub release from bgdnvk/clanker. To track the default branch instead, you set the channel at setup with clanker config init --update-channel main, or edit ~/.clanker.yaml under update.channel with the values release or main. A single run can override it: clanker update --channel release. Config comes from cp .clanker.example.yaml ~/.clanker.yaml or clanker config init. Provider keys are mostly environment variables: OPENAI_API_KEY, GEMINI_API_KEY, COHERE_API_KEY. The no-config defaults matter more than they look. Without ~/.clanker.yaml the default provider is openai and the model is gpt-5, unless you pass --ai-profile. Key resolution is ordered: --openai-key then OPENAI_API_KEY, with ai.providers.openai.api_key and ai.providers.openai.api_key_env available if a config file exists. Gemini and Cohere follow the same pattern, defaulting to gemini-2.5-flash and command-a-03-2025 respectively. For AWS, Clanker reads local AWS CLI profiles rather than raw access keys in its own config, and the README recommends SSO where the account supports it, with aws configure sso, aws sso login --profile, and aws sts get-caller-identity --profile as the verification path.

Clanker Apps: a narrow hosting product with hard limits

Clanker Apps is the part of the product that is not about inspecting existing infrastructure. It is account-scoped, immutable deployment of a single HTML document, described as being for small team software. You create an app, deploy an HTML file, then publish one deployment with share (also activate or publish), which returns a shareable link alongside the full JSON result. unpublish removes public access while keeping retained versions; delete disposes of the app and all its versions and hosted artifacts. The constraints are specific and worth reading before you build anything on it. Single-file HTML deployments must be valid UTF-8 and are capped at 2 MiB. The CLI sends exactly the supplied HTML and does not strip features or filter content. Network calls follow normal browser and API CORS behavior. The runtime identifies itself as clanker-html-v1 in deployment output, along with file count, total bytes and browser network policy. The README also notes HTML apps can opt into hosted Gemini or Kimi calls without shipping provider credentials inside the document. That last point is the design intent: a small app can call a model without embedding a key in client-side code.

Where Clanker is the wrong tool

The first limitation is that Clanker is at v0.0.9, with v0.0.8 and v0.0.7 landing roughly a month apart before it. The README itself warns the Homebrew package may be outdated relative to master. A tool that can apply infrastructure changes and whose recommended install path is building from a moving branch is not something to put in a change-controlled pipeline without pinning. Second, the agent path is only as auditable as the plan it produces. The README states Clanker can generate or apply infrastructure and deploy plans, but it does not describe a dry-run or diff gate for the apply flow the way it does for onboarding install --dry-run. If your environment requires reviewable plans, the maker and deploy flows are the part to probe first. Third, the AI dependency is real: without a config file you fall back to openai and gpt-5, so an air-gapped or key-less environment degrades to the static list commands. That is a fine fallback, but it is not the product as advertised. Finally, the 2 MiB single-file HTML limit and the absence of a build step mean Clanker Apps is not a place for anything with a bundler, multiple routes, or server-side logic.

How it differs from Pulumi and Terraform

Terraform and Pulumi both work from declared state. You write configuration or code, the tool computes a diff against a state file, and you approve the plan. Clanker inverts that. The README frames it as asking questions about infrastructure and optionally generating plans, with the provider CLIs as the execution layer. There is no state file described in the material, which means no drift detection in the Terraform sense and no lock semantics. That is the actual difference in approach: Terraform is declarative and stateful, Clanker is interrogative and imperative. For inventory, Clanker's static list commands are closer to a scripted aws describe call than to terraform plan. For changes, an agent-authored plan has no equivalent of a reviewed .tf diff unless you build that review yourself. The practical consequence is that Clanker complements a state-managed tool rather than replacing it. If you already run Terraform, the useful surface is the read-only list commands and the ask flow over resources you own.

Licence, maintenance and upgrade cost

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own code. It does not, however, cover the hosted Clanker Cloud service, which the README links separately and which the cloud apps commands depend on via CLANKER_CLOUD_API_KEY. Those are two different things under two different sets of terms, and the MIT grant on the CLI says nothing about the hosted API. On maintenance: the update channel setting is the main upgrade lever. If you set update.channel to main you are tracking unreleased commits, which raises the cost of every upgrade because you cannot diff against a tagged release. Staying on release means accepting that Homebrew may lag, as the README warns, and that clanker update pulls from the GitHub release rather than your package manager. The provider CLI dependency is the recurring cost that is easy to underestimate. Clanker delegates to whatever aws, gcloud, az, kubectl and flyctl versions you have installed, so a breaking change in a provider CLI surfaces inside Clanker rather than in a version you control.

Editorial conclusion

Adopt Clanker if you already run provider CLIs and want an agent that reads local profiles instead of storing long-lived cloud keys, and if the static list commands cover the inventory you need. Do not adopt it as a Terraform replacement or as a source of truth for production state. First verify your default AI provider and key resolution path, since running without ~/.clanker.yaml silently falls back to openai and gpt-5, and confirm which providers your onboarding scan actually detects.

Official sources

1. bgdnvk/clanker on GitHub
2. License: MIT
3. Project website
4. README
5. Releases