-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Description
Problem
Currently, the GitHub MCP Server only supports single-user mode, requiring a single GitHub token to be configured at startup. This limits its usage in multi-tenant environments, shared services, and enterprise scenarios where different users need to authenticate with their own GitHub tokens.
Current State
- ✅ Single-user mode supports both stdio and streamable HTTP transports
- ❌ No multi-user mode exists - server requires one GitHub token per instance
- ❌ Cannot serve multiple users with different authentication contexts
- ❌ Limited scalability for shared or enterprise deployments
Proposed Solution
Add a new multi-user mode with streamable HTTP transport support, enabling the server to:
- Accept HTTP requests with per-request authentication tokens
- Serve multiple users simultaneously with their own GitHub tokens
- Run behind load balancers and reverse proxies
- Integrate with web applications and cloud services
- Support containerized deployments with proper port binding
Use Cases
- Enterprise Shared Services: One server instance serving multiple teams/users
- Cloud Deployments: Multi-tenant SaaS applications using GitHub integration
- Web Integration: Web applications where users authenticate with their own GitHub tokens
- Load Balancing: Distributing requests across multiple server instances
- Kubernetes Deployments: Enabling proper health checks and service discovery
- API Gateway Integration: Direct HTTP endpoints for API management platforms
Expected Implementation
Command Interface
# New multi-user mode with HTTP transport
./github-mcp-server multi-user --port 8080
# Existing single-user modes still work
./github-mcp-server stdio # Single-user stdio
./github-mcp-server streamable-http # Single-user HTTP
Configuration Options
- Configurable port binding via
--port
flag - Per-request authentication token extraction from request headers/context
- No global GitHub token required - tokens provided per request
- Backward compatibility with existing single-user modes
Technical Details
- Utilize existing
server.NewStreamableHTTPServer()
from mcp-go library - Implement per-request authentication model with auth tokens
- Create new multi-user toolsets that extract tokens from request context
- Proper error handling and logging for HTTP transport
- Support for standard HTTP headers and content types
Benefits
- 🌐 Production Ready: Enables production deployments in cloud environments
- 🔄 Scalable: Works seamlessly with load balancers and auto-scaling
- 🔌 Integration Friendly: Direct HTTP API for web applications and services
- 📦 Container Native: Proper port binding for containerized deployments
- 👥 Multi-Tenant: Support multiple users with their own GitHub authentication
- ⚡ Performance: HTTP transport optimized for distributed scenarios
Acceptance Criteria
- New
multi-user
command that starts HTTP server on configurable portPer-request authentication tokens work correctlyMultiple users can use the server simultaneously with their own tokensBackward compatibility with existing single-user modesProper error handling and logging for multi-user scenariosDocumentation for new multi-user modeDocker support for multi-user HTTP deploymentsTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Additional Context
This enhancement would introduce a completely new operational mode to the GitHub MCP Server, making it suitable for enterprise and multi-tenant deployments. Unlike the current single-user model where one GitHub token is configured globally, this multi-user mode would extract authentication tokens from each individual request.
The implementation should leverage the existing mcp-go library's streamable HTTP capabilities while introducing a new multi-user authentication approach that differentiates this mode from the existing single-user implementations.
Activity
SamMorrowDrums commentedon Jun 7, 2025
We are releasing a remote server soon, and using this repo as a library so we will not be accepting PRs adding this functionality to this repo.
Thanks for your interest in the project, I hope our server offering will resolve this issue for you.
WZHBEDZ commentedon Jun 16, 2025
@devendershekhawat How did you deployed with streamable-http for single user, in docker container is not possible ?
WZHBEDZ commentedon Jun 16, 2025
SamMorrowDrums commentedon Jun 16, 2025
@WZHBEDZ you cannot from the docker container. You can use this:
https://github.blog/changelog/2025-06-12-remote-github-mcp-server-is-now-available-in-public-preview/
WZHBEDZ commentedon Jun 16, 2025
@SamMorrowDrums Thanks for answer, but we need to deploy mcp by ourself. We are using github enterprise. We can't use public one. STDIO one which is implemented not good interface for connection to other tools.
SamMorrowDrums commentedon Jun 16, 2025
Ah that makes sense @WZHBEDZ I hope we might be able to host the remote server for GHES too at some stage.
I'll bring this back to internal team as feedback.
WZHBEDZ commentedon Jun 16, 2025
Thanks a lot @SamMorrowDrums, but what is reason why you didn't put publicly how to deploy mcp to have http endpoint ? I assume you already have code for that ?
We could just run docker container and deploy it easily, why GITHUB needs to host that?
SamMorrowDrums commentedon Jul 4, 2025
@WZHBEDZ so its much more than just a docker container. For remote server we want to support oauth which means that there are multiple endpoints that need to be supported.
Our server also doesn't handle the auth, we have a reverse proxy that handles the auth in front of our server.
Our http server also has to support horizontal scaling which adds complexity and there are also lots of GitHub internal Kubernetes parts.
It's not trivial to host the MCP server safely remotely, and it's not trivial for us to provide what we have built as a single container, because we depend on other internal services.
I agree it would be nice to support other protocols for this repo, I just worry because several parts of the implementation for stdio are not safe from many user to server scenarios OOTB.