# MCPCan: Container-Based Management Platform for MCP Services

> MCPCan is an open-source platform that deploys each Model Context Protocol service into its own container, resolves configuration conflicts through isolation, and provides a web UI for monitoring, RBAC authentication, and multi-protocol access. It targets DevOps teams running multiple MCP services who need centralized lifecycle management without manual JSON editing.

**Kymo-MCP/mcpcan** — MCPCAN is a centralized management platform for MCP services. It deploys each MCP service using a container deployment method. The platform supports container monitoring and MCP service token verification, solving security risks and enabling rapid deployment of MCP services. It uses SSE, STDIO, and STREAMABLEHTTP access protocols to deploy MCP。

- Repository: https://github.com/Kymo-MCP/mcpcan
- Website: https://www.mcpcan.com
- Stars: 728 · Forks: 26
- Language: Go
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/kymo-mcp-mcpcan

## The Problem MCPCan Solves: MCP Service Conflicts and Management Complexity

Running multiple MCP (Model Context Protocol) services on the same host creates configuration conflicts: port collisions, dependency version mismatches, and credential sprawl across config files. MCPCan addresses this by deploying each MCP service in its own container, so dependencies stay isolated and ports are assigned without interference between services.

The platform is built for DevOps and development teams managing several services at once, not individual developers running a single local tool. The README positions it as a one-stop platform for the full MCP service lifecycle: deploy, configure, monitor, authenticate, and distribute. The container model also means that adding or removing a service does not affect the environment of other running services, which is a practical advantage during incremental rollouts.

MCPCan is distinct from simply writing Docker Compose files by hand because it also provides a web UI, RBAC, and token management without the operator needing to wire those systems together manually. The platform handles MCP-specific concerns such as protocol access and token verification as first-class features, not bolt-ons.

## Architecture: Microservices on Go, Vue 3, MySQL, and Redis

MCPCan uses a microservices architecture with three named components. MCPCan-Web, in the `frontend/` directory, is a management interface built on Vue 3.5 with Vite 7.0, Element Plus for UI components, Pinia 3.0 for state management, UnoCSS and SCSS for styling, and Monaco Editor for code editing within the UI. MCP-Market, at `backend/cmd/market/`, handles core business logic including the service marketplace and instance management. MCP-Authz, at `backend/cmd/authz/`, manages RBAC, user accounts, and department structures.

The backend is written in Go 1.25 using the Gin web framework for HTTP routing and gRPC with grpc-gateway for service-to-service communication. MySQL through GORM handles persistent data and Redis handles caching and token storage. Traefik acts as the edge gateway, routing traffic to the appropriate backend service. Docker SDK and Client-go handle container orchestration for Docker and Kubernetes respectively. LangChainGo and MCP-Go are listed as core libraries, indicating that the platform itself uses Go-based MCP tooling internally.

This stack is not lightweight. A full deployment brings up MySQL, Redis, Traefik, and at least two Go backend services before the first MCP service is managed. Teams accustomed to running MCPs as simple processes should account for this infrastructure requirement when evaluating MCPCan.

The repository layout reflects this separation of concerns. The `backend/` directory holds the Go services, `frontend/` holds the Vue 3 application, `deploy/` contains Docker Compose and Helm configurations, and `dockerfiles/` holds container build definitions. Build metadata is controlled by the `VERSION` file in the repository root, and the Makefile embeds the version, commit hash, and build timestamp into the Go binary at compile time using ldflags. The Makefile also defines multi-architecture build targets for `linux/amd64` and `linux/arm64`.

## Deploying MCPCan with Docker Compose

The recommended path for local development, testing, and lightweight production is Docker Compose. Clone the repository and navigate to the Docker Compose deployment directory:

```bash
git clone https://github.com/Kymo-MCP/mcpcan.git
cd mcpcan/deploy/docker-compose/
```

Initialize the environment file from the example, optionally modify settings such as `REGISTRY_PREFIX` to select between global or Chinese mirror registries, generate the final configuration, and start all services:

```bash
cp example.env .env
chmod +x replace.sh
./replace.sh
docker compose up -d
```

After the containers start, access the web interface at `http://localhost` or `http://<Your Public IP>`. The default credentials are `admin/admin123`. The README notes these defaults and expects them to be changed before any production exposure.

A live demo is available at demo.mcpcan.com with the same default credentials, which gives a preview of the interface without a local install. For Kubernetes deployments, official Helm charts are published at kymo-mcp.github.io/deploy/ and the Helm guide is linked from the deployment documentation. The README describes Docker Compose as suitable for local development and lightweight production, while Helm is the recommended path for Kubernetes environments.

## Protocol Support: SSE, STDIO, and Streamable HTTP

MCP services expose themselves through different transport mechanisms. MCPCan supports three: SSE (Server-Sent Events), STDIO, and Streamable HTTP. This matters in mixed environments where some services run as long-lived HTTP processes and others as command-line tools communicating over standard input and output.

