Self-Hosted MCP Registry: Why Enterprises Need More Than GitHub Repos and Zip Files
A self-hosted MCP registry is a private, organization-owned source of truth for the Model Context Protocol (MCP) servers an organization approves, signs, and distributes. It replaces the patchwork of GitHub repositories, npm packages, zip files, and public registries that most teams currently rely on with one centralized, scanned, signed, and audited catalog. For any organization running MCP servers in production (and most are, whether they know it or not), a self-hosted MCP registry is the foundation that everything else in MCP governance depends on.
This guide explains what a self-hosted MCP registry covers, why GitHub repos and zip files do not meet the bar, and what to look for in a registry built for security and platform teams in 2026.
What is a self-hosted MCP registry?
A self-hosted MCP registry is an internal service that mirrors approved MCP servers from public and internal sources, scans them, signs them, versions them, and serves them to IDEs, agents, and runtimes through the MCP registry API. The organization owns the registry, controls what enters it, and produces tamper-evident records of every artifact and decision.
A well-designed self-hosted MCP registry has six properties:
- Single source of truth for all approved MCP servers
- Cryptographic signing and version pinning
- Integrated security scanning and signed attestations
- Implements the MCP registry API for native IDE and agent integration
- Air-gapped and disconnected operation
- Tamper-evident audit log of every artifact and access event
Why GitHub repos and zip files are not enough
Most organizations today distribute MCP servers through some combination of GitHub repos, npm, internal git, shared drives, or "ask a teammate for the zip file." That works for a small team in a pilot. It breaks down fast at organizational scale.
No inventory. Nobody can answer "which MCP servers are running where" because the distribution channels are scattered and informal.
No signed identity. A repo or a zip is mutable. The version a developer installed last month is not guaranteed to be the version that exists today.
No scanning gate. Public sources do not scan for tool poisoning, prompt injection markers, license risk, or known vulnerabilities. Internal git typically doesn't either.
No provenance. When something breaks, there is no signed record of who reviewed the artifact, what scans it passed, or which version is in production.
No air-gapped path. A GitHub-dependent workflow does not function inside DDIL or air-gapped networks. Federal, defense, healthcare, and OT teams cannot rely on this model.
No audit trail. A git clone is not an audit event in any system the GRC team uses.
Shadow MCP grows unchecked. When the central pattern is "everyone fetches from the internet," developers will continue to do so, often from sources the security team has never reviewed.
These are not theoretical problems. The Postmark, Smithery, GitHub MCP, and mcp-remote incidents (CVE-2025-6514, 437K+ downloads, CVSS 9.6) all happened to organizations that had no inventory or signed registry behind their MCP usage.
Why MCP server security matters at the registry layer
The registry is where the cheapest controls live. Stopping a compromised MCP server at the registry is much less expensive than stopping it at runtime, which is much less expensive than discovering it during an incident review. A self-hosted MCP registry centralizes those cheap controls so the rest of the governance stack has something consistent to enforce against.
| Control | Without a registry | With a self-hosted registry |
|---|---|---|
| Inventory | Manual, incomplete | Automated, always current |
| Scanning | Per-developer if at all | Required gate before admission |
| Signing | None | Required cryptographic signature |
| Versioning | Mutable | Pinned, immutable OCI digests |
| Provenance | Unclear | Signed attestations attached to every artifact |
| Air-gapped distribution | Not supported | First-class supported pattern |
| Audit | Missing or scattered | Tamper-evident, chained |
What a self-hosted MCP registry must include
1. Implementation of the MCP registry API
IDEs (VS Code, Cursor, Claude Desktop) and production agents speak the MCP registry API. The registry must implement it natively so existing tools can point at the internal source instead of public sources with no client changes. If the registry forces a custom client, adoption stalls.
2. OCI-native packaging
MCP servers should be packaged as OCI artifacts. OCI gives the organization:
- Standard signing (Cosign, Sigstore)
- Pinned digests for version integrity
- Distribution through existing container registries
- Compatibility with the rest of the AI artifact ecosystem (models, agents, policies)
If the registry uses a proprietary packaging format, it isolates MCP from the rest of the stack and adds long-term maintenance burden.
3. Integrated security scanning
The registry should scan every MCP server before it enters the catalog, looking for:
- Known CVEs and vulnerable dependencies
- License risk
- Suspicious tool definitions and prompt instructions
- Serialization attacks and malicious code patterns
- Credential exposure markers
Results should be captured as signed attestations attached to the artifact, not stored separately where they can be detached.
4. Signed attestations and provenance
For every MCP server in the registry, the organization should be able to produce:
- The signing key and identity
- Who reviewed it and when
- What scans it passed
- What dependencies it includes
- Where the source came from
Provenance is the chain compliance teams reach for during audits and the chain incident responders reach for during investigations.
The attestation needs to describe artifact safety, not just the build. The May 2026 Mini Shai-Hulud worm (CVE-2026-45321, CVSS 9.6) compromised legitimate build pipelines and produced valid SLSA Level 3 attestations on malicious npm and PyPI artifacts. SLSA tells you how and where something was built. It does not tell you whether the artifact is safe. For MCP servers, attestations should also capture scan results (serialization attacks, prompt injection markers, suspicious tool definitions, dependency CVEs) as signed records that travel with the artifact and can be verified independently of the pipeline that produced it. Brad Micklea's Mini Shai-Hulud analysis walks through why expanded attestations are the structural fix.
5. Air-gapped and disconnected operation
Federal, defense, healthcare, OT, and tactical edge environments cannot rely on a SaaS-hosted registry. The self-hosted registry must operate fully inside the customer's environment with no internet dependency at runtime. Updates can happen on a defined cadence with controlled imports.
6. Native integration with the runtime
The registry is one half of the picture. The other half is the runtime that enforces policy on what loads and what each MCP server is allowed to do. The registry and the runtime should share a policy language, an artifact format, and an audit chain. If they speak different languages, governance breaks at the seam.
7. Tamper-evident audit
Every artifact admission, signing event, policy decision, and pull from the registry should be written to a cryptographically chained log. The chain ensures that past entries cannot be altered without detection.
Self-hosted MCP registry vs. public MCP registry
| Capability | Public MCP registry | Self-hosted MCP registry |
|---|---|---|
| Inventory of what your org uses | None | Complete |
| Scanning before admission | Variable; often none | Required |
| Cryptographic signing | Variable | Required |
| Version pinning | Variable | Required |
| Air-gapped operation | Not supported | Supported |
| Tamper-evident audit | Not available to you | Owned by you |
| Compliance evidence | Not exportable | Exportable directly |
| Control over what runs | None | Full |
| Risk profile | Inherited from the public source | Owned and reduced by your controls |
Public registries are useful as upstream sources. They are not a place to run your organization's MCP supply chain from.
Self-hosted MCP registry vs. GitHub or zip-file distribution
Some organizations try to evolve a GitHub-based workflow into "registry-like" by adding a README, a SHA file, and a process. That falls short on three structural counts.
It is not a registry the MCP protocol speaks to. IDEs and agents speak the MCP registry API, not git. Pointing them at a git repo skips the registry interface entirely.
It is not a runtime control. A README is a request. A signed OCI artifact verified at admission is a control.
It is not an audit chain. A git log is a useful change record. It is not a tamper-evident audit of what loaded, what was denied, and what was approved by which human at runtime.
How to roll out a self-hosted MCP registry
- Inventory. Sweep managed devices, CI/CD pipelines, agent runtimes, and IDEs for MCP servers currently in use.
- Stand up an internal MCP registry that implements the MCP registry API. Mirror approved servers from public sources after scanning and signing.
- Point IDEs and agents at it. Replace public source URLs in developer tooling and agent configuration with internal registry endpoints.
- Define artifact policy. Specify which signatures, scans, and provenance properties are required before an MCP server can load in a runtime.
- Pin versions in production. Use OCI digests, not floating tags. An attacker who pushes a malicious update should not be able to silently take over your workloads.
- Configure air-gapped distribution patterns. For DDIL or air-gapped environments, set up controlled import flows with no runtime internet dependency.
- Wire the registry to the runtime. Make sure artifact policy evaluation, tool policy, guardrail policy, and audit logs share one chain across registry and runtime.
- Review and update on a defined cadence. New MCP servers and new versions show up weekly. Static registry contents are stale registry contents.
Common mistakes when deploying a self-hosted MCP registry
- Pointing agents at public sources "for now." The "for now" turns into the default and the inventory never catches up.
- Using a generic OCI registry with no MCP-specific support. Without the MCP registry API, IDEs and agents cannot use it natively, and developers route around it.
- Skipping scanning at admission. A registry without scanning is just a directory.
- Floating tags instead of pinned digests. An attacker who pushes a malicious update can take over workloads silently.
- Air-gap-as-an-afterthought. Designing for connected environments and retrofitting air-gapped support usually produces a brittle system with bolted-on patterns.
- A registry that doesn't talk to your runtime. Two separate vendors, two separate policy languages, two separate audit logs. Governance breaks at the integration boundary.
How Jozu Hub's MCP Registry fits
Jozu Hub is a self-hosted, customer-deployed registry for models, agents, datasets, policies, and MCP servers. The MCP Registry API in Jozu Hub implements the MCP registry specification so VS Code, Cursor, Claude Desktop, and production agents can point at it directly. Every MCP server in the catalog is packaged as a signed OCI artifact and scanned by five integrated scanners (ModelScan, LLM Guard, Garak, Promptfoo, ART), with results captured as signed Agent attestations on the artifact itself. Cosign signatures, OCI referrer attestations, and pinned digests provide cryptographic provenance.
Jozu Hub is paired natively with Jozu Agent Guard, the secure runtime for AI. ArtifactPolicy enforces admission at runtime. ToolPolicy and GuardrailPolicy enforce tool-level access control and content inspection on every MCP tool invocation. Audit events from registry and runtime converge into one cryptographically chained log. Policies travel as signed OCI artifacts and enforce locally with no SaaS dependency, including in air-gapped and DDIL environments.
One self-hosted registry. One runtime. One policy language. One audit chain.
Explore Jozu MCP Registry →
Explore Jozu Agent Guard →
Request a demo →
Frequently asked questions
What is the difference between a self-hosted MCP registry and a private GitHub repo?
A self-hosted MCP registry implements the MCP registry API, packages servers as signed OCI artifacts, enforces scanning at admission, and produces tamper-evident audit logs. A private GitHub repo provides version control and an access-controlled directory. The two solve different problems.
Do I need a self-hosted MCP registry if I only use a few public MCP servers?
Even a small number of MCP servers warrants a registry as soon as those servers touch production data, customer information, or systems of record. The risk profile of MCP tools justifies a curated source, not a count of servers.
Can a self-hosted MCP registry work air-gapped?
Yes, with the right architecture. The registry runs entirely inside the customer's environment, accepts controlled updates from outside on a defined cadence, and serves IDEs and agents with no internet dependency at runtime.
Does a self-hosted MCP registry replace the runtime?
No. The registry covers curation, admission, and provenance. The runtime covers tool-level access control, content inspection, human-in-the-loop, and audit at runtime. Both are needed.
Will IDEs and agents need new clients to use a self-hosted MCP registry?
Not if the registry implements the MCP registry API. VS Code, Cursor, Claude Desktop, and most agent frameworks can be pointed at any compliant registry.
Who owns the self-hosted MCP registry inside the organization?
Platform engineering typically operates it. Security architecture owns the policies that gate admission. GRC owns the audit outputs. AI security or AI center-of-excellence teams coordinate across them.
What is the first step?
Inventory what MCP servers are in use today, stand up an internal registry that implements the MCP registry API, and point IDEs and agents at it. From there, layer in scanning, signing, and policy.
Related reading:
- MCP Server Security: Risks, Best Practices, and Enterprise Controls
- What Is MCP Governance? A Framework for Securing MCP Servers at Scale
- AI Agent Governance: A Practical Guide for Enterprise Teams
Ready to deploy a self-hosted MCP registry? See Jozu MCP Registry or request a demo.