Under the Hood: How Clanker Cloud Is Powered by the Open-Source Clanker CLI

Clanker Cloud is a local-first desktop app that wraps and extends the open-source clanker CLI — a Go-based autonomous infrastructure agent under the MIT license. Every query you run in the desktop app, every plan it generates, and every deployment it executes flows through the same Go engine that you can read, fork, and run standalone. There is no separate proprietary inference layer; the desktop adds a GUI, persistent configuration, and an MCP endpoint on top of the CLI's core logic.

This article traces a query from keypress to result. If you want to understand exactly what Clanker Cloud does with your cloud credentials, your API keys, and your infrastructure commands before you trust it with production, read on.

---

The clanker CLI: the engine

The clanker CLI describes itself as an "autonomous systems engineering CLI agent for any cloud environment." That description is accurate but worth unpacking.

The binary is written in Go. Its job is to take a natural language question about infrastructure, figure out which tools are needed to answer it, invoke those tools against your actual cloud environment, pass the raw output to an AI model, and return a coherent response. That loop — route, invoke, interpret — is what Clanker Cloud runs every time you interact with it.

The code is public at github.com/bgdnvk/clanker and licensed MIT. The routing logic, the tool selection, the maker pattern, and the MCP server surface are all in that repository. The Clanker Cloud desktop app adds a GUI layer, a persistent provider configuration UI, and a local MCP endpoint for external agents, but the inference and infrastructure work happens inside the CLI engine.

The CLI supports AWS, GCP, Cloudflare, Kubernetes, DigitalOcean, Hetzner, and GitHub, routing each query to the appropriate CLI tool (AWS CLI, kubectl, gcloud, doctl, hcloud, and others). AI provider support includes OpenAI, Gemini, Cohere, and any model running locally via Ollama.

---

How a query flows through the system

Here is a concrete end-to-end trace for a query run from the CLI or from the desktop app's command surface:

Step 1 — User input

clanker ask "what's the status of my chat service lambda?"

Step 2 — Routing layer

The CLI's routing layer inspects the query and determines which cloud provider and tool set apply. In this case: AWS, Lambda tools. You can inspect this decision without executing anything by passing --route-only:

clanker ask --route-only "what's the status of my chat service lambda?"

The routing decision is printed to stdout. No cloud API call is made.

Step 3 — Tool invocation

The CLI constructs the appropriate AWS CLI commands using the profile configured in ~/.clanker.yaml (or overridden with --profile). These commands run locally — the CLI is a Go wrapper around your existing AWS CLI installation, not a separate credential vault.

Step 4 — Raw output collection

The raw AWS CLI output (JSON, text, or structured log lines) is collected in memory.

Step 5 — AI interpretation

The raw output is passed to the configured AI model with a structured prompt. The model summarizes and interprets the data — explaining service health, flagging anomalies, surfacing the relevant details. The AI call goes directly from your machine to the AI provider's API using the key stored in your environment or config file.

Step 6 — Result returned

The interpreted result is printed locally. Nothing has transited through Clanker Cloud servers at any stage of this flow. The chain is: local AWS CLI → local AI provider API → local output.

To expose the full coordinator and agent lifecycle — which tools were selected, which investigation steps ran, in what order — pass --agent-trace:

clanker ask --agent-trace --profile dev "how can I create an additional lambda and link it to dev?"

This prints the tool selection and investigation steps as they happen, so you can verify the agent's behavior rather than trusting a black box.

---

The maker/apply pattern: read-first by design

The CLI enforces a read-first, act-second model through the maker/apply pattern. This is not a UI convention imposed by the desktop app — it is implemented at the CLI level and applies whether you are running the binary directly or through the GUI.

Step 1 — Generate a plan

clanker ask --aws --maker "create a small ec2 instance and a postgres rds" | cat

This prints a JSON plan describing every AWS CLI command the agent intends to run. Nothing is executed. The plan can be reviewed by a human, passed to another agent, or checked into version control.

Step 2 — Apply the approved plan

clanker ask --aws --maker --apply < plan.json | cat

or

clanker ask --aws --maker --apply --plan-file plan.json | cat

The --apply flag must be explicitly passed. Without it, --maker only generates. This means there is no path through the CLI where infrastructure changes happen without an explicit review gate.

Destructive operations require an additional flag

clanker ask --aws --maker --destroyer "delete the clanka-postgres rds instance" | cat

--destroyer must be passed explicitly for any destructive operation. It is not on by default, and it cannot be triggered by a maker plan that was generated without it.

