Deploying a Code Intelligence Platform in a Single Docker Container

Deploying a code intelligence platform inside a single Docker container is not a shortcut. It's the architectural choice that decides whether the tool ever reaches production at all. Teams evaluate these platforms constantly, get impressed by a demo, and then quietly abandon the rollout once someone tallies up what it would take to run the thing for real.

The pattern is common enough to name. A search team pilots a tool, likes what it returns, and then the infrastructure requirements appear on a whiteboard: an indexing service, a separate search cluster, an auth layer, a database, a web tier, each with its own uptime story and its own on-call rotation. That's usually where the project dies, because nobody wanted to own five new services to get one capability.

Stack Overflow's 2025 Developer Survey found 84% of developers either use AI coding tools already or plan to. But roughly half of that group either avoids AI agents outright or sticks to the simpler assistants, and the reasons they give aren't about capability. They're about control: which model runs, what it costs at scale, and where the source code actually goes once it leaves a laptop. The hesitation reflects a trust gap. It's a trust gap about whether the operational cost is survivable.

For regulated environments, that gap widens into a wall. Classified-program work, pharmaceutical manufacturing networks, OT/ICS environments, and certain healthcare clinical networks (per an outcomeops.ai analysis) don't have a cloud option to fall back on. If the deployment can't land entirely on infrastructure the customer already controls, it doesn't land at all. Which raises the real question this piece is built around: if the deployment model itself is what keeps a tool out of production, then collapsing that model down to a single container is a necessity. It's the decision that determines whether the tool ships.

What Docker containers solve, and why that matters specifically for code intelligence

Docker, first released in March 2013 (the stable release as of writing is 29.8.1, dated September 15, 2026), uses OS-level virtualization to package software so it runs the same way regardless of what machine it lands on. That sounds like a simple pitch, but it quietly solves four separate problems that used to each require their own fix.

First, runtime and dependency pinning: whatever version of Python, Node, or Go the tool was built against ships inside the image, so there's no drift between what the developer tested and what the customer runs. Second, system dependency bundling: native libraries, search backends, index formats, all of it travels inside the image instead of landing on the operator's to-do list. The network surface is declared: which ports the service opens is written into the image. Fourth, there's a clean boundary around persistent state: volumes and mounts spell out exactly what survives a restart and what doesn't.

For code intelligence, those four properties happen to solve the exact problem that made these platforms hard to deploy in the first place. A search backend, an indexer, a web UI, and an authentication layer can all live inside one image boundary without forcing the operator to wire them together by hand. By 2026, this pattern had become close to universal. Every serious open-source agent runtime ships a Dockerfile or a docker-compose.yml, because every agentic tool runs into the same four problems and Docker answers all of them at once. Single-container deployment is now its own recognized category for code intelligence specifically, not just a generic packaging habit borrowed from web apps.

Knowing why Docker works is the easy part. What it actually means to run a multi-service code intelligence platform, with a search engine, an indexer, a chat layer, and an auth system, all inside one container boundary, is where the real engineering happens.

How a production code intelligence platform runs as a single container without becoming a maintenance liability

The instinctive objection is that "single container" must mean everything gets shoved into one process, a monolith with no seams. That's not what's happening here, and the distinction matters.

The actual pattern uses a process supervisor, typically supervisord, to run several distinct services inside one container boundary, each with a clear job and clear separation from the others. Nothing about the internal architecture is monolithic. What changes is the packaging: instead of five deployments, there's one.

A production single-container code intelligence platform typically runs something close to this set of services under supervisord: a Next.js server handling the React front end, authentication through NextAuth.js, and the tRPC API routes; a backend Express server handling REST endpoints and streaming chat responses; a background worker chewing through async jobs like connection syncs and repository indexing; an MCP server for AI agent traffic; and two Zoekt processes, zoekt-webserver answering search queries and zoekt-git-index building the trigram index. That's six distinct services, each doing one job, all inside a single image.

The operator never sees any of that internal wiring. What they see is one image to pull, one container to start, and one set of volumes to configure. There's no service mesh to stand up, no inter-service TLS certificates to rotate, no Kubernetes cluster required just to get search working. The job shrinks down to running a container and pointing it at the right mounts.

