The honest answer to what self hosted mcp governance actually costs is almost never a licence fee. It is three environment variables, one dependency with no shortcut around it, and a small amount of operational discipline that is easy to skip on day one and expensive to have skipped later.
The three things you must supply
A self-hosted deployment of a permissioned MCP layer, running via Docker Compose against Postgres, needs exactly three required inputs before it will do anything useful:
- A Postgres connection string, version 14 or newer. Compose can bring up its own instance alongside the app, or you can point it at a database you already run. This is server-side only by design, so there is no browser-reachable database to secure separately.
- An LLM API key, used for exactly one thing: condensing a raw record from a system of record into the small, written summary that becomes a memory object. There is no fallback path. Without the key, ingest and refresh fail loudly rather than writing a summary a heuristic invented, because a summary that looks real but was not actually produced by reading the source is worse than an honest error.
- An encryption key you generate yourself, typically with
openssl rand -base64 32. A source credential, a database connection string or a bearer token for an upstream system, has to be decrypted and replayed on every refresh, so it cannot simply be hashed the way a password would be. This key is what makes that possible, and it is the one piece of this setup you are entirely responsible for keeping safe.
export OPENROUTER_API_KEY=sk-or-...
export CONTEXTELY_SELF_HOSTED=1
export CONTEXTELY_ENCRYPTION_KEY=$(openssl rand -base64 32)
docker compose up --build
Compose brings up Postgres 17 alongside the application container. The schema is applied once against that database, and from there the entitlement and freshness engines running on your own hardware are the same code as any hosted equivalent, not a stripped-down version of it.
What does self hosting an mcp gateway actually cost, in real terms?
Compute for a Postgres instance and a single application container, whatever your LLM provider charges per condensation call, and the discipline described below around the encryption key. There is no per-seat licence fee for internal use, and no feature gating between a self-hosted deployment and a hosted one running the same version.
What breaks if you skip a piece
| Missing input | What actually happens |
|---|---|
| The self-hosted flag left unset | Every workspace silently resolves to the smallest default plan: one source, three members, five hundred retrievals a month, even though nothing else is technically stopping you |
| No encryption key rotation plan | Losing the key makes every stored source configuration unreadable; there is a rewrap path, but only if you kept the old key somewhere |
| No auth provider configured for the dashboard | The web dashboard reports itself unconfigured and fails every session check closed, meaning it lets nobody in rather than letting everyone in; the API and MCP surfaces are entirely unaffected |
| Skipping the LLM key entirely | Ingest and refresh fail outright rather than degrading to a lower-quality summary, which is the correct failure mode but a surprising one if you expected a graceful fallback |
Table 1: what is actually optional in a self-hosted deployment, and the specific failure each omission produces.
"Server-side only, so there is no browser-reachable database."
from a self-hosting configuration note on required inputs, describing why the Postgres connection string is never exposed to a client
That property is not incidental. A permissioned layer whose entitlement checks could theoretically be bypassed by talking to the database directly from a browser is not actually enforcing anything; keeping the connection server-side only is part of what makes the governance claim hold up rather than a convenience.
The one deliberately optional piece: the dashboard
The web dashboard signs people in through a managed auth provider, which self-hosting against your own Postgres leaves unconfigured unless you explicitly point it at one. Rather than failing open, an unconfigured dashboard reports itself unconfigured and fails every session check closed. Nobody gets in, which is the safe direction for that failure to go. The REST API and the MCP server authenticate with API keys directly and are entirely unaffected by whether the dashboard is wired up, which for a deployment that exists mainly to serve agents rather than humans clicking through a UI is usually the only surface that matters day to day.
Is self hosted mcp governance actually cheaper than a hosted plan?
It depends what you are comparing. For a team already running Postgres and comfortable operating a Docker container, the marginal infrastructure cost is small, and the LLM condensation cost scales with how much content you actually ingest rather than with seats. What it is not cheaper than is the engineering time spent keeping the encryption key safe, watching for a Postgres version bump, and being the one who gets paged if the container falls over. That is a real cost, just not a licensing one, and it is worth weighing honestly rather than assuming "self-hosted" automatically means "free."
The operational baseline you are actually signing up for
None of this is exotic infrastructure. A Docker Compose file bringing up an application container alongside a database is one of the most common deployment shapes there is, and a PostgreSQL instance at version 14 or newer is a well-understood piece of infrastructure most engineering teams already run something on. The point of naming both explicitly is that self hosted mcp governance is not asking you to operate anything unfamiliar. It is asking you to operate a small, ordinary web application and a database, and to take the encryption key seriously, which is a much smaller ask than "run your own vector database cluster" or "manage a temporal knowledge graph," the kind of infrastructure some competing memory systems assume you are willing to take on.
That matters for the honest cost comparison. A team already comfortable running Postgres in production is not adding a meaningfully new category of operational risk by adding one more application container next to it. A team with no existing database operations experience is taking on real, if modest, new responsibility, and should weigh that against a hosted alternative rather than assume self-hosting is free because there is no invoice.
What actually leaves your network
On a correctly configured deployment, exactly one category of data leaves your infrastructure: the content of a record being condensed, sent to whichever model endpoint the LLM key routes to. Retrieval, scoring, entitlement checks and freshness bookkeeping are all local computation against your own Postgres instance and involve no outbound call at all. Re-fetches from a stale source go to your own systems of record, not through any third party. If the machine has no internet access beyond the model endpoint itself, the rest of the pipeline still works.
If you are weighing this against a hosted option, /self-host has the full environment variable reference and the exact Compose file, /pricing shows what the hosted alternative looks like for comparison, and /security covers how the encryption key and source credentials are handled once the deployment is live. For the governance question this post assumes you have already answered (who gets to see what, once the thing is running), mcp authorization is the companion piece.