VibeOps

I work with Claude Code every day. It sits inside VS Code, it reads my codebase, it writes infrastructure, it reviews pull requests. At some point I stopped thinking of it as a tool and started thinking of it as a colleague — one that happens to be extremely fast and never complains about on-call shifts.

But there was a problem. Every morning, I had to re-introduce myself

The context file trap

Like most people, I started with a CLAUDE.md file. Architecture decisions, naming conventions, client environments, internal runbooks. Everything Claude needed to know about the project, packed into a single markdown file loaded at the start of every session.

But….

The first issue was token consumption. That file grew. Every message I sent, Claude was re-reading the entire document — even when I was asking something completely unrelated to 80% of its content. On long sessions, the input token count was quietly exploding in the background. Not a disaster, but a slow and unnecessary cost.

The second issue was more serious: data residency.

I work with client documentation. Internal knowledge bases. Onboarding materials that contain infrastructure details, environment configurations, sometimes personal data. Every time I loaded that context file, the entire thing traveled to Anthropic’s servers — raw, unfiltered, regardless of what I was actually asking.

For a DevOps engineer working with European clients, that is not a theoretical concern. That is a GDPR problem.

The real issue: a brain without long-term memory

Here is what I realized: Claude Code is an extraordinarily capable reasoning engine. But it has no persistent memory. Every session starts from zero. The context window is its entire world — and I was filling it manually, by hand, with a flat file.

That is not how memory should work. When you ask a colleague “what port does the staging database run on?”, they do not re-read the entire project wiki before answering. They retrieve exactly what is relevant. Instantly.

That is what a vector database does.

Enter Qdrant

Qdrant is an open-source vector database. Instead of storing text as text, it stores it as mathematical embeddings — numerical representations of meaning. When you query it, it does not search for exact keywords. It finds what is semantically close to your question.

Combined with Claude Code via MCP (Model Context Protocol), it becomes Claude’s long-term memory. The architecture is simple:

1. You index your documents once — architecture notes, runbooks, client environments, internal wikis
2. When Claude Code needs context, it queries Qdrant automatically via the MCP tool
3. Only the 3-5 most relevant chunks land in the context window — not the entire knowledge base

The token cost drops dramatically. And more importantly, sensitive documentation stays in your Qdrant instance, running locally on your machine, until the moment it is actually needed.

Setting it up

Qdrant runs in Docker. One file

services:
  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant
    restart: unless-stopped
    ports:
      - "6333:6333"
    volumes:
      - qdrant_data:/qdrant/storage
    environment:
      - QDRANT__SERVICE__API_KEY=your-secret-key
volumes:
  qdrant_data:

one command (in the folder when you put the above file)

docker compose up -d

and then register the MCP server in ~/.claude/settings.json:

{
   "mcpServers": {
     "qdrant": {
       "command": "uvx",
       "args": ["mcp-server-qdrant"],
       "env": {
         "QDRANT_URL": "http://localhost:6333",
         "QDRANT_API_KEY": "your-secret-key",
         "COLLECTION_NAME": "project-context"
       }
     }
   }
}

What actually changes

The difference is not just technical. It changes how you interact with Claude Code on a daily basis.

You stop managing context manually. You stop worrying about what is in the file and what is not. You stop sending your entire knowledge base to an external API every time you ask a question.

Claude Code becomes less of a tool you configure before each session and more of a system that simply knows your infrastructure — the same way a good engineer who has been on the team for six months just knows things.

The brain was always there. It just needed a place to store what it learns.

vibeops.one — infrastructure, automation, and the tools that actually work in production.