MCPCAN: a container control plane for MCP servers, with a licence you should read first

The problem MCPCAN targets: MCP servers that grow past one host

An MCP server is usually easy to start and awkward to run. The README frames the core issue as system configuration conflicts when MCP services are deployed, and that matches how these servers behave in practice: each one wants its own runtime, its own environment variables, its own port, and its own credentials. Once you have five of them, you have five upgrade paths and five places where a token can leak.

MCPCAN's answer is to stop treating an MCP server as a process and start treating it as a container. The README states that the platform uses containers for flexible deployment of MCP services, resolving potential system configuration conflicts. That single decision carries the rest of the design: containers give you isolation, a registry to pull from, and something for an orchestrator to restart when it dies.

The intended audience is stated plainly. The README says it provides DevOps and development teams with MCP service lifecycle management through a modern web interface. So this is not a library you import into an agent. It is an operations tool for the people who run the servers that agents connect to.

That distinction matters when you evaluate it. If you are a developer wiring one MCP server into a local client, MCPCAN is heavier than the problem. If you are the person who gets paged when the internal tool server stops responding, the container model and the monitoring view are the parts that matter.

Three Go services, a Vue console, and Traefik at the edge

The README lists three components and their directories, which is the clearest picture of the architecture available. MCPCan-Web lives in frontend/ and is the Vue 3 management UI. MCP-Market lives in backend/cmd/market/ and is described as core business covering marketplace and instance management. MCP-Authz lives in backend/cmd/authz/ and handles RBAC along with user and department management.

Splitting market from authz is a deliberate choice. Instance lifecycle and identity are different concerns with different failure modes, and keeping them in separate binaries means a bug in marketplace logic does not take down token validation. The cost is two services to deploy and monitor instead of one, plus a shared MySQL and Redis that both depend on.

The storage layer is MySQL through GORM for persistence and Redis for cache and tokens, per the technology stack section. Putting tokens in Redis is a reasonable fit for short-lived credentials, and it means the auth service can validate a token without a database round trip. It also means Redis becomes a hard dependency for authentication: if Redis is unavailable, token checks fail, and every MCP call behind the gateway fails with them.

Traefik sits at the edge as the gateway. The README lists it under ops and deployment rather than as an application component, which suggests it handles routing and TLS termination in front of the services. The README does not document the routing rules, so how a specific MCP server gets exposed through Traefik is something you would confirm from the deployment guide or the compose files themselves.

The backend is Go 1.25.x with Gin and gRPC via grpc-gateway, and the core libraries list includes LangChainGo, MCP-Go, the Docker SDK, and client-go. The presence of both the Docker SDK and client-go is consistent with the two deployment targets the README describes: Docker Compose for local and lightweight production, Helm for Kubernetes.

Protocol conversion is the feature that decides whether you need this

MCP clients do not all speak the same transport. Some expect SSE, some spawn a process over STDIO, and newer ones want STREAMABLEHTTP. The README states that MCPCAN uses SSE, STDIO, and STREAMABLEHTTP access protocols to deploy MCP, and that it supports multi-protocol compatibility and conversion between different MCP service architectures.

This is the part of the product with the clearest practical value, and it is worth being precise about why. If you have an MCP server that only runs as a local stdio process, any client that connects over HTTP cannot reach it directly. A conversion layer that presents that server over SSE or STREAMABLEHTTP changes who can consume it. The repository topics include dify-synchronous, which points at the same use case: Dify and similar platforms want an HTTP endpoint, not a spawned process.

The README does not describe how the conversion is implemented, which direction it supports, or which protocol pairs are covered. That gap is worth flagging rather than glossing over. Conversion between transports is not symmetric. Turning a stdio server into an HTTP endpoint requires the platform to keep the process alive and multiplex sessions onto it, which raises questions about per-session state and concurrency that the README does not answer.

So treat protocol conversion as the feature to test first, not the feature to assume. If your target client needs STREAMABLEHTTP and your server is stdio-only, that is the exact path to verify in the demo instance or a local compose deployment before you plan anything around it.

Getting it running: four commands, then a login you should change

The README gives a Docker Compose path as the recommended quick start, aimed at local development, testing, and lightweight production deployments. The commands are short enough to reproduce exactly:

git clone https://github.com/Kymo-MCP/mcpcan.git cd mcpcan/deploy/docker-compose/ cp example.env .env chmod +x replace.sh ./replace.sh docker compose up -d

The replace.sh step is the one worth pausing on. The README describes it as generating the final configuration, which implies the compose files contain placeholders that the script substitutes from .env. It also notes that REGISTRY_PREFIX in .env can be modified to switch between global and CN mirrors. If you are behind a firewall or in a region where the default registry is slow, that variable is the one to set before running the script, not after.

After startup the README says the UI is reachable at http://localhost or http://<Your Public IP>. The default credentials are admin/admin123, and the same pair is published for the hosted demo at demo.mcpcan.com. A default administrator password that is identical across the demo and the shipped compose file is a real deployment hazard. Changing it is not optional advice here; it is the difference between a working install and an open control plane on a public IP.

