Add Streamable HTTP Transport Support for Multi-User Mode

[devendershekhawat]

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

1. Enterprise Shared Services: One server instance serving multiple teams/users
2. Cloud Deployments: Multi-tenant SaaS applications using GitHub integration
3. Web Integration: Web applications where users authenticate with their own GitHub tokens
4. Load Balancing: Distributing requests across multiple server instances
5. Kubernetes Deployments: Enabling proper health checks and service discovery
6. 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

1. 🌐 Production Ready: Enables production deployments in cloud environments
2. 🔄 Scalable: Works seamlessly with load balancers and auto-scaling
3. 🔌 Integration Friendly: Direct HTTP API for web applications and services
4. 📦 Container Native: Proper port binding for containerized deployments
5. 👥 Multi-Tenant: Support multiple users with their own GitHub authentication
6. ⚡ Performance: HTTP transport optimized for distributed scenarios

Acceptance Criteria

• New multi-user command that starts HTTP server on configurable port
• Per-request authentication tokens work correctly
• Multiple users can use the server simultaneously with their own tokens
• Backward compatibility with existing single-user modes
• Proper error handling and logging for multi-user scenarios
• Documentation for new multi-user mode
• Docker support for multi-user HTTP deployments

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.

[SamMorrowDrums]

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]

@devendershekhawat How did you deployed with streamable-http for single user, in docker container is not possible ?

[WZHBEDZ]

[SamMorrowDrums]

@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]

@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]

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]

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]

@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.

[rupinder2]

Any updates on when we can expect this feature to be available?

[almaleksia]

Hi 👋 You can use server-to-server tokens that allow to have a token per app, not per user (installation tokens). Notifications toolset won't be working though with installation token and also an app should have quite broad scopes enabled which is not very secure but can be acceptable in some cases.

[SamMorrowDrums]

👋 We're actively looking at improving GHES support for the MCP server! If you have thoughts on GHES-specific needs, please share your feedback in this discussion. 🙏