A single-container architecture makes it harder to scale individual services horizontally. If the indexer needs ten times the compute but the web tier doesn't, a single container can't split that apart cleanly the way a Kubernetes deployment with separate pods can. This is a design that optimizes for operational simplicity over massive horizontal scale, which is exactly the right trade for most enterprise engineering teams and the wrong one for a hyperscaler running search across billions of documents. Compare that to how traditional enterprise code search platforms shipped: each service layer managed independently, each with its own deployment pipeline, which is precisely where those rollouts historically got stuck.

The search engine underneath: why Zoekt is the right foundation for this architecture

Zoekt, German for "search," was built originally at Google and later open-sourced. It works off a trigram index rather than semantic embeddings or an LLM call.

Trigram indexing gets sub-second results across millions of files without needing any model inference at query time, and it is deterministic and driven by a real query language rather than a similarity score. Trigram indexing gets sub-second results across millions of files without needing any model inference at query time. It's deterministic and driven by a real query language, not a similarity score that shifts depending on which embedding model happens to be loaded.

A benchmark from devtoollab.com puts a number on this. Zoekt indexed a shallow clone of kubernetes/kubernetes, 31,300 files, on a laptop in 6.03 seconds. A filtered regex query across that entire index then came back in 193 milliseconds. That's not a marketing claim about theoretical performance; it's a repository the size of Kubernetes, running on ordinary hardware, answering in under a fifth of a second.

Zoekt fits the single-container model because it's already self-contained by design. The index sits on disk, on a mounted volume. The webserver is one binary. The indexer runs as a background process. All three map cleanly onto the supervisord pattern described above, with no adaptation required to force Zoekt into that shape. Its query language also does something semantic search structurally can't: exact symbol name lookups, regex across specific file patterns, and language-filtered queries where a precise match, not a fuzzy one, is required. What Zoekt doesn't do on its own is just as important to name: it is a search engine, and the broader capabilities of a code intelligence platform get built on top of it inside the container. Those layers get built on top of Zoekt inside the container. Zoekt is the floor, not the whole building.

The MCP layer: how the same container serves AI agents and human users simultaneously

Anthropic released the Model Context Protocol in late 2024, and within about eighteen months it had become the default way AI coding tools talk to external context sources. By mid-2026, MCP had been adopted across Claude Code, Cursor, VS Code Copilot, Codex, Windsurf, Zed, Continue.dev, and Goose, among others.

The download numbers track the adoption curve closely. MCP SDKs crossed 97 million monthly downloads by March 2026, passed 110 million by April, and were closing in on half a billion monthly downloads by mid-2026. Adoption had spread broadly across the ecosystem by that point.

What MCP actually does for a codebase is easy to treat as plumbing when it's the opposite. When an agent queries a codebase through an MCP server, whatever comes back shapes every next move the agent makes: the lines it writes, the refactor it proposes, the test it generates. The context layer functions as a central determinant of agent output. It's arguably the single most consequential variable in whether that output is any good.

Running the MCP server as one of the internal services under supervisord decouples the intelligence layer from the consumption layer. Different engineers, using different agents, whether that's Claude Code on one machine or Cursor on another, all draw from the same indexed codebase through a shared MCP interface. Nobody needs a separate deployment to get access; the server starts when the container starts and sits there waiting for any MCP-compatible client on the network.

The model choice stays with the team, too. The platform connects to whatever LLM provider is configured, OpenAI, Anthropic, Bedrock, Vertex, Mistral, or a self-hosted model, using the team's own API keys. Code doesn't leave the container to reach a vendor's servers unless someone explicitly wires that route.

On July 28, 2026, MCP's maintainers pushed through a major revision of the spec. Anthropic technical staff member David Soria Parra called it probably the most substantial change to the protocol since authorization was added, and the revision brought in enterprise features, with authentication among the additions specifically noted. That matters directly for regulated industries, where compliance requirements around authentication and auditability are non-negotiable.

Who the platform serves beyond senior engineers, and why that changes the ROI calculation

Classic code search assumes a specific user: a senior engineer who already knows roughly where to look and just needs to confirm it fast. The tool speeds up someone who already understands the codebase's shape.

A natural-language interface on top of that same index changes who shows up to use it. A product manager investigating a bug report, a support engineer trying to understand what a feature actually does under the hood, a new hire three weeks in trying to find where a config value gets read: none of them need to interrupt a senior engineer to get an answer anymore. And that interruption has a real cost. Every "hey, quick question, where's X implemented" is a context switch for whoever answers it, and those add up across a team fast.

