Clanker prefers your own cloud profiles, and its Homebrew tap can lag master

Two update channels, and the tap can lag behind master

Installation is offered three ways, and the one the documentation recommends is not the easiest.

The package tap is two commands:

brew tap clankercloud/tap
brew install clanker

But that section is labelled as potentially outdated, with the advice that the best option is to build from the default branch. Building from source is a single make target, and the binary can then update itself with a third command.

The update mechanism has a decision embedded in it. By default, updating replaces the binary with the latest GitHub release. To follow the latest commit on the default branch instead, the channel is set once during setup, either through a config init flag or by editing a small block in the config file. It can also be overridden for a single run, which is what makes it safe to try the other channel once without changing your standing preference.

So there are two questions to answer before installing: which build you start from, and which stream you track afterwards. Getting both wrong is how you end up running a release older than the documentation you read.

The onboarding scan returns documents, it does not install

The setup flow separates detection from action, which is the right shape for a tool an agent may drive.

A scan detects local credentials and missing provider command-line tools, then returns official install documentation, authentication commands, and token or account URLs. It does not install anything. A scan can be run bare, narrowed to named providers, and asked for JSON output, which is the format an agent would want.

Installation is a separate step, and it too separates planning from execution. A dry run takes the same provider list and prints what it would do. The real invocation then names the binaries directly, so what gets installed is visible in the command rather than inferred from a flag.

Providers are treated according to their own conventions rather than a single scheme. AWS uses its official CLI installer and local profiles. Google Cloud uses its own CLI plus Application Default Credentials. Azure uses the official sign-in flow.

The instructions for agents are unusually careful: run the install step, rerun the scan, then walk the user through whatever remains, whether that is a browser login, single sign-on, a sudo prompt or an official token step. The tool stops at the point where a human has to be present.

AWS credentials stay in your AWS CLI, not in the agent config

The authentication model is the most consequential design choice in the tool.

Clanker uses your local AWS CLI profiles rather than raw access keys placed in its own configuration file. The guidance is to create a profile with the official AWS CLI, preferring single sign-on where the account supports it and using access keys only when the account requires them.

The verification commands are the ones to run first. Logging in through the SSO flow, printing a profile's configuration, and asking for the current caller identity each confirm a different thing: that the profile exists, what it contains, and which identity it resolves to.

A default environment and profile are then set in the config file, together with a region, and the same values can be overridden for a single command by passing a profile flag to a question.

The reason this matters is that it inverts the usual trust arrangement. Nothing sensitive is copied into a new file for the agent to hold, and revoking access means removing the profile rather than rotating a key inside a tool's settings.

There is a list path that avoids the model entirely

Not everything needs to go through an agent, and the tool provides the alternative explicitly.

Each provider exposes static list commands for read-only inventory, described as working without any AI interpretation. The naming is per provider and per resource family: resource listings for AWS and Google Cloud, service and worker-pool listings for Google Cloud, a resource graph and private endpoint listing for Azure, and search, browser session, secret store and pipeline listings for Cloudflare.

Each provider also documents how to discover the rest of its supported resources, through the help for that provider's list command rather than a manual.

This is worth more than a convenience feature. An inventory question has a right answer that does not vary with a model, and a deterministic path means a scripted check can rely on the output. The agent path is for the questions where the answer is a synthesis across resources, and keeping the two separate is what stops a routine audit from becoming a prompt.

The provider set is broader than the two hyperscalers, which is the other reason the static path exists.

Key resolution is an ordered chain with published model defaults

Running with no config file at all is a supported mode, and the defaults in it are specified rather than implied.

The default provider is OpenAI unless a profile flag says otherwise. For OpenAI, a key given on the command line wins, then the environment variable, and the config file's own provider fields are consulted only when a config exists. The same three-step order is documented for the Gemini and Cohere profiles.

Model defaults are published alongside: the OpenAI profile defaults to a GPT-5 model, the Gemini profiles to a flash-class model, and the Cohere profile to a dated command model. That matters because a tool whose default model changes silently changes what you get, and these are written down.

Provider keys generally come from environment variables, with three examples given, and the config file itself is optional: you copy an example to your home directory and edit it, or run a config init command.

The practical pattern is a thin config file and fat environment, which makes the same configuration usable from a shell, a CI job and an agent session without rewriting secrets per context.

Apps are one HTML file, capped, and sent unmodified

The deployment feature has a narrow contract, and the narrowness is the point.

An app is an account-scoped, immutable deployment of small team software. A deployment is a complete HTML document, deployed when you need working JavaScript, forms, browser storage, external resources, downloads, navigation or API calls. The document runs as supplied at its own public app URL, and network calls follow ordinary browser and API cross-origin behaviour.

The lifecycle is explicit about privacy. Creating an app or a deployment leaves it private. A separate activation step, also reachable under publish or share, publishes one deployment and returns a shareable link while the full result stays available in the output. Unpublishing removes public access without removing retained versions, and deleting disposes of the app, its versions and its hosted artifacts permanently.

The limits are numeric. A single-file deployment must be valid UTF-8 and no more than two mebibytes. The CLI sends exactly the HTML supplied, without removing features or filtering content, and the output names the runtime and reports its file count, total size and browser network policy.

An HTML app can also opt into hosted model calls without shipping provider credentials inside the document, which is the one part of the design that breaks the no-credentials rule deliberately and visibly.

A Go binary with a container image target and an unusual dependency set

The build is a single Go binary with a straightforward make interface.

Building produces one named binary into a bin directory from the root main file. Installation prefers the Homebrew prefix bin directory when Homebrew is present and falls back to a system location otherwise, so the same make target lands the binary somewhere on the path either way. Tests run in full or short mode, with the short mode noted as the one intended for continuous integration.

The version string is injected at link time from a tag variable, which is how a release build differs from a local one without editing source.

Alongside the usual targets there is a container image target with its own project, region and repository variables, pointing at an artifact registry path, plus separate targets to build and to push it. Two Dockerfiles sit at the root with distinct names, one for that box image and one for a role the names suggest is operations.

The dependency list explains the provider coverage. Google Cloud client modules, a set of AWS service clients spanning batch, cost, compute, containers, databases, storage and identity, plus database drivers, a GitHub client, an MCP server library, the cobra and viper command-line and configuration pair, and a set of Tencent Cloud modules. That last group is the one to note, since it is not a provider named in the description.

Editorial conclusion

Clanker fits someone who already has local cloud CLI profiles and wants to ask questions about their infrastructure, or to keep a non-model path for routine inventory. It does not fit anyone who wants credentials managed centrally, since the design deliberately delegates authentication back to the provider CLIs. Two things to check before relying on it. The project recommends building from master because the package tap can be outdated, so decide which channel you trust before setting an update preference. And the versions are still in the zero point releases, which is a reasonable signal to treat the output as assistance rather than as something to run unattended against production.

Frequently asked questions

Official sources

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