Local-First Infrastructure Automation: How Maker Mode and MCP Replace Manual Ops

There is a persistent misconception in infrastructure operations: if your tooling is local-first, you are stuck with manual workflows. The assumption is that automation requires a hosted platform with standing access to your credentials — that "local" and "automated" are mutually exclusive.

They are not.

Local-first infrastructure automation means automation runs with your credentials, on your machine, with your approval gates. The execution environment is yours. The credential chain is yours. The blast radius controls are yours. What you give up is the vendor's background access to your cloud accounts. What you keep is everything that actually matters for safe production operations.

This article covers three concrete automation patterns using Clanker Cloud and its open-source CLI, explains why local-first automation is safer than hosted automation, and shows how the approval gate model makes automated operations controllable rather than dangerous.

---

The False Choice: Local-First Does Not Mean Manual

The confusion comes from conflating "local" with "interactive." Local-first describes where your credentials live and where execution happens — on your machine, not a vendor's cloud. It says nothing about whether operations are scheduled, agent-driven, or require human input at each step.

Hosted automation platforms automate by holding your credentials and running changes on your behalf. That is one way to remove human friction. But it introduces a different kind of risk: a vendor's infrastructure has standing access to your production environment, changes can run without your awareness, and a vendor-side breach or misconfiguration becomes your incident.

Local-first automation removes the vendor from the execution path entirely. Your machine holds credentials. Your machine runs the automation. The automation logic — cron jobs, agents, CI/CD steps — executes against your cloud providers directly, using the same credential files (~/.aws/credentials, ~/.kube/config) that your local terminal uses.

The question is not "local or automated" — it is "who controls the execution environment?"

For more on the local-first philosophy and what it means architecturally, see the local-first AI DevOps overview.

---

Why Local-First Automation Is Safer Than Hosted Automation

Hosted automation platforms trade convenience for control surface. When a vendor's infrastructure holds your cloud credentials and runs changes automatically:

• A breach of the vendor's platform is a breach of your cloud environment
• Changes can execute without your real-time awareness
• Audit logs are on the vendor's infrastructure, not yours
• Runaway automation — agent scaling down a critical pod, misconfigured cron applying a destructive change — has no hard stop at the execution layer

Local-first automation inverts each of these:

Credentials stay local. Your AWS keys, kubeconfig, and provider tokens never leave your machine. There is no vendor-side credential store to breach.

Execution runs on your machine. Cron jobs, GitHub Actions steps, and MCP agent calls all execute from your local environment or CI runner. The cloud provider sees API calls from your IP, your keys, your audit identity.

Audit trail is yours. Every operation logged locally. You control retention, format, and access.

Blast radius is bounded by design. The approval gate model (covered below) means write operations cannot execute without explicit authorization — not because the vendor decided to add a confirmation step, but because the architecture requires it.

If you are moving fast with AI-assisted development — the vibe coding to production pattern — this is the safety layer that keeps fast shipping from becoming fast breaking.

---

Pattern 1: Scheduled CLI Queries with Cron

The Clanker CLI (github.com/bgdnvk/clanker, MIT license) is a Go binary that runs clanker ask queries against your infrastructure from any shell context. Install it with:

brew tap clankercloud/tap && brew install clanker

Because clanker ask is a standard CLI command, it composes with any Unix scheduling or automation primitive. Cron is the simplest pattern:

# Daily cost report — Monday through Friday at 8am
0 8 * * 1-5 clanker ask "show me top 10 cost increases this week" >> /tmp/cost-report.txt

# Post-deploy health check — run immediately after any deployment script
clanker ask "show me pod status in namespace production" --output json > /tmp/deploy-check.json

# Weekly security scan — Sunday at 2am
0 2 * * 0 clanker ask "scan production for any new public endpoints or permission changes"

Each of these runs with the credentials on the machine where the cron executes. The output is plain text or structured JSON. The queries read live state from your cloud providers — no cached data, no proxy layer.

The --output json flag makes clanker ask composable with jq for downstream processing:

# Tag non-compliance report
clanker ask "list resources with no tags in us-east-1" --output json | \
  jq '.[] | select(.cost > 10)'

This is local-first infra automation 2026 in its simplest form: scheduled, credential-safe, composable.

---

Pattern 2: MCP-Driven Agent Automation

The Clanker MCP server turns the desktop app into a structured local endpoint that any MCP-compatible agent can query. Start it with:

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