Maker apply safety behavior

When --maker --apply runs, the apply engine handles common edge cases:

• Idempotent errors (e.g., duplicate security group rules) are treated as success when safe to do so.
• Async AWS operations (CloudFormation create/update) are waited to terminal state before the run is considered complete, so failures surface immediately rather than silently.
• If a common AWS runtime issue is detected (CIDR conflicts, subnet mismatches, template errors), the runner rewrites and retries the affected command.
• If built-in retries are exhausted, the engine escalates to AI for prerequisite command generation, then retries the original command with exponential backoff.

The desktop app surfaces this behavior as the visual read-first/act-second workflow described on the Clanker Cloud demo page. The underlying enforcement is in the Go CLI.

---

The MCP layer

The CLI exposes an MCP (Model Context Protocol) server surface via the clanker mcp subcommand.

HTTP transport (default for the desktop app integration):

clanker mcp --transport http --listen 127.0.0.1:39393 | cat

stdio transport (for MCP clients that launch the binary directly):

clanker mcp --transport stdio | cat

When the Clanker Cloud desktop app is running, it exposes its own MCP endpoint at the same local address. External agents — Claude Code, Codex, OpenClaw, or any MCP-compatible client — can connect to this endpoint and use the following three tools:

clanker_version

Returns the installed clanker version. Useful for health checks and for verifying that the agent is connected to the running instance.

clanker_route_question

Returns the CLI's internal routing decision for a given prompt. This is the debug surface for understanding how the agent classifies queries and selects tools — without executing anything.

# Example: inspect routing without execution
curl -sS -X POST http://127.0.0.1:39393/mcp \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json, text/event-stream' \
    --data '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"clanker_route_question","arguments":{"question":"use clanker cloud mcp to show my saved settings"}}}' | jq

clanker_run_command

Executes a clanker command through MCP and returns the result. This is how external agents trigger ask, openclaw, and other subcommands programmatically:

curl -sS -X POST http://127.0.0.1:39393/mcp \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json, text/event-stream' \
    --data '{"jsonrpc":"2.0","id":5,"method":"tools/call","params":{"name":"clanker_run_command","arguments":{"args":["ask","--route-only","what lambdas are running"]}}}' | jq

This MCP surface is how Clanker Cloud integrates into agent-driven workflows. An AI coding agent like Claude Code can ask Clanker Cloud for live infrastructure context, receive a grounded answer based on real resource state, and incorporate that into its next action — all without direct access to your cloud credentials.

---

clanker talk and Clanker Cloud backend routing

The clanker talk command opens a chat mode. When the Clanker Cloud desktop app is running, clanker talk routes queries to the local Clanker Cloud app backend first. This gives the chat session access to desktop-aware context: your saved provider configurations, your current environment, your active session state.

If the desktop app is not running, clanker talk falls back to Hermes (the local Ollama-backed model). The fallback is automatic and transparent.

The routing behavior is verifiable:

clanker ask --route-only "use clanker cloud mcp to show my saved settings" | cat
clanker ask --route-only "ask clanker cloud about the running app backend" | cat

These commands show the routing decision without executing it, so you can confirm that queries are going where you expect.

---

BYOK and AI provider routing

The CLI selects its AI provider via the --ai-profile flag, which maps to a provider profile in ~/.clanker.yaml. Credentials are read from environment variables or the config file and passed directly to the provider's API from your machine.

Profile	Default model
openai (default)	gpt-5
gemini-api	gemini-3-pro-preview
cohere	command-a-03-2025
Ollama (local)	gemma4, hermes, or any installed model

Examples:

clanker ask --ai-profile openai "What are the latest logs for our dev Lambda functions?"

clanker ask --ai-profile cohere --cohere-model command-a-03-2025 "Summarize the current deployment risks in dev."

clanker ask --ai-profile gemini-api "What changed in our prod environment in the last 24 hours?"

No AI credentials transit through Clanker Cloud servers. The API call goes from your machine directly to OpenAI, Google, Cohere, or your local Ollama instance depending on the selected profile.

The Clanker Cloud desktop app surfaces this as a BYOK (bring-your-own-key) model selection UI. The underlying routing is the same --ai-profile mechanism in the CLI. This is covered in more detail in the AI DevOps for teams context.

---

Architecture diagram

User query (desktop app or CLI)
           │
           ▼
  clanker CLI (Go engine)
  ~/.clanker.yaml config
           │
     ┌─────┴──────┐
     ▼            ▼
