DEV Community: Vijaya Rajeev Bollu

I Built an MCP Server That Lets Claude Control My Kubernetes Cluster

Vijaya Rajeev Bollu — Thu, 09 Apr 2026 13:52:04 +0000

Why I Built This

Every DevOps incident I've dealt with follows the same pattern.

Something breaks. I open five terminal tabs. I run kubectl, check the AWS console, tail Docker logs, and manually piece together what went wrong — all while the clock is ticking.

The tools all exist. They're just completely disconnected from each other.

I wanted one interface that could ask a question, reach into all of them simultaneously, and explain what it found. So I built an MCP server that gives Claude Desktop direct access to my real infrastructure.

How It Works

The server runs locally on my laptop. Claude Desktop launches it on startup and communicates over stdio (standard input/output).

When I type a question, Claude reads the 14 registered tool descriptions, decides which ones to call, and sends a JSON request to my server:

{"method": "call_tool", "params": {"name": "get_failing_pods", "arguments": {"namespace": "default"}}}

My server executes against real infrastructure and returns structured text. Claude synthesises everything into a plain English response.

The key thing: Claude never connects to AWS or Kubernetes directly. It only talks to my Python server. My server uses local credentials (~/.aws/credentials, ~/.kube/config) to reach the real systems.

14 tools across 4 categories:

Kubernetes: pod status, failing pods, logs, restart deployment, describe pod
AWS: cost report, EC2 instances, CloudWatch alarms, S3 buckets
Docker: list containers, container logs, restart container
Terraform: run plan, check state

Demo / Results

I typed: "Give me a health report of my infrastructure"

Claude called get_pod_status, get_aws_cost, get_cloudwatch_alarms, and list_containers simultaneously and returned a unified summary — Kubernetes pods, AWS costs, Docker containers, CloudWatch alarms — all in one response.

One pod was in CrashLoopBackOff with 14 restarts. I typed:

"Pull the logs from broken-app and tell me why it's crashing"

Claude diagnosed it instantly — busybox with no long-running process, exits immediately every time, Kubernetes keeps restarting it.

Before: 45 minutes of manual investigation across 5 tabs.
After: 10 seconds, one chat window.

What I Learned

1. The tool description is everything.
Claude picks tools based on their description, not their name. A vague description causes Claude to call the wrong tool or skip it entirely. My first version had get_failing_pods described as "Get pods". Claude never called it. I changed it to "List only pods in Failed, CrashLoopBackOff, OOMKilled, or Error state" and it worked perfectly every time. The description is the API contract between you and Claude.

2. Parallel tool calls are not guaranteed — they're emergent.
I didn't write any code to call tools in parallel. Claude decided to do that on its own when the question was broad enough ("health report"). For narrow questions ("which pods are failing?") Claude called only one tool. The parallelism comes from Claude's reasoning, not from your server. This means your tool descriptions need to be distinct enough that Claude can make that judgment call correctly.

3. Sync SDKs in an async server is the silent performance killer.
boto3, the Kubernetes Python client, and the Docker SDK are all blocking. If you call them directly inside an async MCP handler, you stall the entire event loop. Every tool call wraps the SDK call in asyncio.to_thread(). Without this, Claude would time out waiting for responses when multiple tools were called simultaneously.

4. Error handling scope matters more than you think.
My first version caught SDK import errors at module level. If boto3 failed to connect to AWS at startup, the entire server crashed — Kubernetes and Docker tools went down too. The fix: catch errors inside each tool call, not at import time. One broken service should never take down the whole server.

5. The MCP protocol is simpler than it looks.
There are really only two things you implement: list_tools() (return tool names + descriptions + input schema) and call_tool() (receive tool name + arguments, return text). Everything else is handled by the MCP SDK. Building a tool is 20 lines of Python.

Limitations

Single EC2 instance. The demo infrastructure runs on one t3.small. In a real multi-node Kubernetes cluster, the pod information would be spread across namespaces and nodes. The tools work against any kubeconfig — but the demo is scoped to what's in one cluster.

Read-heavy, not write-heavy. Most tools read state — pod status, AWS costs, Docker containers. The only write operation is restart_deployment. There's no tool to edit a deployment YAML, push a config change, or create resources. Giving Claude write access to production infrastructure is a separate (and more serious) conversation about guardrails.

Claude restarts but can't fix root causes. If a pod is in CrashLoopBackOff because of a bad container image, Claude can restart it — but it'll crash again immediately. Claude diagnosed the issue correctly and warned me, but the actual fix (updating the deployment YAML and pushing a correct image) is outside the scope of the tools I gave it. The tools match what I was comfortable giving an AI access to.

No authentication on the MCP server. The server runs locally over stdio — there's no network exposure. But if you ever expose this over a network (e.g., run the server on EC2 and connect Claude Desktop remotely), you'd need to add authentication. Don't do that without thinking it through.

AWS credentials are local. The server uses whatever credentials are in ~/.aws/credentials. If you're running this on a shared machine, those credentials are accessible to anything running as your user. Use IAM roles with minimal permissions scoped to read-only for Cost Explorer, EC2, CloudWatch, and S3.

Try It

