You know that moment when a tool becomes so powerful that the tooling around it becomes the bottleneck? That was me with Claude Code about three weeks ago.
Claude Code has gotten ridiculously good. I’m using it for client projects, my own infrastructure work, even for building out complex n8n workflows. But the more powerful it got, the more I hit the same wall: context management. How do I get the right knowledge to Claude fast? How do I expose tools reliably without manually copying documentation and code snippets every single time?
Claude and Anthropic figured it out with MCP (Model Context Protocol) servers. But here’s the thing—I wanted more than just running one instance. I wanted to run multiple Archon MCP servers for different clients, different projects, and see them all in real-time. Oh, and I wanted to do it without exposing a single inbound port on my server.
Here’s how a simple “let me self-host this repo” turned into a deep dive on Docker networking, Cloudflare Tunnels, and why zero-trust architecture isn’t just enterprise buzzword nonsense.
The Context Management Problem (And My Terrible Old Workflow)
Let me paint the picture of how bad my old workflow was:
Before Archon:
- Find documentation pages or codebases I need Claude to understand
- Manually copy the relevant pages
- Load them into a vector database (usually Supabase with pgvector)
- Query the vector store through n8n
- Feed the results back to Claude
- Repeat this entire process for every project context switch
This worked. Technically. But it was slow, manual, and error-prone. Every time a client asked me to work on their codebase, I’d spend 15-20 minutes setting up the context before I could even start the actual work.
What Archon Changed:
Archon has a built-in crawler and embedder that automatically:
- Crawls any site or codebase you point it at
- Generates embeddings
- Exposes an MCP server that Claude Code can query directly
- Provides real-time project and task tracking
Suddenly my context gathering went from 20 minutes of manual work to 30 seconds of automatic indexing. This was a 10x improvement in my actual workflow speed.
But there was a catch: I wanted to run multiple instances of this for different clients, and I wanted it secure. No exposed ports, no traditional firewall management, just pure zero-trust architecture.
The Initial Plan: “This Should Be Simple”
I found the Archon repository on GitHub and thought, “Great, I’ll just clone this, run docker-compose up, and I’m done.”
Classic developer optimism.
The Archon stack consists of three main services:
- Archon-Server: The backend logic
- Archon-UI: The web interface for managing projects
- Archon-MCP: The MCP server that Claude Code actually talks to
My goal was straightforward:
- Get these containers running on my Ubuntu server
- Make the MCP endpoint accessible to my local Claude Code CLI
- Do it without opening a single port on my firewall
- Be able to replicate this pattern for multiple client instances
The security constraint was non-negotiable. I’ve been down the road of exposed SSH ports and random port scanning attempts. For this project, I decided to learn how to do it right: zero-trust, zero exposed ports.
Reality Check #1: Docker Networks and the DNS Magic
First attempt: spun up the Archon stack with docker-compose. Services started fine. Tried to access the MCP endpoint from my local machine. Nothing. Complete silence.
This is where I learned about Docker’s user-defined bridge networks, and honestly, this is the part that changed how I think about container orchestration.
The Problem: The default Docker Compose networking isolates each stack. The Archon containers couldn’t talk to the Cloudflare Tunnel container I already had running in a separate stack (for my other services). And I sure as hell wasn’t going to expose the MCP port to the host machine.
The Solution: ai-net
I created a user-defined Docker bridge network called ai-net:
bash
docker network create ai-netThis became the private LAN for all my AI services. Any container attached to ai-net can communicate with any other container on that network, regardless of which docker-compose stack it lives in.
But here’s the magic part I didn’t initially appreciate: Docker’s embedded DNS.
When a container joins a user-defined bridge network, Docker automatically registers its container_name as a resolvable hostname within that network. This means my Cloudflare Tunnel container could be configured to forward traffic to http://Archon-MCP:8051, and Docker would resolve that name to the correct private IP automatically.
No hardcoded IPs. No complex service discovery. Just simple, reliable DNS resolution.
Reality Check #2: The Authentication Rabbit Hole
With the networking sorted, I thought I was home free. Configured the Cloudflare Tunnel, pointed it at the Archon-MCP container, and tried to connect with Claude Code.
Access denied.
This kicked off about three hours of researching Cloudflare Access policies and authentication flows. My first instinct was to use identity-based authentication—the theoretically “right” way to do this.
The Identity-Based Dream:
Cloudflare has this nice cloudflared login flow where you authenticate once in a browser, it generates a JWT token on your machine, and that token gets attached to all future requests. Perfect for zero-trust, right?
The Reality:
Claude Code doesn’t support this authentication flow. It doesn’t know how to find or attach the JWT token. There’s a workaround involving running a persistent cloudflared access tcp proxy locally that attaches the token for you, but that felt like over-engineering.
I needed something that worked with Claude Code’s actual capabilities, not its theoretical ones.
The Pragmatic Solution: IP-Based Bypass Policy
I ended up implementing a network-centric approach:
- Created a Cloudflare Access Bypass policy based on IP ranges
- Whitelisted my home and office public IPs
- Configured it as default-deny for everything else
This means:
- Requests from my known IPs skip authentication entirely (they’re trusted)
- Requests from unknown IPs get a 403 Forbidden at the Cloudflare edge
- No login page, no attack surface, just a hard deny
Is it less flexible than identity-based auth? Sure. But it’s more secure for my use case because:
- The tunnel itself is encrypted and outbound-only
- The Access policy acts as a pre-emptive firewall at the Cloudflare edge
- Default-deny posture means anything not explicitly allowed is dropped
- No additional client-side configuration required
Sometimes the pragmatic solution is the right solution, even if it’s not the “textbook” solution.
Reality Check #3: The Two-Stack Architecture
Initially, I tried to cram everything into one massive docker-compose file. This worked, but it was messy and hard to manage.
The breakthrough was splitting services into two logical stacks:
Infrastructure Stack (open-webui):
cloudflared: The Cloudflare Tunnel container (ingress controller)ollama: Local LLM inference (for other projects)open-webui: Web UI for Ollama
Application Stack (archon):
Archon-Server: Backend logicArchon-UI: Web interfaceArchon-MCP: The MCP server
Both stacks connect to the shared ai-net network. This separation means:
- I can restart the Archon stack without affecting my tunnel
- I can add new application stacks easily
- Each stack has its own docker-compose.yml for clarity
- Services can still communicate across stack boundaries via the shared network
This modular approach makes it trivial to add new instances. Want an Archon stack for a different client? Just clone the docker-compose file, change the container names and ports (internally), and deploy.
Tracing the Traffic: How a Request Actually Flows
The final architecture is elegant enough that I want to walk through exactly how a request flows from my local Claude Code CLI to the Archon-MCP container:
- Client Request: I run
claude codeon my laptop. The CLI sends HTTPS tohttps://archon-mcp.logicweave.ai/mcp - Cloudflare Edge: The request hits the nearest Cloudflare data center. Public DNS resolves to Cloudflare’s network.
- Access Policy Evaluation: Before the request proceeds, Cloudflare Access checks: “Is this request’s source IP on the whitelist?” If yes, allow. If no, 403.
- Tunnel Transit: Authorized requests are sent down the encrypted tunnel to the
cloudflaredcontainer on my Ubuntu server. - Internal Routing: The
cloudflaredcontainer knows this hostname maps tohttp://Archon-MCP:8051. It forwards the request over theai-netnetwork. - Docker DNS: Docker resolves
Archon-MCPto the container’s private IP (something like172.18.0.5). - Container Processing: The Archon-MCP container receives the request on port 8051, processes it, and sends the response back along the same path.
The server itself? Still has zero exposed inbound ports. The firewall is locked down. Everything happens through the outbound tunnel connection.
What This Actually Means for My Workflow
The business impact of this setup is hard to overstate:
Before Archon:
- 15-20 minutes of manual context setup per project
- Constantly switching between documentation and code
- Copy-paste workflow that felt like caveman development
After Archon:
- 30 seconds to index a new codebase or documentation site
- Claude Code has instant access to the right context
- I can run multiple instances for different clients simultaneously
- Real-time visibility into what Claude is working on
The ROI:
If I’m saving 15 minutes per project context switch, and I switch contexts 5-10 times per day (because freelance life), that’s 75-150 minutes per day I’m getting back. Over a month, that’s 30+ hours of productive time.
For my Upwork clients, this means:
- Faster turnaround times
- More accurate implementations (Claude has the right context)
- Better documentation (I can quickly spin up context for any project)
What I Learned (That I Should Have Known)
Docker Networking Is a Programming Language
User-defined bridge networks with embedded DNS resolution completely changed how I think about container orchestration. This isn’t just “connect some containers”—it’s a proper Layer 2 networking model with service discovery built in.
Zero-Trust Isn’t Just for Enterprises
The Cloudflare Tunnel + Access policy combination is genuinely more secure than traditional port forwarding, and it’s not significantly harder to set up. The mindset shift from “which ports do I open?” to “how do I broker access?” is worth making.
Pragmatic Security Beats Theoretical Perfection
IP-based bypass isn’t as flexible as identity-based authentication, but it’s more secure for this specific use case and works with the actual capabilities of my tools. Don’t let perfect be the enemy of good (or in this case, better).
Modular Stacks Scale Better
Splitting infrastructure and application concerns across docker-compose stacks makes the entire system easier to reason about and replicate. This pattern will work for any new MCP server or AI service I want to add.
Claude Code + MCP Is the Future
This workflow feels like the future of AI-assisted development. The context management problem has been genuinely solved. I’m not feeding Claude chunks of documentation—I’m giving it access to queryable knowledge stores.
What’s Next: Multiple Instances and Real-Time Monitoring
Right now, I have one Archon instance running for my general development work. The next phase is spinning up client-specific instances:
- One instance per major client project
- Separate vector stores for each client’s codebase
- Real-time dashboards showing which projects Claude is actively working on
- Task-level visibility into what’s being built
The architecture I’ve built makes this trivial. Clone the docker-compose file, update container names, deploy. The ai-net network and Cloudflare Tunnel handle the rest.
I’m also exploring how this pattern extends to other MCP servers I want to run. The same zero-trust, multi-stack approach should work for any service that needs secure remote access.
For My Fellow Solutions Architect Students
If you’re pursuing your AWS Solutions Architect certification like I am, this project is basically a practical exam question:
- Networking: Understanding VPCs, security groups, and network isolation (just at the Docker level instead of AWS)
- Security: Implementing zero-trust access controls
- Architecture: Designing modular, scalable systems
- Identity & Access: Managing who can access what (Cloudflare Access = mini IAM)
The patterns here translate directly to AWS. Replace Docker networks with VPCs. Replace Cloudflare Tunnel with AWS PrivateLink or VPN. Replace Cloudflare Access with IAM policies. The architectural thinking is identical.
Your Turn: How Are You Managing Claude Code Context?
Seriously, I want to know—are you still manually copying documentation? Have you implemented MCP servers? Are you running Archon or something else?
And if you’re working with Docker networking, have you discovered the magic of user-defined bridge networks yet, or are you still wrestling with hardcoded IPs?
For my fellow freelancers: how much time are you spending on context switching? Is this a pain point you’ve solved, or are you still dealing with it?
Drop a comment or reach out—I’m always down to compare notes on AI development workflows and infrastructure patterns.
Visual Ideas for This Post:
- Network Architecture Diagram: Show the flow from Client → Cloudflare Edge → Tunnel → Docker ai-net → Container. This is the hero visual that explains the whole system.
- Before/After Workflow Comparison: Split-screen showing “Old Context Setup” (manual steps) vs “New Archon Workflow” (automatic indexing)
- Docker Stack Visualization: Show the two docker-compose stacks side by side with the shared ai-net network connecting them
- Traffic Flow Diagram: Annotated step-by-step showing how a request moves through each layer with security checks
- Screenshot: The Archon UI showing multiple projects being indexed (when you get multiple instances running)
Want me to help you create any of these visuals, or adjust anything in the post?