This exposes three tools: clanker_version, clanker_route_question, and clanker_run_command. Agents call these tools to get live infrastructure context without holding cloud credentials themselves.

The reference pattern here is OpenClaw's HEARTBEAT.md — a markdown file that OpenClaw (68K GitHub stars, MIT license) processes every 30 minutes as a continuous health-check and task-management loop:

# 1. Start the MCP workspace
clanker mcp --transport http --listen 127.0.0.1:39393

# 2. Register Clanker Cloud with OpenClaw
openclaw mcp set clanker-cloud --url http://127.0.0.1:39393

# 3. OpenClaw runs HEARTBEAT.md every 30 minutes
# Each cycle calls clanker_route_question for each check:
# "are all production pods healthy?"
# "any cost anomalies since last check?"
# "any new public endpoints detected?"

The agent makes decisions based on live data — not static configuration, not cached state. When OpenClaw detects a problem, it creates a task. When the task is a read operation (generate a cost report, surface a degraded service), it completes autonomously. When the task requires a change, it surfaces a plan for operator review.

Hermes (hermes3:70b via Ollama, MIT license) follows the same pattern. So does Claude Code and any other MCP-compatible agent — the protocol is standard. See For AI Agents for integration details and the Clanker Cloud docs for MCP configuration.

The key property: agents get live infrastructure context without touching your credentials. The MCP server mediates all provider access. The credential chain stays local.

---

Pattern 3: Maker Mode — Plan, Review, Apply

The third pattern handles write operations. This is where local-first automation diverges most sharply from hosted automation.

Maker Mode is the explicit approval gate for all infrastructure changes. It is not a confirmation dialog added for UX — it is an architectural constraint. No change executes without the --maker flag, and no change applies without --apply or explicit operator approval.

The workflow:

# Step 1: Agent or operator generates a scale-down plan
clanker ask "generate a plan to scale billing-worker from 4 to 2 replicas"

Clanker returns a reviewed plan before touching anything:

PLAN: Scale billing-worker from 4 → 2 replicas
Resources affected: billing-worker deployment (namespace: production)
Current state: 4 replicas, CPU avg 3%, memory avg 12%
Estimated cost change: -$62/month
Risk: LOW — idle workload, no downstream dependencies
Approve? [yes/no]

The plan shows current state, projected impact, cost delta, and risk level. You see the blast radius before the change runs. This is the same philosophy as terraform plan before terraform apply — a decade-old practice that AI infrastructure tools should follow but often do not.

# Step 2: Operator reviews and approves, then applies
clanker ask "scale billing-worker to 2 replicas" --maker --apply

For agent-driven automation, the pattern is: agent generates the plan autonomously, surfaces it for operator review, operator approves, maker mode executes. The agent handles the research and planning work; the operator retains control over execution.

This is the model the Deep Research feature follows for infrastructure-wide analysis — scan everything, surface findings with severity grades, let the operator decide what to act on.

---

CI/CD Integration with the Clanker CLI

GitHub Actions and other CI/CD pipelines are automation contexts that benefit from live infrastructure queries. Post-deploy health checks and pre-deploy cost estimates are common patterns:

# GitHub Actions: post-deploy health check
- name: Post-deploy health check
  run: |
    clanker ask "are all pods healthy in namespace production?" --output json | \
    jq 'if .healthy == false then error("Unhealthy pods detected") else . end'

# GitHub Actions: pre-deploy cost estimate
- name: Pre-deploy cost estimate
  run: clanker ask "estimate monthly cost change for deploying 2 additional checkout-api pods"

The CI runner uses whatever credentials are configured in the pipeline environment — the same ~/.aws/credentials or KUBECONFIG that your standard kubectl or AWS CLI steps use. No new credential surface, no vendor-side access.

This integrates naturally with the AI DevOps for teams workflow: CI pipelines handle deployment; Clanker CLI handles the infra-aware checks that need live cluster state.

---

The Approval Gate Model and Why It Matters

The approval gate model is not a limitation. It is blast radius control.

Every infrastructure automation failure has the same root cause: a change executed without the operator understanding its full impact. The billing-worker that looks idle but only processes jobs at 2am. The pod flagged for scale-down that is actually the only replica handling a low-traffic but critical internal API. The security rule that looks redundant but is blocking a known attack pattern.

Automation that reads and reports can run continuously and autonomously — cron jobs, HEARTBEAT.md cycles, CI checks. These carry no write risk. Automation that changes infrastructure must pass through an explicit gate.

