Clanker Cloud Is Open-Source First: Built on the Clanker CLI

When a tool asks for access to your AWS credentials, your Kubernetes clusters, and your production infrastructure, you should be able to read the code behind it. That is not an idealistic position — it is a practical one. Open source is a security feature.

Clanker Cloud is built on the clanker CLI, an open-source, MIT-licensed agent written in Go. The CLI is the engine that powers the desktop app. It is available on GitHub today, free to use, free to inspect, and free to contribute to. This article explains what it is, what it does, how to get started, and why we built things this way.

---

Why Open Source Matters for Infrastructure Tools

Most infrastructure tooling lives in a black box. You give it credentials, it does things to your cloud, and you trust that it is behaving correctly. When something goes wrong, you cannot audit what happened. When you want to understand a decision, you cannot read the code that made it.

The calculus changes when the tool is open source. You can read how credentials are handled. You can verify that nothing is being exfiltrated. You can run it in an air-gapped environment. You can fork it and adapt it to your organization's security policies.

For an AI agent that touches your DevOps workflows, transparency is especially important. When the clanker CLI calls an AWS API or generates an infrastructure plan, you can trace exactly what happened — using --debug, --agent-trace, or by reading the source. That is not a nice-to-have. For production infrastructure, it is essential.

This is why we started with the CLI before building the desktop app. The CLI came first. The desktop app is built on top of it.

---

The Clanker CLI: What It Is

The clanker CLI is described in its own README as an "autonomous systems engineering CLI agent for any cloud environment: AWS, GCP, Cloudflare, etc." It is the main agent powering Clanker Cloud.

Written in Go and licensed under the MIT license, the CLI is a self-contained binary that you can install, configure, and run against your cloud environments. It supports AWS, Kubernetes, DigitalOcean, Hetzner Cloud, and more. It accepts plain-English questions about your infrastructure and returns real answers — not summaries of documentation, but actual data pulled from your cloud environment.

The same core agent logic runs inside the Clanker Cloud desktop app. When you use the desktop app, you are using the clanker agent. The app adds a local-first GUI, persistent session state, multi-cloud management, and model configuration — but the underlying agent is the same one you can run from your terminal right now. This is the same pattern as moving from prototypes to production infrastructure: start with the CLI, understand the tool, then graduate to the fuller workflow when you are ready.

---

Getting Started with the CLI

Install via Homebrew or from source:

# Homebrew
brew tap clankercloud/tap
brew install clanker

# Or from source
git clone https://github.com/bgdnvk/clanker
make install

Requirements: Go and AWS CLI v2 (if you are using AWS features).

Once installed, set up your config:

# Initialize a config file interactively
clanker config init

# Or copy the example config manually
cp .clanker.example.yaml ~/.clanker.yaml

The config file at ~/.clanker.yaml is where you define your cloud profiles, AI provider profiles, and environments. A minimal AWS setup looks like this:

infra:
    default_provider: aws
    default_environment: my-env

    aws:
        environments:
            my-env:
                profile: my-aws-profile
                region: us-east-1

Clanker uses your existing local AWS CLI profiles — it does not store raw access keys. You can verify your AWS identity the same way you always would:

aws sts get-caller-identity --profile my-aws-profile | cat

For AI provider credentials, set environment variables:

export OPENAI_API_KEY="..."
export GEMINI_API_KEY="..."
export COHERE_API_KEY="..."

The CLI works without a config file if you just want to try it — it defaults to OpenAI with GPT-5 and reads your OPENAI_API_KEY from the environment.

---

What You Can Do with It

The clanker CLI operates in several modes, each designed around a specific type of interaction with your infrastructure.

Ask mode: questions about your infrastructure

The most basic use case is asking questions in plain English:

clanker ask "what's the status of my chat service lambda?"
clanker ask "show me the last error from my big-api-service lambda"
clanker ask "list all deployments and their replica counts"

