MCPHub: a self-hosted gateway between AI clients and MCP servers

The problem MCPHub is aimed at

Every MCP client keeps its own list of servers. Claude Code, Cursor, Cherry Studio and OpenWebUI each need the same entries typed into their own configuration, and each client's config is a separate copy that drifts. Once a second person needs access, or a server needs a token that should not be pasted into four config files, the copy-per-client model stops working. MCPHub's answer is to make the hub the only place a server is defined. Clients point at an HTTP endpoint instead. The README frames the project as a unified control point between AI clients and MCP servers, and the feature list backs that up: one place to add a server, one place to set visibility, one place to read logs. The intended user is not a solo developer with one server. It is a team, a small platform group, or anyone running a shared MCP setup where access needs to be granted and revoked rather than edited by hand.

Routing: one server, several endpoints

The mechanism is path-based. MCPHub exposes the same connected servers under several URLs, and the path decides what the client sees. /mcp reaches all servers, /mcp/{group} reaches a named group, /mcp/{server} reaches one server, and /mcp/$smart selects tools by semantic search rather than by name. Smart routing also has a group-scoped form, /mcp/$smart/{group}. That last pair is the interesting part. Instead of a client loading every tool from every server into its context, $smart uses vector semantic search to pick relevant tools for a request, which the README describes as AI-powered tool discovery. Groups are the coarser control: they bundle servers and carry their own visibility rules, and the README says Tool, Prompt and Resource exposure can be controlled per group. Aliases let a server be addressed by a name you choose. The data flow is therefore client to HTTP endpoint to hub to the underlying server, with the hub holding the connection and the client never learning the server's real command line. For stdio servers the hub spawns and owns the process; for remote servers it holds the transport.

Per-user credentials and what they change

The per-user credential feature is the one that separates MCPHub from a plain proxy. A personal key can be bound to one shared server, so several people use the same server definition while each authenticates as themselves. The README states credentials are stored encrypted and that stdio runtimes are isolated per user. That isolation matters: a stdio MCP server is a child process, and if two users shared one process, one user's state or environment could leak into the other's calls. Isolated runtimes mean the hub starts a separate process per credential rather than multiplexing. The cost is memory and process count, which the README does not quantify. Authentication itself is layered. OAuth 2.0 is supported in both client and server modes, bearer keys are available, and the MCP endpoints require authentication by default. There is also a Skip Authentication option, but the README is explicit that it only affects dashboard login, not the MCP endpoints. Social login through GitHub and Google is listed as requiring Database Mode, so that path is not available in the default file-backed setup.

Getting it running with Docker and mcp_settings.json

Configuration starts with a JSON file in the same shape other MCP clients use. The README's example defines a time server via npx and a fetch server via uvx, each with a command and an args array. The recommended container command mounts that file plus a data directory: docker run -p 3000:3000 -v ./mcp_settings.json:/app/mcp_settings.json -v ./data:/app/data samanhappy/mcphub. The second volume is not optional in practice. The README notes that mounting ./data keeps credentials and state across restarts, and a container without it loses whatever the hub persisted. Two image tags are published. latest carries Node.js, pnpm, Python, uv and uvx, Git and build tools. latest-full adds a Rust toolchain, Docker Engine and Playwright browsers for Chrome and Firefox, with the Playwright part limited to amd64; the README says the extended image is for Rust-based servers or container-in-container workflows and is a larger download. The dashboard listens on port 3000 and the default username is admin. If ADMIN_PASSWORD is unset on first launch, a random password is printed to the server logs, and the README suggests passing -e ADMIN_PASSWORD=your-secure-password instead. Setting DISABLE_WEB=true skips the bundled dashboard and serves only the API and MCP endpoints, which fits a deployment where mcp_settings.json is managed outside the hub.

The CLI talks to the running hub