Cloud APIs     AI provider
(AWS CLI,      (OpenAI / Gemini /
 kubectl,       Cohere / Ollama)
 gcloud,              │
 doctl,               │
 hcloud,              │
 CF API)              │
     │                │
     └────────┬───────┘
              ▼
       Raw output + AI interpretation
              │
              ▼
       Result (local — no data
       transits Clanker Cloud servers)
              │
              ▼
    ┌─────────────────────┐
    │  MCP server         │
    │  127.0.0.1:39393    │
    │                     │
    │  clanker_version    │
    │  clanker_route_     │
    │    question         │
    │  clanker_run_       │
    │    command          │
    └────────┬────────────┘
             │
             ▼
   External agents
   (Claude Code, Codex,
    OpenClaw, any MCP client)

The maker gate sits between the routing layer and cloud API calls when --maker is passed. The plan is generated and halted at the review stage; --apply resumes execution.

---

Why this architecture is trustworthy

The source is open. The Go engine that processes your queries is at github.com/bgdnvk/clanker under the MIT license. You can read the routing logic, the tool invocation code, and the MCP implementation directly.

The routing is transparent. --route-only shows routing decisions without executing. --agent-trace shows the full coordinator and agent lifecycle — which tools were selected, which investigation steps ran, in what order. You are not relying on a black box.

AWS credentials use the standard AWS CLI profile system. Clanker reads from the same ~/.aws/credentials and ~/.aws/config that the AWS CLI uses. You configure a profile with aws configure --profile <name>, confirm it with aws sts get-caller-identity --profile <name>, and reference the profile name in ~/.clanker.yaml. There is no new credential surface and no additional place where AWS keys are stored.

The maker gate is enforced at the CLI level. Infrastructure changes do not happen without --apply. Destructive operations do not happen without --destroyer. These constraints apply whether you are running the binary directly, through the desktop app, or through an external agent via MCP.

No data transits Clanker Cloud servers. The processing chain is local: CLI → local cloud tools → AI provider API (direct) → local output. The desktop app adds configuration management and the MCP endpoint, both of which run on your machine.

---

FAQ

How does Clanker Cloud handle my cloud credentials?

Cloud credentials never leave your machine. For AWS, Clanker uses your existing AWS CLI profiles — the same profiles configured with aws configure. For other providers (GCP, Cloudflare, DigitalOcean, Hetzner), credentials are set as environment variables or stored in ~/.clanker.yaml on your local filesystem. The Clanker Cloud desktop app reads this config to populate its provider UI. Nothing is uploaded to Clanker Cloud servers.

What happens when I type a query in Clanker Cloud?

The desktop app passes the query to the local clanker CLI engine. The CLI routing layer determines which cloud provider and tools apply, invokes the relevant CLI commands against your local credentials, collects the raw output, and passes it to your configured AI provider's API (directly from your machine). The result is returned locally. See the architecture diagram above for the full flow.

Is the clanker CLI the same as the Clanker Cloud desktop?

They share the same Go engine. The clanker CLI is the open-source core — it runs standalone from a terminal and covers the full routing, maker/apply, Kubernetes, and MCP surface. The Clanker Cloud desktop app is a GUI layer on top of that engine. It adds persistent multi-cloud configuration, a visual read-first/act-second workflow, BYOK model selection UI, and the local MCP endpoint for external agents. You can use the CLI without the desktop app. The desktop app does not work without the CLI engine underneath it.

How does Clanker Cloud's MCP server work?

When the desktop app is running, it starts a local MCP server (by default at 127.0.0.1:39393). External agents connect to this endpoint using the MCP protocol over HTTP or stdio. The server exposes three tools: clanker_version (version info), clanker_route_question (returns the routing decision for a prompt without executing), and clanker_run_command (executes a clanker command and returns the result). Any MCP-compatible agent — Claude Code, Codex, OpenClaw — can use these tools to query live infrastructure context through Clanker Cloud. See the MCP integration docs for client configuration examples.

---

Get started

• Source code: github.com/bgdnvk/clanker — read the routing logic, the maker implementation, and the MCP server code
• Create an account: clankercloud.ai/account — download the desktop app
• Documentation: docs.clankercloud.ai — full reference for config, providers, and MCP integration

If you want to see the routing and planning behavior before committing to any configuration, install the CLI from source (make install), copy the example config (cp .clanker.example.yaml ~/.clanker.yaml), and run a few --route-only queries against your existing AWS profile. The routing decisions are printed to stdout. Nothing is executed until you explicitly ask it to be.