Clanker routes the question, determines which cloud APIs to call, runs them, and returns a readable response. Add --debug to see exactly which tools were selected and which API calls were made. Add --agent-trace for full coordinator and agent lifecycle logs.

Maker mode: plan before you apply

When you want to make infrastructure changes, maker mode generates a JSON plan first — before anything is applied. You review the plan, then decide whether to apply it.

# Generate a plan (prints JSON, touches nothing)
clanker ask --aws --maker "create a small EC2 instance and a Postgres RDS" | cat

# Apply an approved plan from stdin
clanker ask --aws --maker --apply < plan.json | cat

# Or apply from a file
clanker ask --aws --maker --apply --plan-file plan.json | cat

This is not just a UX nicety. The plan step is a hard gate. Nothing in your infrastructure changes until you have reviewed the JSON and explicitly applied it. For teams that are moving toward infrastructure management with AI agents, this human-in-the-loop design is the right default.

When you do apply, the runner handles real-world AWS behavior: idempotent errors are treated as success when safe, async operations are waited to terminal state, and if the runner detects common AWS issues — CIDR mismatches, subnet conflicts, template errors — it can rewrite and retry. If built-in retries are exhausted, it escalates to AI for prerequisite commands, then retries with exponential backoff.

Destroyer mode: destructive ops require an explicit flag

Deleting production infrastructure requires a separate flag. This is intentional:

clanker ask --aws --maker --destroyer "delete the staging RDS instance" | cat

The --destroyer flag must be passed explicitly for any destructive operation. There is no way to accidentally delete infrastructure through a normal ask or --maker invocation.

Kubernetes support

The CLI includes a full k8s subcommand for cluster management, monitoring, and natural language queries:

# Natural language queries against your cluster
clanker k8s ask "which pods are using the most memory"
clanker k8s ask "why is my pod crashing"

# Create an EKS cluster
clanker k8s create eks my-cluster --nodes 2 --node-type t3.small

# Get pod logs and cluster metrics
clanker k8s logs my-pod --tail 100 --since 1h
clanker k8s stats cluster

The k8s ask command uses a three-stage LLM pipeline: determine which kubectl operations are needed, execute them in parallel, then synthesize the results into a markdown response. Conversation history is maintained per cluster for follow-up questions.

---

MCP Server Mode

The CLI also runs as an MCP (Model Context Protocol) server, which means any MCP-compatible AI agent can use it as a tool. This is one of the more interesting properties of the open-source CLI: it is not just a terminal tool, it is an infrastructure interface that other agents can call.

# HTTP transport (any MCP client)
clanker mcp --transport http --listen 127.0.0.1:39393

# stdio transport (Claude Code, Codex, and other MCP clients)
clanker mcp --transport stdio

The MCP server exposes three tools:

• clanker_version — returns the installed clanker version
• clanker_route_question — returns the internal routing decision for a prompt
• clanker_run_command — runs any local clanker command through MCP

This means Claude Code, Codex, OpenClaw, and any other MCP-compatible agent can use the clanker CLI as a tool for infrastructure operations. If you are building workflows for AI agents, the MCP server mode is where the CLI becomes composable with the rest of your toolchain.

---

BYOK: Choose Your AI Provider

The CLI supports multiple AI providers through the --ai-profile flag. Your queries go directly from the CLI to your chosen provider — nothing passes through Clanker Cloud servers.

# GPT-5 (default)
clanker ask --ai-profile openai "what lambdas do we have?"

# Gemini 3 Pro Preview
clanker ask --ai-profile gemini-api "summarize the current deployment risks in dev"

# Cohere Command-A
clanker ask --ai-profile cohere "what's the health of my cluster?"

# Local Ollama model (Gemma 4, Hermes, etc.)
clanker ask --ai-profile ollama "list all running services"

Default models by provider: OpenAI defaults to GPT-5, Gemini to gemini-3-pro-preview, Cohere to command-a-03-2025. You can override the model within any provider profile in ~/.clanker.yaml.