In Clanker Cloud, this is hard-coded:

• Read operations (queries, health checks, cost reports): instant, no approval required
• Write operations (scaling, configuration changes, resource creation): always require --maker flag and explicit approval

The --apply flag in automation pipelines allows pre-approved patterns to execute in CI without interactive confirmation — but the operator has explicitly configured those patterns and understands their scope.

No vendor can run a change in your environment without going through this gate. The gate is yours, not theirs.

---

Roadmap: Cybersecurity Agents

The continuous monitoring case makes the local-first advantage most concrete.

Clanker Cloud's roadmap includes Cybersecurity Agents: "Sleep at night after vibe coding all day. Autonomous security agents that continuously scan for misconfigurations, exposed endpoints, and drift before attackers do."

Continuous security scanning is a natural fit for the local-first automation model. An agent running every 30 minutes via HEARTBEAT.md or cron, calling clanker_route_question for each check, surfaces issues before attackers find them — without any security-sensitive infrastructure data leaving your environment.

The alternative — a hosted security scanning service that pulls your cloud credentials and runs continuous analysis on the vendor's infrastructure — creates exactly the attack surface the scanning is meant to detect.

---

BYOK for Automation: Free Continuous Monitoring with Local Models

AI infrastructure automation BYOK is what makes continuous monitoring economically viable. Not every infrastructure query needs a frontier model.

Routine health checks and cost queries — the kind that run on a cron schedule or in every CI job — work well with local models:

• Gemma 4 via Ollama (gemma4:31b, gemma4:26b, gemma4:e4b): fast, free, runs entirely on your machine. Zero cost per query.
• Hermes 3 via Ollama (hermes3:70b, hermes3:8b, MIT license): strong for agentic tool-use patterns, well-suited for the MCP automation workflows above.

Escalate to frontier models for complex analysis:

• Claude Opus 4.6 or GPT-5.4 Thinking for incident root cause investigation that requires deep multi-step reasoning
• Gemini 3.1 Pro for structured cost data analysis across multiple accounts

With BYOK, you pay AI providers directly at their listed rates — no token markup, no opaque bundled AI costs. A continuous monitoring loop using Gemma 4 locally costs nothing per query. The same loop using a hosted AI DevOps platform at $0.10/query at 100 checks/day costs $300/month.

See your account settings to configure BYOK keys and the FAQ for model selection guidance.

---

FAQ

What is local-first infrastructure automation?

Local-first infrastructure automation means automated operations — cron jobs, agent loops, CI/CD steps — run with credentials that stay on your machine or CI runner. Cloud providers receive API calls from your execution environment, not a vendor's cloud. The automation logic runs locally; the vendor never holds your credentials or executes changes on your behalf.

Is Maker Mode compatible with fully automated pipelines?

Yes. The --maker --apply flags allow pre-configured patterns to execute in CI/CD pipelines without interactive approval. The distinction is between read operations (always autonomous) and write operations (require --maker plus either interactive approval or --apply in pre-authorized pipeline contexts). The gate is architectural — you define which pipelines are authorized to apply.

What local models work for continuous monitoring automation?

Gemma 4 via Ollama (gemma4:26b or gemma4:e4b for lower resource usage) handles routine health checks and cost queries with no per-query cost. Hermes 3 (hermes3:8b or hermes3:70b) is well-suited for MCP-driven agent loops due to its strong tool-use performance. Both run entirely on your machine with zero egress.

How does MCP-driven agent automation differ from the cron CLI pattern?

Cron-based CLI automation is scheduled and stateless — each job runs independently, queries infra state, and writes output. MCP-driven automation is event-driven and context-aware — an agent like OpenClaw maintains state across its HEARTBEAT.md cycles, correlates findings across checks, and can escalate from monitoring to plan generation to approval surfacing within a single autonomous loop. Both patterns use the same local credential model.

---

Get Started

Infrastructure automation should not require handing your credentials to a vendor. The Clanker Cloud demo shows the query and Maker Mode workflow in a live environment. The docs cover CLI setup, MCP configuration, and BYOK key management.

Download the desktop app at clankercloud.ai/account — free beta, one-minute setup, BYOK for AI model costs. The open-source CLI (brew tap clankercloud/tap && brew install clanker) is available immediately for cron and CI/CD integration.

Local-first automation means you own the execution environment. The credentials, the approval gates, and the audit trail are yours.