Teams Keep Trying to Self-Host a Codebase MCP. Here's What That Actually Costs.

"We have a shared codebase MCP — one of our platform engineers set it up last quarter." This sentence appears increasingly often in conversations about team AI tooling. The next sentence, six months later, tends to be something like: "It might be a bit stale, we're not sure who's maintaining it anymore."

Self-hosting a codebase MCP server is attractive for the same reason that self-hosting anything is attractive: you control it, it runs on your infrastructure, and the initial setup cost looks modest. Build it once, point your developers at the endpoint, and the team has shared AI context. That is how it looks at launch.

The problem is what the tool needs to be in the months after launch. A codebase MCP is not a static artifact — it is an infrastructure component that requires continuous maintenance, and that maintenance is easy to neglect because the cost of neglect is invisible until something goes noticeably wrong.

The setup looks cheap

The initial investment for self-hosting a codebase MCP server is real but bounded. A platform engineer spends a week setting up the indexing pipeline, configuring webhooks to trigger re-indexing on repository events, deploying the service to a VM or container, and writing the configuration instructions for developers to connect their editors. At the end of that week, the team has a working shared codebase MCP. That engineer has accomplished something useful.

What self-hosting a codebase MCP server looks like at launch:
  -> Clone the MCP server repo and configure it for your repositories
  -> Set up a GitHub webhook or cron job to trigger re-indexing
  -> Deploy to an internal server or cloud VM
  -> Configure developer editor settings to point at the endpoint
  -> Done — team has a shared codebase MCP
  -> Owner: platform engineer who set it up

The ongoing cost is not visible at this point. The service is running. The index is fresh. Developer editors are pointing at the endpoint. Everything looks operational. The hidden costs are all in the future.

What breaks silently

Codebase MCP servers fail in ways that are easy to miss. The most common failure mode is an indexing job that stops running. This can happen because a GitHub token expires, a rate limit is hit and the retry logic is inadequate, a repository rename breaks the webhook configuration, or the server runs out of disk space during a large indexing run. When the indexing job fails, the MCP server continues to serve — it just serves stale context.

Developers using a stale index do not immediately know their context is stale. The AI continues to respond. The responses continue to sound plausible. The staleness becomes visible only when a developer notices that the AI is describing behavior that no longer exists, or missing behavior that was added in a recent sprint. By that point, the index may be weeks or months behind.

What the same self-hosted MCP looks like six months later:
  -> Indexing job silently failed three weeks ago — nobody noticed until today
  -> The platform engineer who built it moved to a different team
  -> The cron job needs updating because the GitHub token expired
  -> The MCP server has a new version with security patches — upgrade is manual
  -> Three developers are on the current version; two are on an old fork
  -> The server VM is paying for idle time between indexing runs
  -> One team asks: "why is our AI giving wrong answers about AuthService?"
  -> Answer: AuthService was refactored 3 weeks ago; the index predates it

The AuthService example in that list is representative of how stale-context incidents actually manifest. A developer asks their AI coding assistant about a service's authentication flow. The AI describes the old flow, the one that existed before the refactor three weeks ago. The developer writes code that integrates with the old flow. That code fails in testing. The debugging process eventually surfaces the stale MCP index as the root cause — but not before several hours of developer time were spent on the wrong path.

The ownership problem

Infrastructure requires an owner. When a service breaks, someone needs to be responsible for fixing it. Self-hosted MCP servers tend to be owned by whoever set them up, which is usually a platform engineer or a senior developer who had time one quarter to do it. When that person leaves the team, changes roles, or moves to higher-priority work, the ownership becomes informal.

Informal ownership is not the same as no ownership — someone will usually respond when things break badly. But it is different from accountable ownership, where someone monitors the service proactively, applies security patches promptly, and upgrades versions before they become compatibility problems. Informal ownership produces the classic result: the service runs fine until it does not, and when it does not, the work of diagnosing and fixing it falls on whoever happens to be available.

This is a well-understood pattern in software operations. Services without explicit owners accumulate technical debt, fall behind on security updates, and become liabilities. The time it takes depends on the complexity of the service and the stability of the team around it. For a codebase MCP server — which depends on GitHub API versions, embedding model compatibility, and the constantly-changing structure of the repositories it indexes — the accumulation tends to be faster than teams expect.

The hidden cost accounting

What self-hosting a codebase MCP actually costs over 12 months:
  -> Initial setup: 1–2 weeks of platform engineer time
  -> Ongoing maintenance: 2–4 hours/month for a healthy setup
  -> Incident response when indexing breaks: 4–8 hours per incident
  -> Token/credential rotation: 1–2 hours when credentials expire
  -> Version upgrades: 2–4 hours per major version
  -> Security patches: time-sensitive, often unplanned
  -> Stale-context incidents: debugging time hidden across many developers
  -> Total engineering-hour cost year 1: 60–100 hours (conservative)

The 60-100 engineering hours in that estimate is conservative. Teams with frequent repository changes, many connected repos, or high developer turnover will see the upper end of that range. Teams that treat the service as low-priority will see incidents that cost more than the estimate because they are not caught early.

Against a typical engineering hourly cost, 60-100 hours of platform engineer and senior developer time over one year often exceeds the annual cost of a managed service that handles all of that work. The self-hosted option is cheaper if all the maintenance work were zero-cost — but infrastructure maintenance is never zero-cost, it is just unevenly distributed and hard to see until the incidents start accumulating.

Security patches as an unscheduled tax

MCP servers are software with security surface. Check Point disclosed CVEs in Claude Code in 2025 that allowed remote code execution through malicious repository configuration files. The MCP ecosystem is young, which means security researchers are actively finding vulnerabilities in MCP-adjacent tooling. When a critical security patch is released for a self-hosted MCP server, applying it is not scheduled work — it is urgent, unplanned work that competes with whatever sprint the team is currently in.

Managed MCP services apply security patches as part of their operating model. The team does not need to schedule patch application or respond to security advisories with emergency maintenance windows. For security-sensitive organizations — regulated industries, companies with enterprise contracts, teams that have already been through a security incident — the difference between "we apply patches on our schedule" and "patches are applied automatically" is a meaningful operational risk reduction.

What managed actually means in practice

Kognita runs the indexing pipeline, applies security updates, maintains the API endpoint, handles GitHub API rate limiting, and manages re-indexing schedules as part of the service. The team does not have a cron job to monitor. There is no VM to resize when a large repository exceeds the server's disk space. There is no token expiry to track. When the MCP server is updated, developers notice only that their context quality improved — not that an upgrade happened.

The developer experience is a single endpoint string in an editor config. Behind that string is infrastructure that the team would otherwise need to build and maintain itself. The question of whether managed is worth it is a question about the value of redirecting 60-100 engineering hours per year from infrastructure maintenance to building the product.

Final take

Self-hosting a codebase MCP is a reasonable choice if you have a platform team with capacity to maintain it as first-class infrastructure, a stable team around the service, and a threat model that requires keeping indexed code on your own infrastructure. Those conditions exist in some organizations.

They do not exist in most growing companies. What exists in most growing companies is a codebase MCP that was set up enthusiastically, is currently somewhat stale, and is informally owned by someone who is not prioritizing it. That is not a productive AI tooling foundation — it is deferred maintenance in the shape of a context server.

Self-hosting a codebase MCP is not free. It is a commitment to a class of infrastructure maintenance that grows with your team size and repository churn. Managed infrastructure exists to take that commitment off your engineering team's plate so they can spend those hours building the product instead.