The platform's protocol conversion capability lets a client that speaks one transport reach a service deployed over another. The README presents this as a key differentiator, describing the goal as enabling integration between different MCP service architectures without requiring each service to be rewritten to match a single transport. This is relevant when an organization has existing MCP services built independently by different teams, each choosing a different access method.

Token verification is part of the access layer. MCPCan validates tokens per service before allowing connections, which provides an authentication boundary between the management plane and the running MCP services. The README describes this as addressing security risks that arise when MCP services are exposed directly without access controls.

## Security, RBAC, and Token Management

MCPCan's authentication system covers two concerns: who can operate the platform, and who can reach each MCP service. The MCP-Authz component handles the first. It provides role-based access control, user accounts, and department-level groupings, which lets organizations assign management permissions by role rather than sharing a single admin credential. A DevOps engineer responsible for deploying services can hold different permissions from a developer who only reads service status.

For MCP service access, the platform's token verification sits in front of each deployed service. Before a client reaches an MCP service, MCPCan validates its token. This means the services themselves do not need to implement their own authentication, which simplifies service code at the cost of a dependency on MCPCan's token store. Rotating a token happens at the platform layer rather than inside each service.

The README also references a SECURITY.md for responsible disclosure of vulnerabilities in the platform itself. The repository includes a `.gitleaks.toml` configuration, indicating that secret-scanning tooling is part of the development workflow. The `.githooks/` directory suggests pre-commit hooks are also part of the standard development setup. A `.gitmessage` file defines a commit message template for contributors.

## Limitations: License Boundaries and Operational Overhead

MCPCan operates under a Sustainable Use License for its core platform, with enterprise features in `.ee` folders covered by a separate Enterprise License documented in LICENSE_EE.md. The README does not specify which features fall under the enterprise tier, which means teams planning commercial or production deployments need to read that file before committing. The repository's detected license field shows "NOASSERTION," reflecting that automated tooling cannot classify the Sustainable Use License.

The infrastructure footprint is a real constraint. Running MCPCan at all requires MySQL, Redis, Traefik, and the Go services in addition to the MCP services being managed. For teams running a small number of MCP services or running them only for development, this overhead is difficult to justify.

The platform is cloud-native in design, targeting Kubernetes with Helm as the production path. Teams not already operating Kubernetes infrastructure would need to stand up that capability before MCPCan can reach its intended deployment model.

## Comparing MCPCan to Manual Container Management

A team managing MCP services without MCPCan typically writes Docker Compose or Kubernetes manifests by hand, manages tokens in environment variable files, and monitors services through a general-purpose observability platform. Each new service means editing manifests, rotating tokens manually, and adding alert rules one at a time. This approach scales poorly when services are numerous or when team members outside DevOps need to interact with service configuration.

MCPCan replaces that manual work with a web UI that handles token issuance, protocol configuration, and service health in one place. The trade-off is that MCPCan itself becomes a dependency: if the platform is unavailable, management operations cannot complete, even if the individual MCP services keep running normally. Operators must also apply MCPCan updates independently of the services it manages.

For teams already operating Kubernetes, the operational model of MCPCan fits into existing infrastructure work. For teams that have never run a management platform before and are adding their first few MCP services, the overhead of MCPCan is likely higher than the overhead it saves. A team running two or three MCP services benefits less than one running a dozen or more across multiple environments.

## Conclusion

MCPCan suits teams already running multiple MCP services who want centralized management, protocol conversion, and RBAC in a single platform without building that infrastructure by hand. It is a wrong fit for single-service setups where Docker or Kubernetes overhead is not justified. Before adopting it, verify that the Sustainable Use License permits your deployment scenario: enterprise features in `.ee` folders are subject to a separate Enterprise License, which matters if your use case depends on those capabilities. The last push to the repository was on 2026-04-03.

## FAQ

### What MCP access protocols does MCPCan support?

MCPCan supports SSE (Server-Sent Events), STDIO, and Streamable HTTP. It also performs protocol conversion, so services built on different transports can be reached by clients that support only one of those access methods.

### How does MCPCan prevent configuration conflicts between MCP services?

MCPCan deploys each MCP service in its own container, which isolates dependencies, environment variables, and port assignments. Services do not share a host environment, so version conflicts and port collisions between services cannot occur.

### Can MCPCan be deployed on Kubernetes?

Yes. Official Helm charts are published at kymo-mcp.github.io/deploy/. The README describes Helm deployment as the recommended path for Kubernetes environments, while Docker Compose is recommended for local development and lightweight production.

## Sources

- [Issues](https://github.com/Kymo-MCP/mcpcan/issues)
- [Kymo-MCP/mcpcan on GitHub](https://github.com/Kymo-MCP/mcpcan)
- [Project website](https://www.mcpcan.com)
- [README](https://github.com/Kymo-MCP/mcpcan/blob/main/README.md)
- [Releases](https://github.com/Kymo-MCP/mcpcan/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kymo-mcp-mcpcan