AIOps tools ask for an unusual amount of trust. They inspect cloud accounts, read Kubernetes state, summarize production incidents, and sometimes propose infrastructure changes. If the engine behind that workflow is closed, every operator has to accept a black box at the exact place where production risk is highest.
That is why Clanker Cloud is built on the open-source Clanker CLI. The CLI is a Go binary under the MIT license. It can run on its own from a terminal, expose an MCP server for agents, and power the local-first desktop workflow inside Clanker Cloud.
The desktop app is the workspace. The CLI is the engine. That split matters.
AIOps Needs an Engine, Not Just a Dashboard
Most operations tools start with a dashboard. A dashboard is useful when you already know which metric matters, which namespace to inspect, and which graph explains the incident. AIOps starts somewhere messier: a human or agent asks, "why is checkout slow?" or "what changed in production?" and the system has to decide what to inspect.
That requires an engine with four jobs:
- Route the question to the right provider or tool.
- Pull live infrastructure state from local credentials.
- Interpret the results with the selected AI provider.
- Separate read-only investigation from actions that change infrastructure.
Clanker CLI does that work. It can ask live infrastructure questions, run Kubernetes and cloud workflows, expose MCP tools, generate maker plans, and apply reviewed plans only when explicitly instructed.
Clanker Cloud wraps that engine with a desktop interface, saved provider context, topology views, Deep Research, and a product workflow for teams. The reason the app can stay local-first is that the core execution path is local-first already.
Why the CLI Is Open Source
Open source is not only a community preference here. It is a security and procurement property.
Infrastructure teams need to answer practical questions before adopting an AI operations tool:
- Where do cloud credentials live?
- Which commands can run against production?
- How does the system decide whether a request is read-only or mutating?
- Can operators inspect the exact behavior when a query routes to AWS, Kubernetes, GitHub, or another provider?
- Can a security team review the engine before approving the workflow?
With Clanker CLI, the answer is not "trust the vendor." The code is at github.com/bgdnvk/clanker. Teams can inspect how local AWS profiles are used, how MCP tools are exposed, how maker plans are generated, and how debug or agent trace output works.
That changes the conversation from faith to verification.
Local Credentials Are the Foundation
AIOps becomes dangerous when the tool centralizes privileged credentials in a hosted service. The blast radius expands from one workstation or one CI environment to a vendor-controlled account boundary.
Clanker CLI follows the opposite model. It uses the credentials already configured on the machine: AWS CLI profiles, kubeconfig, provider CLIs, environment variables, and local config. The CLI can call cloud APIs and AI providers from the user's environment without requiring Clanker Cloud servers to become a credential relay.
That is the model Clanker Cloud inherits. The desktop app provides the interface, but the trust boundary stays local. For teams evaluating local-first AI DevOps, this is the core architectural choice.
Read-First, Act-Second
The most important AIOps workflow is not automatic remediation. It is accurate investigation followed by reviewed action.
Clanker CLI supports that split directly:
clanker ask "what changed in prod since the deploy?" | cat
That kind of question is investigative. It should gather context and explain risk.
When a user wants to make a change, maker mode generates a plan first:
clanker ask --aws --maker "create a small ec2 instance and postgres rds" | cat
Applying is a separate step:
clanker ask --aws --maker --apply --plan-file plan.json | cat
Destructive operations require an additional explicit flag:
clanker ask --aws --maker --destroyer "delete the staging rds instance" | cat
This is the same philosophy behind Clanker Cloud's review-before-execution workflow. The AI can help inspect, summarize, and plan. The operator still owns approval.
MCP Makes the CLI Composable
Modern AIOps is no longer just a human typing into a terminal. Claude Code, Codex, OpenClaw, Hermes, and custom internal agents all need a way to ask infrastructure questions without receiving raw cloud credentials.
Clanker CLI exposes that interface through MCP:
clanker mcp --transport http --listen 127.0.0.1:39393 | cat
The standalone CLI MCP server exposes tools for version checks, routing decisions, and running local clanker commands. That means an MCP-capable agent can ask for live infrastructure context through a controlled local tool surface instead of inventing shell commands or guessing from stale repository files.
Clanker Cloud extends this idea into a desktop workspace. Agents can use a local MCP surface while humans get a visual operational layer around the same underlying engine.
Why This Powers Clanker Cloud
The reason Clanker Cloud can support a wide set of operations workflows without becoming another hosted credential warehouse is that its foundation is a local engine.
The CLI handles the hard operational primitives:
- Routing natural-language questions to the right provider.
- Running live reads against AWS, Kubernetes, DigitalOcean, Hetzner, GitHub, and other systems.
- Supporting BYOK AI provider profiles.
- Exposing MCP for agents.
- Generating and applying reviewed infrastructure plans.
- Printing debug and trace output for auditability.
The desktop app makes those primitives usable across a full team workflow: topology, context, sessions, model configuration, Deep Research, and safer review surfaces.
That is the right layering for AIOps. Put the engine where the credentials live. Put the workspace where humans and agents collaborate.
Start with the Engine
The simplest way to understand Clanker Cloud is to start with the engine underneath it.
brew tap clankercloud/tap
brew install clanker
clanker ask "what infrastructure is running?" | cat
Or inspect the code directly at github.com/bgdnvk/clanker.
When you want the full workspace around that engine, use Clanker Cloud: the local-first desktop app for AI-assisted infrastructure operations, live cloud context, MCP agents, and reviewed execution.
Give your agent live infrastructure context
Download Clanker Cloud, expose the local MCP surface, and let coding agents work from current cloud, Kubernetes, GitHub, and cost state instead of guesses.