A growing share of engineering teams are actively running AI agents in production workflows. The same teams adopting agents tend to be the ones where non-engineers are increasingly expected to understand system behavior well enough to work alongside those agents, not just file tickets about them.

That changes how the deployment cost gets justified. Counted purely as a developer tool, the platform has to earn its infrastructure cost against developer productivity gains alone. Counted as something PMs, support staff, and new hires also use daily, the same cost spreads across a much bigger population of people getting value from it. Single-container deployment is what makes that broader audience realistic in the first place: there's no IDE plugin to install per seat, no per-user setup ritual. Access is a web UI, open to anyone with network access to the container.

The privacy and data-residency guarantees that single-container self-hosting delivers

Once source code goes to a SaaS code intelligence platform, the real questions are where it actually goes, who can see it, and whether it crosses a compliance boundary the organization can't afford to cross.

That fear isn't abstract. CVE-2025-53773 documented a hidden prompt injection that enabled remote code execution through GitHub Copilot, with a CVSS score of 7.8. The EchoLeak vulnerability in Microsoft 365 Copilot showed a zero-click prompt injection path that could silently exfiltrate enterprise data without a single user action. And research from Apiiro found that AI-generated code introduced more than 10,000 new security findings per month across the repositories studied, a tenfold spike over six months and still climbing at the time of the report.

Self-hosted single-container deployment answers a specific slice of that fear directly. Source code gets indexed and stored inside the container's own volumes, on infrastructure the organization already controls, and it never crosses the network perimeter unless someone explicitly configures a route out. The bring-your-own-API-key design extends that same guarantee to the model layer: the organization decides which LLM provider sees a prompt and what that prompt contains, rather than the platform deciding for them.

For deployments where cloud simply isn't an option, classified-program work, pharma manufacturing networks, OT/ICS environments, certain healthcare clinical networks, on-prem container deployment is the only path that exists. Single-container architecture is what makes that path realistic for a team without a dedicated platform engineering group standing by to babysit five separate services.

Self-hosting doesn't automatically hand a team every protection on the roadmap. MCP's 2026 enterprise features, authentication and audit logging among them, were still maturing as of the July revision. A team in a regulated industry should check which of these are actually shipped in the version they're deploying rather than assuming a roadmap item is already live.

The ecosystem around the single container: what connects to it and how

The container doesn't sit in isolation. On the indexing side, it pulls from code hosts, GitHub, GitLab, Bitbucket, Azure DevOps, Gerrit, and Gitea, keeping a synchronized local index while the actual code stays inside the deployment boundary the whole time.

Context doesn't stop at code, either. MCP-based connectors reach out to Jira, Linear, and Confluence, giving both agents and human users a single query surface that spans code and the project management layer around it. On the consumption side, any MCP-compatible client, Claude Code, Cursor, VS Code Copilot, Codex, Windsurf, Zed, Continue.dev, can call into the embedded MCP server and use its search and navigation tools as part of an agent session.

That consumption pattern looks nothing like human search behavior. An agent inside a session might call the search tool dozens of times in a few minutes, at a frequency no human ever approaches sitting at a keyboard. The Zoekt-backed index is built for exactly that load, returning results in under 200 milliseconds even on complex queries, which is the only way an agent workflow stays usable rather than grinding to a halt waiting on search.

Code execution sandboxing is a separate layer from this one. Teams running agents that also execute generated code need a sandbox, tools like E2B, Daytona, or Northflank, to run that code safely. The code intelligence container provides context; the sandbox provides safe execution. They sit next to each other, not on top of one another, and neither replaces the other.

The ecosystem also has its casualties, which serve as a caution rather than a footnote. Bloop, a code search tool built on a systems programming language that picked up a large following on GitHub, was archived on January 2, 2025, and the company behind it announced a shutdown on April 10, 2026. Its domain now redirects to a parking page. Any team that built workflows on top of it now has to migrate, which is the practical risk of building on a tool without a clear maintenance commitment behind it.

What the deployment looks like: from docker pull to indexed repositories

Stripped down, the operator's job is short. Pull the image, set the environment variables (code host credentials, LLM API keys, volume mount paths), run the container, and point it at the repositories that need indexing.

What the operator doesn't have to do is the more interesting list. No separate database to stand up. No search cluster to configure by hand. No standalone authentication service to deploy and patch on its own schedule. No manual wiring between five services that all need to know how to find each other. Supervisord handles all of that inside the container, invisibly, which is the entire point of building it this way in the first place.