The Helm path is referenced rather than documented inline. The README points to a separate Helm deployment guide and a charts index, and lists Kubernetes 1.28 in the stack badges. It does not give the chart name, the values keys, or the namespace conventions, so anyone deploying to Kubernetes should read the linked guide rather than infer from the compose setup.

Where MCPCAN is the wrong tool

The clearest limitation is scale of the wrong kind. MCPCAN is a platform with MySQL, Redis, Traefik, a Vue frontend, and at least two Go services. That is a reasonable footprint for a team running several MCP servers across environments. It is a poor fit for a single developer who wants one filesystem server available to one editor over stdio. In that case the server is a command in a config file, and adding a control plane means adding four moving parts that can each fail.

The second limitation is the state dependency. Because tokens live in Redis and instance metadata lives in MySQL, MCPCAN's availability is the product of its dependencies. The README does not describe a degraded mode, a fallback token store, or what happens to in-flight MCP sessions when the auth service restarts. For a system sitting in front of every agent's tool calls, that is an important unknown, and it is not answered in the material available.

The third is that container deployment changes what an MCP server can do. A server that needs to read local files, talk to a device, or inherit the user's environment is harder to run in a container than on the host. The README presents containerisation as the mechanism that resolves configuration conflicts, which is true for isolation, but it does not discuss servers whose whole purpose is host access.

Finally, the repository is young in release terms. The three most recent releases, v2.1.2 through v2.1.4, all landed within a nine day window in late March and early April 2026. That cadence is normal for active development and it also means the surface is still moving. Pinning a version rather than tracking main is the sensible default.

How it differs from running MCP servers directly or through a generic gateway

The obvious alternative is to skip the platform and run each MCP server yourself, either as a local process spawned by the client or as a container you manage with your own compose file or Kubernetes manifests. That approach has real advantages: no MySQL, no Redis, no auth service, and no upgrade treadmill other than the servers themselves. It also means every server's transport, credentials, and exposure are your problem individually, and there is no shared place to see which ones are healthy.

A second alternative is a general purpose API gateway in front of the MCP servers. Traefik, which MCPCAN already uses at the edge, can route and terminate TLS for HTTP services on its own. The difference is that a generic gateway does not know what an MCP server is. It cannot convert a stdio server into an HTTP endpoint, it does not manage instance lifecycle, and it has no concept of an MCP service token. MCPCAN's value sits in that MCP-specific layer: the instance registry, the protocol conversion, and the authz service that validates tokens before a call reaches a server.

A third comparison is the hosted route, where you point clients at a vendor's MCP endpoint and skip self-hosting entirely. That removes the operational burden but also removes the control over what the server can reach and where its data goes. MCPCAN is the self-hosted answer to that trade-off, which is also why the licence question below matters more than it would for a purely internal tool.

Licence, maintenance, and what the metadata does not settle

The licence is the least clear part of this project and the one with the most consequence. The repository metadata reports NOASSERTION, which means the licence could not be identified automatically. The README displays a badge reading Sustainable Use License. Those two signals do not resolve to the same set of terms, and the README does not link to a licence file or restate the conditions.

A Sustainable Use style licence is typically source-available rather than a standard open source licence, and such licences commonly restrict commercial resale or hosted service offerings while permitting internal use. I am not giving legal advice and I cannot tell you which terms apply here, because the material does not say. What I can say is that the gap between NOASSERTION in the metadata and a named licence in the README is a concrete thing to close before you build on this. Find the licence file, read it, and have someone who is allowed to make that call decide whether your intended use fits.

On maintenance, the signals are mixed in a way that is worth reading carefully. The project is not archived, the default branch is main, and the last push and the v2.1.4 release share the same timestamp of 2026-04-03, which indicates releases are cut from active work rather than a dormant tree. Three releases in nine days shows momentum. It does not show stability, and the README's own contributing section is still asking contributors to read a code of conduct and check existing issues, which is the standard shape of a project still building its process.

Upgrade cost is where the microservice split shows up. Upgrading means moving the web image, the market service, the authz service, and any schema changes MySQL needs, ideally together, since market and authz share a database. The README does not document a migration process or a compatibility matrix between platform versions and MCP server images, so the safe assumption is that a version bump is a coordinated deploy rather than a rolling one. Pin the image tags, read the release notes for each of v2.1.2, v2.1.3, and v2.1.4 before jumping, and treat the compose file as the source of truth for what actually gets started.

Editorial conclusion

Adopt MCPCAN if you already run Kubernetes or Docker Compose and you want a single control plane for several MCP servers, including the SSE to STREAMABLEHTTP conversion that clients like Dify need. Do not adopt it if you only run one local stdio server, or if your legal team needs a settled licence before you deploy: the repository metadata reports NOASSERTION while the README badge says Sustainable Use, and those are not the same thing. Verify two things before you commit. First, open the LICENCE file in the repository and confirm which terms actually apply. Second, run the Docker Compose path locally and confirm the MCPCAN-Authz service issues and validates tokens the way your existing clients expect, because the README describes RBAC and token verification as features without documenting the token format or the endpoints.

Official sources

1. Issues
2. Kymo-MCP/mcpcan on GitHub
3. Project website
4. README
5. Releases