The same binary acts as a client for a running instance, so no separate install is needed. The README's sequence is mcphub login --url http://localhost:3000 --username admin, then mcphub servers list, then mcphub servers add fetch --type stdio --command uvx --arg mcp-server-fetch. Discovery is split into two steps: mcphub tools list shows what is available, and mcphub tools get fetch_url shows the required parameters plus a sample command. Invocation is mcphub call fetch_url url=https://example.com --json. Keys are created with mcphub keys create --name ci --access-type all. That last command is the one to think about before running it. An access type of all grants the key reach across everything the hub exposes, which is convenient for CI and also the broadest grant the CLI offers. The CLI also speaks the marketplace API through mcphub discover and mcphub install, which the README says work against any hub with discovery enabled. This is the part of the project with the most surface area, and the README defers the full subcommand list, profiles and CI usage to a separate CLI guide rather than documenting them inline.

Operational features and the limits of the README

Health checks monitor connection state and server status from one place, and the logging layer records tool-call activity, request status, latency and server logs. Hot-swappable configuration means servers can be added, removed or updated without downtime, which is the reason to run a hub rather than editing client configs. Tool result compression reduces large text outputs before they reach the client, a practical concern when a tool returns a long document into a context window. An MCP Apps proxy forwards interactive MCP Apps on single-server routes. Database Mode stores configuration in PostgreSQL for production, and it is a prerequisite for social login. What the README does not give is equally worth noting. There are no stated limits on how many servers or concurrent clients the hub handles, no description of what happens to in-flight requests when a server is hot-swapped, and no detail on the encryption used for stored credentials beyond the word encrypted. Those are documentation gaps, not defects, but they are the questions a production deployment will raise and the README will not answer. The docs site is linked for each feature, so the answer may exist there; it is not in the repository README.

Versus configuring each client directly

The alternative is what most people do now: put the server entry in each client's own config file and let every client manage its own connections. That approach has real advantages. There is no container to run, no port to expose, no admin password to rotate, and no single process whose failure takes down every client at once. For one person with two or three servers, direct configuration is less work than operating MCPHub, and it is the right default. The difference appears when the same server must be reachable by several clients and several people. Direct configuration means the credential is duplicated into every client, revocation means editing every file, and there is no log that shows who called which tool. MCPHub moves that state to one process with one authentication layer. The trade is a new dependency: the hub becomes a single point of failure between every client and every server, and the README does not describe a high-availability mode. If the hub is down, the clients that point at it have nothing to talk to. That is the cost of centralizing, and it should be weighed against the coordination savings rather than assumed away.

Licence, maintenance and what to check first

MCPHub is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It does not impose copyleft on your own code, though the usual obligation to preserve notices and state changes applies. This is not legal advice; if you redistribute the project or a modified version, read the licence text rather than a summary. On maintenance, the release cadence visible in the supplied material is active: v1.0.34, v1.0.35 and v1.0.36 landed within about eight days in September 2026, and the repository is not archived. That pace cuts both ways. Frequent releases mean fixes arrive quickly, and they also mean the configuration surface can move; the README already defers large parts of its own behaviour to an external docs site, so the version of the docs you read should match the image tag you pull. Pinning a specific tag rather than latest is the safer default for a hub that every client depends on. The first things to verify in your own environment are the transports your servers actually use, since the README lists SSE, Streamable HTTP and stdio as supported without enumerating edge cases, and whether your chosen image variant carries the runtimes your servers need, because latest lacks the Rust toolchain and Playwright browsers that latest-full provides.

Editorial conclusion

Adopt MCPHub if you operate more than one MCP server for more than one client or person and you want authentication, per-user credentials and a single dashboard instead of hand-editing every client's config. Do not adopt it if a single stdio server in one client's config file is enough, or if you cannot run a persistent container with a mounted data volume. Before committing, verify three things: that the transports your servers use are listed as supported, that a restart of the container leaves credentials intact through the mounted ./data volume, and that the admin password is set explicitly with ADMIN_PASSWORD rather than read from the first-launch log line.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. samanhappy/mcphub on GitHub