GitHub: [https://github.com/ThinkWithOps/ai-devops-systems-lab.git]
Demo: [https://youtu.be/2XsNcKSa28s]

git clone https://github.com/ThinkWithOps/ai-devops-systems-lab.git
cd 03-ai-devops-mcp-server
pip install -r requirements.txt

# Test with mock data — no real infra needed
KUBE_MOCK_MODE=true python -m pytest tests/ -v

Add the MCP server to your Claude Desktop config and restart. Full setup guide in the README.

This is Project 03 of the ThinkWithOps AI + DevOps series

What would you control first if Claude had access to your infrastructure? Drop it in the comments.

# I Built an AI That Understands Any GitHub Repo Using LangChain and ChromaDB

Vijaya Rajeev Bollu — Wed, 01 Apr 2026 16:54:53 +0000

Why I Built This

Every time I join a new codebase, the first few days are the same: open the repo, stare at folders, try to figure out which service does what, read half a file, get interrupted, lose context, start over.

GitHub's built-in search is keyword-only. ChatGPT has never seen your repo. Teammates are busy. Documentation is either missing or out of date.

I wanted a tool that could answer "how does checkout work?" from the actual code — not from training data, not from docs, but from the real source files.

So I built one.

How It Works

The system is built around a RAG (Retrieval-Augmented Generation) pipeline. The idea: instead of asking an LLM to answer from memory, you first retrieve the most relevant code chunks, then ask the LLM to answer using only those chunks.

Ingest flow:

Clone the GitHub repo locally
Walk every file and split into overlapping chunks (~500 tokens, 50-token overlap)
Convert each chunk to a vector embedding using all-MiniLM-L6-v2 (Sentence Transformers — local, free)
Store embeddings + metadata in ChromaDB

Query flow:

Embed the user's question with the same model
ChromaDB cosine similarity search → top-5 most relevant chunks
Inject chunks into a LangChain prompt
LLM generates an answer with source file citations

The frontend is a Next.js split-pane layout — file tree on the left, chat on the right. The ingest endpoint streams progress via Server-Sent Events so the user sees live updates instead of a spinner.

# LangChain RAG chain (simplified)
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True
)
result = qa_chain({"query": question})

The LLM only ever sees 5 chunks — not the whole repo. That keeps answers fast and grounded.

Demo / Results

I indexed the ShopFlow ecommerce demo app — ~847 files across 12 services.

Input: "How does the checkout flow work?"

Output:

The checkout flow works as follows:
1. Cart validation — CartService checks inventory availability (src/services/cart.py:142)
2. Payment processing — PaymentService calls Stripe API with order total (src/services/payment.py:89)
3. Order creation — OrderService writes to PostgreSQL with status PENDING (src/models/order.py:67)
4. Inventory update — InventoryService decrements stock counts (src/services/inventory.py:203)

Index time: ~30 seconds. Answer latency: ~3 seconds. API cost: $0 (self-hosted on AWS EC2).

What Surprised Me

1. FastAPI path parameters break on slashes
Repo names like owner/repo contain a / — FastAPI treats it as a path separator and routes to the wrong endpoint. Fix: declare the parameter as {repo_name:path}. One character. Found it via a 404 in production after deployment.

2. TypeScript types drift silently from backend SSE events
The backend was emitting file, file_path, and indexed_at fields in the SSE stream that the frontend TypeScript interface didn't declare. No error in local dev — only failed during next build inside Docker. A shared OpenAPI-generated type contract would have caught this at development time.

3. Docker layer caching hides real code
After pushing a fix, the Docker build was still serving old code because it cached the COPY . . layer. Always run docker-compose build --no-cache when a fix isn't appearing after git pull.

4. Chunk overlap matters more than chunk size
I initially had no overlap between chunks. The AI would give incomplete answers for questions that spanned function boundaries — the relevant context was split across two chunks that were never returned together. Adding 50-token overlap fixed most of these cases.

Try It

git clone https://github.com/ThinkWithOps/ai-devops-systems-lab
cd projects/02-ai-github-repo-explainer
cp backend/.env.example backend/.env
# Add your GROQ_API_KEY or leave blank to use Ollama
docker-compose up -d

Open http://<your-ec2-ip>:3000, paste any public GitHub URL, and start asking questions.

🔗 GitHub: https://github.com/ThinkWithOps/ai-devops-systems-lab
📺 Full build walkthrough: https://youtu.be/a6376K9Lm00

This is Project 02 of a 30-project AI + DevOps series. Each project is a real deployed system — not a tutorial snippet.

What's the most confusing codebase you've ever had to onboard into? What would you have asked an AI first?

# I Built a DevOps Chatbot That Checks My Live App for Failures — Here's How It Works

Vijaya Rajeev Bollu — Tue, 31 Mar 2026 16:50:21 +0000

Why I Built This

Every DevOps engineer has had the 2am moment. Something is broken. You don't know what. You SSH in, check logs, Google the error, open five tabs, still nothing clear. Thirty minutes later you find it — a config flag someone changed, a slow query, a dependency timing out.

I wanted to ask an AI instead. Not a generic ChatGPT that gives you textbook answers, but an AI connected to my actual running system that can check what's broken right now.

So I built the AI DevOps Copilot — Project 01 of my 30-project AI + DevOps YouTube series.

How It Works

The system has four layers:

1. LangChain agent (the brain)
Uses create_tool_calling_agent with Llama 3.1 via Groq. When you ask a question, the agent decides whether to answer from knowledge or call a tool. General DevOps questions → instant answer. Questions about the live app → tool call.

2. ChromaDB RAG (the knowledge base)
Nine runbook documents embedded into a vector database — Docker troubleshooting, AWS debugging, Kubernetes, Terraform, Linux performance, security, and more. The agent searches these for context when answering general questions.

3. Tool layer (the live connection)
Four tools: restaurant_monitor (hits the live restaurant app API), log_search (searches application logs), github_search (searches repos), and devops_docs (searches the runbook vector store).

4. FastAPI + SSE streaming (the interface)
The agent runs in a thread executor, streaming tokens back through an asyncio Queue with a sentinel pattern. The Next.js frontend connects via Server-Sent Events and renders each token as it arrives.

Data flow:

User question → FastAPI → LangChain agent → tool call or RAG search → streamed response → Next.js UI

Demo / Results

I deployed a chaos engineering demo app — a restaurant application with injectable failure modes. One failure mode: slow_menu, which adds a 2-second artificial delay to GET /api/menu.

Input: Menu page spinning, customers waiting. I ask the copilot: "What is wrong with the restaurant app right now?"

What happened:

Tool called: restaurant_monitor → action: failures
API response: slow_menu: ACTIVE (2s delay on /api/menu)

AI answer:
The slow_menu failure mode is currently ACTIVE.
This injects a 2-second delay into the Menu API.

Fix:
1. Operator dashboard → Failures → Disable slow_menu
2. Or: POST /api/admin/failures/slow_menu/disable
3. Verify: menu should load in <100ms

Time to diagnosis: ~8 seconds.

After disabling the toggle, the menu loaded instantly. The entire incident lifecycle — detection, diagnosis, fix, verification — took under 2 minutes.

What Surprised Me

1. create_react_agent kept hitting iteration limits.
I started with the ReAct text-parsing agent. Llama 3.1-8b kept failing the "Thought/Action/Observation" format, exhausting 10 iterations on simple questions. Switching to create_tool_calling_agent — which uses native LLM function calling — fixed this completely. The model knows how to call functions; it doesn't know how to produce exact ReAct formatting.

2. Tool call chunks were streaming to the user as garbage text.
on_llm_new_token in LangChain fires for every token — including internal tool call encodings like {"name": "restaurant_monitor", "arguments":. Fixed by checking chunk.tool_call_chunks and skipping those tokens. Without this, users see raw JSON blobs in the chat.

3. host.docker.internal doesn't resolve on EC2 Linux.
Added extra_hosts: - "host.docker.internal:host-gateway" to Docker Compose — still failed. Fixed by using the EC2 private IP directly: RESTAURANT_API_URL=http://172.31.90.69:8010 in the .env file. Simple, obvious in hindsight.

4. Groq free tier is 6,000 tokens per minute.
With llama-3.3-70b-versatile, three questions hit the limit. Switched to llama-3.1-8b-instant — much faster, lower token usage, still very capable for DevOps Q&A. For a demo or portfolio project, this is the right call.

Try It

📁 GitHub: https://github.com/ThinkWithOps/ai-devops-systems-lab/tree/main/projects/01-ai-devops-copilot

🎬 Video walkthrough: https://youtu.be/a50334Szt5g

# Clone and run locally
git clone https://github.com/ThinkWithOps/ai-devops-systems-lab
cd projects/01-ai-devops-copilot
cp backend/.env.example backend/.env
# Add your GROQ_API_KEY to .env
docker compose up -d

Open http://localhost:3000 — the copilot is running.

This is Project 01 of a 30-project series building AI + DevOps systems from scratch.

What's the most painful part of your on-call experience that you wish an AI could handle? Drop it in the comments — it might become Project 02.


`

---

How I Built an AI That Diagnoses GitHub Actions Failures Automatically

Vijaya Rajeev Bollu — Fri, 20 Mar 2026 19:17:38 +0000

The Problem

GitHub Actions failure logs are noisy. Finding the actual error in 500 lines of output takes time you don't have during an incident. You get a red X, click through multiple pages, scroll past runner setup noise and dependency install output, land on the real error — and then you have to figure out what it means and what to do about it. I was doing this loop manually too often, so I automated it.

What It Does

The tool fetches your repository's failed workflow runs via the GitHub API, extracts the relevant error sections from job logs, pulls in the workflow YAML for context, and sends everything to Ollama running locally. You get back a root cause, an explanation of why it happened, exact YAML changes to make, and steps to prevent it from happening again — in about 15 seconds.

Zero cloud costs. Your logs and code never leave your machine.

The 5 Failure Types It Handles

Dependency conflicts — version mismatches, packages missing from requirements.txt or package.json
Missing secrets — env vars referenced in the workflow but not configured in repository settings
Permission errors — GITHUB_TOKEN scope issues, OIDC misconfiguration, action not allowed
Docker build failures — base image not found, build context issues, registry auth failures
Flaky tests — identifies non-deterministic failures vs real bugs based on error patterns and exit codes

Architecture

The flow is straightforward: GitHub REST API → Python log parser → Ollama.

GitHub API (workflow runs + job logs + YAML)
         │
         ▼
  extract_error_from_logs()   ← keyword scan, context windows, dedup
         │
         ▼
  analyze_failure()           ← structured prompt to Ollama
         │
         ▼
  Terminal report             ← root cause + YAML changes + prevention

The log extraction step is where most of the work happens. Raw GitHub Actions logs are thousands of lines — runner diagnostics, apt output, pip install progress bars, none of which is useful. The parser scans for a list of error keywords (error:, failed, Traceback, exit code, permission denied, etc.), then captures 8 lines of context before and 12 after each hit, deduplicates overlapping windows, and caps the result at 1500 characters before sending to the AI.

def extract_error_from_logs(self, logs: str) -> str:
    lines = logs.split('\n')
    error_keywords = [
        'error:', 'failed', 'Traceback', 'fatal:',
        'command not found', 'permission denied',
        'exit code', 'returned non-zero'
    ]
    error_sections = []
    seen_lines = set()

    for i, line in enumerate(lines):
        if any(kw in line.lower() for kw in error_keywords):
            if i in seen_lines:
                continue
            start, end = max(0, i - 8), min(len(lines), i + 12)
            for j in range(start, end):
                seen_lines.add(j)
            error_sections.append('\n'.join(lines[start:end]))

    result = '\n\n'.join(error_sections)
    return result[:1500] + "\n... (truncated)" if len(result) > 1500 else result

The AI prompt includes the workflow name, failed job name, the extracted error section, and up to 1000 characters of the workflow YAML. That YAML context is what lets the AI suggest specific YAML fixes rather than generic advice.

prompt = f"""You are a GitHub Actions expert analyzing a failed CI/CD workflow.

Workflow: {workflow_name}
Failed Job: {job_name}

{workflow_context}

ERROR LOGS:
{limited_logs}

**ROOT CAUSE:** [each specific error, all of them]
**WHY THIS HAPPENED:** [plain language explanation]
**HOW TO FIX:** [numbered, actionable steps]
**YAML CHANGES:** [exact changes needed]
**PREVENTION:** [how to avoid this next time]
"""

The Most Useful Feature: Failure Classification

The thing that saves the most time isn't root cause identification — it's the flaky vs real distinction.

When a test fails with a non-deterministic error (race condition, network timeout, port already in use), re-running the workflow is the right call. When a test fails because you introduced a bug, re-running wastes 5 minutes and doesn't help. Before this tool, I'd often re-run first and only look at logs after the second failure confirmed it wasn't flaky. That's a 5-10 minute delay every time.

The AI picks this up from patterns in the error output. A ConnectionRefused or socket timeout alongside a test failure is a different signal than a clean AssertionError: expected 200, got 404. The prompt explicitly asks for this classification, and Llama 3.2 handles it reliably — it's the kind of pattern matching that LLMs are genuinely good at.

The accuracy isn't perfect (the README documents ~85%), but it's good enough that I check the classification before deciding whether to re-run or investigate.

Demo

Input — a failed workflow log containing:

Run pytest tests/
ERROR: No module named 'requests'
FAILED tests/test_api.py::test_health - ModuleNotFoundError
error: Process completed with exit code 1.

Output:

🔍 GITHUB ACTIONS FAILURE ANALYSIS
Repository: myname/myrepo | Workflow: CI Build | Failed Job: test

🤖 AI DIAGNOSIS:

**ROOT CAUSE:**
pytest is failing because the 'requests' library is not installed.
The test imports it, but it's not listed in requirements.txt, so
pip install -r requirements.txt doesn't include it.

**WHY THIS HAPPENED:**
The package works locally because you have it installed globally on your
machine. In the GitHub Actions runner, only packages in requirements.txt
get installed — nothing else is available.

**HOW TO FIX:**
1. Add 'requests' to requirements.txt: requests>=2.32.0
2. Commit and push — the workflow will pick it up automatically.
3. If requests is only needed for tests, add a requirements-dev.txt
   and install it separately in a dedicated workflow step.

**YAML CHANGES:**
No YAML changes needed. The fix is in requirements.txt.

**PREVENTION:**
Run your CI workflow locally with a clean virtualenv before pushing:
  python -m venv .venv && source .venv/bin/activate
  pip install -r requirements.txt
  pytest tests/

That took 14 seconds. The manual version of this (click to run page, scroll logs, identify error, Google it, figure out the fix) is 10-15 minutes minimum.

Try It

GitHub: https://github.com/ThinkWithOps/ai-devops-projects
Video: https://youtu.be/EwgdZ8KmBJg

# Prerequisites: Ollama running with llama3.2 pulled
git clone https://github.com/ThinkWithOps/ai-devops-projects
cd ai-devops-projects/04-ai-github-actions-healer
pip install -r requirements.txt

# Set your GitHub token (needs repo + workflow scopes)
export GITHUB_TOKEN="your_token_here"

# Run against your repo
python src/github_actions_healer.py --repo your-username/your-repo

# Save report to file
python src/github_actions_healer.py --repo owner/repo --output report.json

Project 4 in my AI+DevOps series — all tools run locally with Ollama, zero cloud AI costs. Project 3 was an AI AWS Cost Detective, Project 5 is an AI Terraform Code Generator. Links in my profile.

What GitHub Actions failure do you dread the most? For me it's the OIDC / GITHUB_TOKEN permission errors — the error message never tells you which specific permission is missing. The AI actually handles those surprisingly well. Drop yours in the comments.

# I Built a Local AI Terraform Generator and Tested It By Actually Deploying to AWS — Here Are the Results

Vijaya Rajeev Bollu — Fri, 13 Mar 2026 15:29:11 +0000

The Idea

Every time I needed a new AWS resource, I'd spend 20 minutes reading Terraform docs just to get the syntax right for something I'd done before. I wanted to type plain English and get working HCL back. But I also didn't want to just generate code — I wanted to know if it actually deploys. So I tested every resource by running terraform apply against a real AWS account.

How It Works

You describe infrastructure in plain English. The tool sends it to a local Llama 3.2 model via Ollama, which returns four Terraform files. Those files get saved to a generated/ folder, ready for terraform init and terraform apply.

Plain English → Python → Ollama (local) → Parse HCL → main.tf + variables.tf + outputs.tf + tfvars.example

The key piece is the prompt. Getting consistent, parseable HCL out of an LLM required a very specific structure:

prompt = f"""You are a Terraform/OpenTofu expert. Generate production-ready infrastructure code.

USER REQUEST:
{description}

PROVIDER: {provider}

CRITICAL:
- Generate ONLY valid Terraform/HCL code
- NO markdown formatting or code blocks
- Start each file with a comment showing the filename
- Separate files with: ### FILENAME ###

Format your response like this:

### main.tf ###
terraform {{
  required_version = ">= 1.0"
  required_providers {{
    {provider} = {{
      source  = "hashicorp/{provider}"
      version = "~> 5.0"
    }}
  }}
}}

[rest of main.tf code]

### variables.tf ###
[variables code]

### outputs.tf ###
[outputs code]

### terraform.tfvars.example ###
[example values]

Generate production-ready code now:"""

The ### FILENAME ### markers are what make the response parseable. The script splits on ###, reads the filename, grabs everything after it until the next marker, and writes that to disk. There's also a fallback parser for when the model goes off-script and wraps things in code blocks anyway.

Test Results: 10 Resources Tested

Resource	Generated	Validated	Deployed
EC2 instance	✅	✅	✅
S3 bucket	✅	✅	✅
IAM role	✅	✅	✅
VPC + subnets	✅	✅	✅
Security group	✅	✅	✅
RDS instance	✅	✅	✅
ALB	✅	✅	✅
Lambda	✅	✅	✅
ECS task	✅	⚠️ needed fix	✅
Complex module	✅	⚠️ needed fix	✅

8/10 deployed first try. 2/10 needed minor manual fixes.

The ECS task definition had an incorrect network_mode value for Fargate. The complex multi-resource module had a missing depends_on for the security group. Both were one-line fixes once terraform validate pointed at them.

What It's Good At vs Where It Struggles

Good at:

Standard single-resource configs (EC2, S3, IAM, RDS) — near-perfect every time
Wiring dependencies correctly between resources it knows well
Generating variables.tf with descriptions and sensible defaults
Adding tags and naming conventions without being asked

Struggles with:

Very new AWS resources where Llama's training data is thin
Complex modules with many interdependent resources — sometimes misses a depends_on
Provider version pinning — occasionally suggests a deprecated argument from an older AWS provider version
ECS/EKS specifics — these configs are dense and the model sometimes gets task definition fields wrong

Honest assessment: treat it like a junior engineer who's read all the Terraform docs but hasn't deployed much to production. Good first draft, always needs a review.

The Prompt Engineering That Made It Work

Three things made the difference between garbage output and deployable HCL:

1. Kill the markdown. LLMs love wrapping code in hcl blocks. That breaks the file parser completely. The explicit instruction NO markdown formatting or code blocks eliminated this.

2. Show the exact format in the prompt. Telling the model to use ### main.tf ### as a separator, and including the terraform {} block structure directly in the prompt, anchored the output format. Without this, every response looked slightly different.

3. Demand variables explicitly. Early versions hardcoded values like instance_type = "t3.micro" directly in main.tf. Adding Use variables for configurable values to the requirements section fixed this — now everything configurable lands in variables.tf with proper descriptions.

Why Local Matters for IaC Generation

Your Terraform descriptions contain your architecture. "Create a VPC with private subnets, an RDS cluster for our auth service, and an ECS task that pulls from our private ECR registry" — that's a roadmap of your production infrastructure. Sending that to a cloud API means it leaves your machine.

Running Ollama locally means the description, the generated code, and any sensitive context like account IDs or naming patterns stay on your machine. For anything touching production infrastructure, that's not optional.

Try It

GitHub: https://github.com/ThinkWithOps
Live deploy demo: https://youtu.be/nhhZqrCEhOA

git clone https://github.com/ThinkWithOps/ai-devops-projects
cd ai-devops-projects/05-ai-terraform-generator
pip install -r requirements.txt

# Generate code
python src/terraform_generator.py \
  --description "EC2 instance with S3 bucket for logs" \
  --provider aws

# Deploy it
cd generated/
cp terraform.tfvars.example terraform.tfvars
terraform init && terraform plan && terraform apply

Project 5 in my AI+DevOps series — all tools run locally with Ollama, zero cloud API costs.

What's your current Terraform workflow? I'm curious whether people are using Copilot for this, manually writing it, or something else entirely — drop it in the comments.

# I Built an AI Kubernetes Pod Debugger — Diagnoses CrashLoopBackOff, OOMKilled, and More in Seconds

Vijaya Rajeev Bollu — Fri, 13 Mar 2026 15:14:28 +0000

Why I Built This

K8s error messages are designed for cluster operators, not for the developer who just shipped a feature and now has a pod stuck in CrashLoopBackOff at 11pm. kubectl get pods tells you something is broken. It doesn't tell you why, and it definitely doesn't tell you what to do about it. I kept doing the same 4-command loop — get pods, describe pod, logs, Google the error — and thought there had to be a better way.

So I automated the loop and added an AI in the middle.

The 6 Failure Types It Handles

ImagePullBackOff — wrong image name, missing credentials, private registry issues
CrashLoopBackOff — app crash on startup, missing env vars, bad config
OOMKilled — container exceeding memory limits
Pending — insufficient cluster resources, node selector issues
Failed — job completion errors, config map missing
Init Container failures — init container exits non-zero

How It Works

The tool runs three kubectl commands in sequence, then hands everything to Ollama.

First, kubectl get pods -o json scans the namespace and flags any pod that isn't Running, isn't ready, or has restarts > 0. For each unhealthy pod, it grabs the last 50 lines of logs and the Events section from kubectl describe. Both get truncated before hitting the AI — logs capped at 2000 chars, events at 1000 — to stay within a reasonable context window.

Then everything goes into a structured prompt:

def analyze_pod_failure(self, pod: Dict, logs: str, events: str) -> str:
    logs_sample = logs[:2000] if logs else "No logs available"
    events_sample = events[:1000] if events else "No events available"

    prompt = f"""You are a Kubernetes expert helping debug pod failures.

Pod Information:
- Name: {pod['name']}
- Status: {pod['status']}
- Ready: {pod['ready']}
- Restart Count: {pod['restarts']}

Recent Logs (last 50 lines):
{logs_sample}

Recent Events:
{events_sample}

Provide a diagnosis in this format:

**ROOT CAUSE:**
[Explain in 1-2 sentences what's causing the pod to fail, using simple terms]

**WHY THIS HAPPENS:**
[Explain why this error occurs, use an analogy if helpful]

**HOW TO FIX:**
[Provide specific kubectl commands or YAML changes to fix the issue]
"""
    response = self.ask_ollama(prompt)
    return self._remove_repeated_suffix(response)

The _remove_repeated_suffix at the end strips duplicated content that Llama 3.2 sometimes generates — more on that below.

Demo: CrashLoopBackOff Diagnosis

Input — what the cluster shows:

$ kubectl get pods
NAME          READY   STATUS             RESTARTS   AGE
broken-pod    0/1     CrashLoopBackOff   4          3m

Logs show: panic: runtime error: invalid memory address or nil pointer dereference

Output from the AI:

🔍 KUBERNETES POD DEBUG REPORT
Pod: broken-pod | Status: CrashLoopBackOff | Restarts: 4

🤖 AI DIAGNOSIS:

**ROOT CAUSE:**
The application is crashing immediately on startup due to a nil pointer
dereference — it's trying to use a variable that was never initialized,
likely a missing environment variable or config value.

**WHY THIS HAPPENS:**
Think of it like a recipe that calls for eggs, but your fridge is empty.
The app tries to read a config value that doesn't exist, gets back nothing,
and then crashes when it tries to use it. Kubernetes keeps restarting it,
hoping it'll work — it won't until the missing config is there.

**HOW TO FIX:**
1. Check what env vars the container expects:
   kubectl describe pod broken-pod | grep -A 10 'Environment'
2. Add the missing values to your deployment YAML under 'env:'
3. Or create a ConfigMap and reference it:
   kubectl create configmap app-config --from-literal=KEY=value
4. Reapply: kubectl apply -f your-deployment.yaml

💡 SUGGESTED NEXT STEP:
   kubectl logs broken-pod --previous

That diagnosis took 12 seconds. The manual version of this took me 25 minutes the first time I hit a nil pointer crash in K8s.

What Surprised Me

kubectl logs silently fails on crashed containers. If a container has already exited, the default kubectl logs command returns nothing — no error, just empty output. The fix is the --previous flag, which fetches logs from the last terminated container. I found this out the hard way when the AI kept saying "No logs available" for CrashLoopBackOff pods. The code now tries normal logs first, then falls back automatically:

except subprocess.CalledProcessError:
    # Try to get previous logs if container already crashed
    result = subprocess.run(
        ["kubectl", "logs", pod_name, "-n", namespace,
         "--previous", f"--tail={tail}"],
        ...
    )

Llama 3.2 sometimes repeats its own output. Occasionally the model generates a full response and then starts over from the beginning, appending a duplicate. For a terminal tool this looks terrible. I had to write a suffix deduplication function that checks if the second half of the response is a repeat of any trailing segment of the first half, and strips it. Not something I expected to need when I started this project.

Minikube hangs silently when the base image is cached. On Windows with Docker Desktop, minikube start can freeze indefinitely trying to pull an image that's already on disk. The fix — minikube start --base-image=gcr.io/k8s-minikube/kicbase:v0.0.49 — forces it to use the local cache. This isn't documented prominently and cost me an hour of debugging a debugging tool.

Try It

GitHub: https://github.com/ThinkWithOps
Demo video: https://youtu.be/LFF-987-uhA

# Prerequisites: Minikube running, Ollama + llama3.2 pulled
git clone https://github.com/ThinkWithOps/ai-devops-projects
cd ai-devops-projects/02-ai-k8s-debugger
pip install -r requirements.txt

# Deploy a broken pod to test with
kubectl apply -f demo/broken-pod.yaml

# Run the debugger
python src/k8s_debugger.py

# Or target a specific pod
python src/k8s_debugger.py --pod broken-pod

Project 2 in my AI+DevOps series — all tools run locally with Ollama, zero cloud costs. Project 1 was an AI Docker vulnerability scanner, Project 3 is an AI AWS Cost Detective. Links in my profile.

What K8s error do you dread seeing the most? For me it's still Pending with node affinity issues — the AI actually handles that one better than I expected. Drop yours in the comments.

I Built an AI AWS Cost Detective That Found $900/Year in Waste — Here's How

Vijaya Rajeev Bollu — Sun, 08 Mar 2026 15:22:25 +0000

The Problem

AWS Cost Explorer shows you data. It doesn't tell you what to do about it. I was paying $127/month and knew I was wasting money but couldn't quickly identify where.

What the AI Found

Running the tool against my own account uncovered:

EC2 Waste: A t3.small running 24/7 — used maybe 2 hours a day for testing. That's $45/month for 22 hours of idle compute every single day.
EBS Volumes: Three EBS volumes still attached to stopped instances. No data being written, no instance using them. $8/month evaporating for nothing.
NAT Gateway: A NAT Gateway from an old VPC setup I'd completely forgotten. Nothing routing through it. $12/month for a network door with no traffic.
Snapshots: Automated snapshots from an RDS instance I deleted months ago. The database was gone but the snapshots kept accumulating — $10/month.

Total: $75/month = $900/year

How It Works

The tool chains three things together: boto3 fetches your AWS costs and resource counts, Python shapes the data, and Ollama (local Llama 3.2) turns it into actionable recommendations.

AWS Cost Explorer API  →  Python (boto3)  →  Ollama  →  Structured report
     (billing data)        (resource counts)   (local LLM)

First it pulls 30 days of costs grouped by service, then counts your live resources (EC2 instances, EBS volumes, S3 buckets, RDS databases, Lambda functions). Both datasets go into the AI prompt together — because cost numbers without resource context give you vague answers.

def analyze_costs(self, services: List[Dict], resources: Dict) -> str:
    total_cost = sum(s['cost'] for s in services)
    top_services = services[:5]

    services_text = "\n".join([
        f"- {s['service']}: ${s['cost']:.2f}"
        for s in top_services
    ])

    resources_text = "\n".join([
        f"- {k.replace('_', ' ').title()}: {v}"
        for k, v in resources.items()
    ])

    prompt = f"""You are an AWS cost optimization expert.

COST SUMMARY (Last 30 Days):
Total Cost: ${total_cost:.2f}

Top Services by Cost:
{services_text}

Resources Currently Running:
{resources_text}

Provide recommendations in this format:

**COST ANALYSIS:**
**HIDDEN COSTS DETECTED:**
**OPTIMIZATION RECOMMENDATIONS:**
**ESTIMATED SAVINGS:**
"""
    return self.ask_ollama(prompt)

The structured output format in the prompt is what makes the response actually parseable and useful — not just a wall of text.

Setting Up Read-Only AWS Access

This is important — the tool only needs read permissions. Here's the minimal IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ce:GetCostAndUsage",
      "ec2:Describe*",
      "s3:ListAllMyBuckets",
      "rds:Describe*",
      "lambda:List*"
    ],
    "Resource": "*"
  }]
}

Create a dedicated IAM user (cost-detective), attach this policy, generate an access key, and run aws configure. The tool never writes anything to your account — worst case it reads data you didn't expect it to.

What Surprised Me

Two things I didn't expect:

The Cost Explorer API is completely free. I assumed querying billing data would itself have a cost. It doesn't. Zero charges for API calls to Cost Explorer.

AWS returns cost values as Python Decimal, not float. This one is a quiet killer — json.dumps() will crash when you try to save a report because the standard JSON encoder doesn't handle Decimal. Had to write a custom encoder:

class DecimalEncoder(json.JSONEncoder):
    def default(self, obj):
        if isinstance(obj, Decimal):
            return float(obj)
        return super(DecimalEncoder, self).default(obj)

No error message tells you why it failed. You just get a TypeError and have to figure out where the Decimal came from.

Limitations

Being honest about what this doesn't handle well:

Data is 24–48 hours delayed. Cost Explorer isn't real-time. If you just spun up a resource today, it won't show up yet.
Single region by default. Resource counts only scan us-east-1. Multi-region setups need extra config.
Doesn't catch everything. Very small charges (under $0.01) are filtered out. Some hidden costs — like cross-AZ data transfer — aren't obvious from the Cost Explorer groupings.
AI recommendations need verification. The tool identifies patterns and suggests actions, but you should always sanity-check before terminating anything. I almost deleted an EBS volume that was actually still in use by a snapshot restore.

Try It

GitHub: https://github.com/ThinkWithOps
Demo video: https://youtu.be/rg1Vnjjt9xk

git clone https://github.com/ThinkWithOps/ai-devops-projects
cd ai-devops-projects/03-ai-aws-cost-detective
pip install -r requirements.txt
python src/aws_cost_detective.py

# Save report to JSON
python src/aws_cost_detective.py --output report.json

Project 3 in my AI+DevOps series. Project 4 is an AI GitHub Actions Auto-Healer — it reads failing CI logs and suggests fixes. Link in my profile.

What's the most unexpected thing hiding in your AWS bill? I'd have never noticed that NAT Gateway without the tool surfacing it. Drop yours in the comments.

How I Built a Local AI Docker Vulnerability Scanner (No API Costs, No Cloud)

Vijaya Rajeev Bollu — Fri, 06 Mar 2026 19:04:47 +0000

How I Built a Local AI Docker Vulnerability Scanner (No API Costs, No Cloud)

The Problem with Trivy Output

Running Trivy gives you a wall of CVE numbers. Most developers copy-paste them into Google and spend 20 minutes figuring out if each one actually matters for their use case.

I built a tool that fixes this.

What I Built

A local AI wrapper around Trivy that:

Scans any Docker image
Takes the raw CVE output
Feeds it to Ollama (local LLM — no API costs)
Returns plain English explanations + specific fix recommendations

The Interesting Finding

nginx:1.27-alpine: 14 vulnerabilities
nginx:alpine:       3 vulnerabilities

Same base image family — pinned version had 4.5x more CVEs. The AI caught this pattern and recommended variants to compare automatically.

Tech Stack

Python 3.11
Trivy (vulnerability scanner)
Ollama + Llama 3.2 (local LLM)
Zero cloud dependencies

How It Works (Code Walkthrough)

The scanner has three moving parts: Trivy does the heavy lifting of CVE detection, Python orchestrates everything, and Ollama explains what it all means.

Step 1 — Scan with Trivy and parse the JSON:

def scan_image(self, image_name: str) -> Optional[Dict]:
    result = subprocess.run(
        ["trivy", "image", "--format", "json", "--severity", "HIGH,CRITICAL", image_name],
        capture_output=True, text=True, check=True
    )
    return json.loads(result.stdout)

def extract_vulnerabilities(self, scan_data: Dict) -> List[Dict]:
    vulnerabilities = []
    seen_vulns = set()  # deduplicate by CVE ID

    for result in scan_data.get("Results", []):
        for vuln in result.get("Vulnerabilities", []):
            vuln_id = vuln.get("VulnerabilityID", "N/A")
            if vuln_id in seen_vulns:
                continue
            seen_vulns.add(vuln_id)
            vulnerabilities.append({
                "id": vuln_id,
                "package": vuln.get("PkgName", "N/A"),
                "severity": vuln.get("Severity", "N/A"),
                "fixed_version": vuln.get("FixedVersion", "Not available")
            })
    return vulnerabilities

Step 2 — Send each CVE to Ollama for a plain English explanation:

def explain_vulnerability(self, vuln: Dict) -> str:
    prompt = f"""You are a security expert explaining vulnerabilities to developers.

Vulnerability Details:
- ID: {vuln['id']}
- Package: {vuln['package']} (version {vuln['version']})
- Severity: {vuln['severity']}
- Title: {vuln['title']}

Explain in 2-3 sentences:
1. What this vulnerability means in simple terms
2. Why it's dangerous
3. How to fix it (fixed version: {vuln['fixed_version']})

Keep it concise and actionable. Use analogies if helpful."""

    response = requests.post(
        f"{self.ollama_host}/api/generate",
        json={"model": "llama3.2", "prompt": prompt, "stream": False},
        timeout=60
    )
    return response.json().get("response", "")

Step 3 — Generate an overall summary with structured output:

The summary prompt forces Ollama into a key-value format so we can parse it reliably and build a comparison command on the fly — more on that in the next section.

The Trickiest Part

Getting Ollama to return structured output consistently was harder than expected. Free-form responses were great for individual CVE explanations, but the security summary needed to be parseable — I needed specific fields like SECURITY_POSTURE and VARIANTS_TO_TEST to programmatically build the comparison command.

The solution was strict prompt formatting: I told the model to respond in KEY: value pairs and gave it an explicit example. Then I split each line on : and built a dict. When parsing failed I fell back to a hardcoded comparison command. The other challenge was Llama 3.2 sometimes repeating itself — I solved that with a deduplication pass that checks for repeated section headers (**1., **Vulnerability, etc.) and drops them before printing.

Results

Before — Raw Trivy output:

CVE-2024-1234 (CRITICAL)
Package: openssl 1.1.1k
Description: Use-after-free in X509_verify_cert function

😕 "What does this mean? Do I need to care about this?"

After — AI-enhanced output:

🤖 AI Explanation:
This is like leaving your house key under the doormat.
OpenSSL handles your HTTPS connections, and this bug lets
attackers potentially decrypt traffic. Fix: update your
Dockerfile base image to get openssl 1.1.1w or later.

✅ "Got it, I'll update the base image today."

Metric	Value
Avg scan time	15–30 seconds
AI explanation per CVE	~3 seconds
Cloud API cost	$0
Images tested	50+ (nginx, node, python, ubuntu)

Manual CVE triage that used to take 20+ minutes per image now takes under a minute for the top 5 vulnerabilities.

Try It Yourself

GitHub: https://github.com/ThinkWithOps/ai-devops-projects/tree/main/01-ai-docker-scanner
Full demo video: https://youtu.be/J6fmU6t9jUU

# Prerequisites: Docker, Trivy, Ollama + llama3.2 pulled
git clone 
cd 01-ai-docker-scanner
pip install -r requirements.txt
python src/docker_scanner.py nginx:latest

What's Next

This is Project 1 in my AI+DevOps series. Next I built an AI K8s Pod Debugger — link in my profile.