Answer-first
Each example starts with the decision or finding the operator needs, not a generic feature tour.
Example library
Clanker Cloud examples
This is the proof library for Clanker Cloud app claims. Each workflow starts with the answer, gives you an in-app query to copy, names the required local context, shows a realistic output, and states the safety boundary.
Use these examples to verify how the app uses local credentials, multi-cloud scans, MCP agent access, Kubernetes troubleshooting, cost investigation, and review-before-apply workflows. The open-source CLI powers the same local runtime and appears as the equivalent path where useful.
Clanker Cloud is easiest to evaluate through concrete app workflows: problem, app query, context, output, safety boundary, supported providers, and next step.
App-first
Queries are written for the Clanker Cloud app first, with CLI equivalents only where terminals, automation, or MCP clients need them.
Safety stated
Every workflow calls out what is read-only and what requires explicit review or maker-mode approval.
Provider grounded
Examples name the supported providers and context needed before the query runs.
Workflow library
Concrete examples you can verify
Debug Kubernetes 502 responses
Users get HTTP 502 from a Kubernetes app even though DNS and the public load balancer are reachable.
Find an AWS cost spike
AWS spend is up sharply this week and the team needs to know which resources, services, and changes explain it.
Scan Cloudflare and EKS together
The team needs to know which Cloudflare routes reach EKS workloads and whether any public paths skip expected authentication or WAF controls.
Use Claude Code MCP with Kubernetes
Claude Code can inspect the repo, but it cannot see the running cluster, failing pods, ingress state, or cloud context without a controlled tool surface.
Review before applying a Terraform change
The team needs to add or modify infrastructure but wants a reviewable artifact before any provider API write runs.
At a glance
Which workflow answers which query
| Example | Use it when | Safety boundary |
|---|---|---|
| Debug Kubernetes 502 responses | Users get HTTP 502 from a Kubernetes app even though DNS and the public load balancer are reachable. | Read-only investigation. The app reads cluster state through the local runtime and the open-source CLI engine underneath it. No kubectl apply, delete, restart, or rollout command runs unless you create and approve a separate maker/action plan. |
| Find an AWS cost spike | AWS spend is up sharply this week and the team needs to know which resources, services, and changes explain it. | The app reads Cost Explorer and resource metadata through the local runtime. It does not resize, delete, or purchase commitments. Any optimization that changes infrastructure should be generated as a plan and explicitly approved. |
| Scan Cloudflare and EKS together | The team needs to know which Cloudflare routes reach EKS workloads and whether any public paths skip expected authentication or WAF controls. | The scan inventories resources and performs bounded reachability checks. It does not mutate DNS, WAF, ingress, or Kubernetes objects. Remediation stays behind a reviewed plan. |
| Use Claude Code MCP with Kubernetes | Claude Code can inspect the repo, but it cannot see the running cluster, failing pods, ingress state, or cloud context without a controlled tool surface. | MCP runs locally through the same runtime that powers the app. Read-only tools expose version, routing, and provider queries through the Clanker safety model. Apply-style changes still require an explicit approved plan. |
| Review before applying a Terraform change | The team needs to add or modify infrastructure but wants a reviewable artifact before any provider API write runs. | Maker mode in the app generates reviewable plan output. Apply mode is separate. Destructive operations require the explicit destroyer flag and should not be enabled through ambient config. |
Trust and architecture
Read the boundary pages next
Local credentials
Canonical trust page for storage, model calls, telemetry, logs, BYOK, and MCP localhost boundaries.
MCP server for cloud infrastructure
Stable product page for connecting agents to live cloud and Kubernetes context.
How Clanker Cloud works
Request flow, local runtime, provider context, and reviewed-plan execution.
FAQ
Common questions
Are these examples for the app or only the CLI?
They are app-first Clanker Cloud workflows. The public Clanker CLI is the open-source engine underneath the local runtime, so CLI equivalents are included only when they help explain automation, MCP, or terminal use.
Do the examples send credentials to Clanker Cloud servers?
No. The examples rely on local credentials, kubeconfigs, and model keys already trusted on the operator machine. The local credentials page documents the boundary in detail.
Next step
Want to test one workflow?
Start with a read-only example, then move to reviewed plans only when the evidence is clear.