The zero-data-to-Clanker-servers model is not a marketing claim — it follows directly from the architecture. The CLI communicates with your cloud via local AWS CLI profiles and with your AI provider via keys you control. You can verify this by reading the source.

---

The Relationship Between the CLI and the Desktop App

The CLI is the engine. The Clanker Cloud desktop app is the workspace built on top of it.

When you run the Clanker Cloud desktop, it uses the same core clanker agent logic. The desktop app adds:

• A local-first GUI for navigating multi-cloud environments
• Persistent session state across conversations
• A built-in MCP server for external agents to connect to
• A model configuration UI for managing AI provider credentials
• Unified management across AWS, Kubernetes, DigitalOcean, Hetzner, and other providers

But the agent is the same. If you are a terminal-first developer who wants to use clanker in scripts, CI/CD pipelines, or as part of an agentic workflow, the CLI gives you the same core capability without the desktop app. If you want to graduate to the full workspace later, your familiarity with the CLI translates directly.

You can see what the full desktop experience looks like on the demo page.

---

Open Source as a Security Feature

Trust in an infrastructure tool should not be based on the vendor's reputation alone. It should be verifiable.

With the clanker CLI, you can:

• Read the Go source code to understand exactly how credentials are handled
• Verify that nothing is exfiltrated — credentials stay local, queries go to your chosen AI provider
• Run it in air-gapped environments — no dependency on Clanker Cloud infrastructure for core functionality
• Fork it and customize it to match your organization's security policies
• Audit any specific behavior using --debug or --agent-trace without installing anything extra

This is not hypothetical. The code is at github.com/bgdnvk/clanker, MIT-licensed, and available to read right now.

For teams that need to get infrastructure tooling approved by a security team, open source is often the path of least resistance. There is no "trust us" in the conversation — there is just the code.

---

Contributing and Community

The clanker CLI is MIT-licensed and contributions are welcome. The repository is at github.com/bgdnvk/clanker.

If you want to contribute:

1. Clone the repo and install from source with make install
2. Browse the open issues or open one describing what you want to work on
3. Follow the standard GitHub workflow: fork, branch, pull request

The CLI is written in Go. If you are comfortable with Go and interested in AI agents, cloud APIs, or CLI tooling, this is a concrete place to contribute to a project that is actively used in production.

Full documentation is at docs.clankercloud.ai.

---

FAQ

Is Clanker Cloud open source?

The core engine — the clanker CLI — is fully open source under the MIT license at github.com/bgdnvk/clanker. The Clanker Cloud desktop app is built on top of this CLI. You can use the CLI standalone, inspect the source, fork it, or contribute to it. The desktop app is a commercial product built on the open-source core.

How do I install the clanker CLI?

Via Homebrew: brew tap clankercloud/tap && brew install clanker. From source: clone github.com/bgdnvk/clanker and run make install. You will need Go installed for the from-source path. AWS CLI v2 is recommended if you plan to use AWS features.

What is the difference between the clanker CLI and Clanker Cloud desktop?

The CLI is the agent — it handles infrastructure queries, maker plans, apply operations, Kubernetes management, and the MCP server. The Clanker Cloud desktop is a local-first workspace application that uses the same agent logic and adds a GUI, persistent session state, multi-cloud management, and model configuration. The desktop is built on top of the CLI; they share the same core.

Can I use the clanker CLI without the desktop app?

Yes. The CLI is a standalone tool. You do not need the desktop app to use it. It runs on macOS, Linux, and Windows. You can use it in scripts, CI/CD pipelines, as an MCP server for other AI agents, or as a terminal-first infrastructure interface. The desktop app is optional.

---

Get Started

• GitHub: github.com/bgdnvk/clanker — clone, install, read the source
• Clanker Cloud: clankercloud.ai/account — sign up for the desktop app
• Documentation: docs.clankercloud.ai — full reference for CLI commands, config, and cloud providers

The CLI is available now. Start with brew install clanker, point it at your AWS profile, and ask it what is running. The code is there if you want to look under the hood.