MCP Github Server Docker Image not compatible for GKE deployment due to no persistent server mode

[samarthgaggar]

Describe the bug

The Docker image defined at dockerfile currently does not appear to support a persistent server or daemon mode. As a result, when deploying this image on Kubernetes, the pod remains in a "CrashLoopBackOff" state because the container process exits immediately.

Would it be possible to add a persistent server or daemon mode to the image, so that the main process continues running? This would enable successful deployment and operation within Kubernetes environments. Thank you for considering this.

Affected version

docker run -i --rm ghcr.io/github/github-mcp-server ./github-mcp-server --version
GitHub MCP Server
Version: v0.4.0
Commit: e9f748f246761fb0769e2a5611003939a6274872
Build Date: 2025-05-23T13:06:55Z

Steps to reproduce the behavior

1. Access to a Google Kubernetes Engine (GKE) cluster with kubectl configured.
2. A valid GitHub Personal Access Token
3. Create the Kubernetes Secret

kubectl create secret generic mcp-github-secret \
  --from-literal=key=<YOUR_GITHUB_TOKEN>

4. Create your deploy.yaml file (Example)

apiVersion: apps/v1kind: Deployment
metadata:
  name: mcp-github-server
  labels:
    app: mcp-github-server
  annotations:
    description: "Deployment for MCP GitHub server"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mcp-github-server
  template:
    metadata:
      labels:
        app: mcp-github-server
    spec:
      securityContext:
        fsGroup: 2000
      containers:
      - name: mcp-github-server
        image: ghcr.io/github/github-mcp-server:latest
        command: ["./github-mcp-server", "stdio"]
        env:
        - name: GITHUB_HOST
          value: https://github.com/github    
        - name: GITHUB_PERSONAL_ACCESS_TOKEN
          valueFrom:
            secretKeyRef:
              name: mcp-github-secret
              key: key
        - name: GITHUB_TOOLSETS
          value: "repos,issues,pull_requests,code_security,experiments"
        ports:
        - containerPort: 3001

5. Apply the Deployment YAML

kubectl apply -f deploy.yaml

6. Check Pod Status

kubectl get pods

Expected vs actual behavior

Expected Behavior

The Docker image should run in a persistent server or daemon mode, keeping the main process active so that the container remains running.When deployed as a Kubernetes pod, the container should stay in a healthy, running state, supporting typical Kubernetes workloads and allowing for reliable orchestration and scaling.

Actual Behavior

The current Docker image does not include a persistent server or daemon mode; the main process exits immediately after starting.As a result, when deployed in Kubernetes (e.g., on GKE), the pod enters a "CrashLoopBackOff" state because Kubernetes expects the container to keep running, but it exits instead, causing repeated restarts.

Logs

• kubectl get pods

NAME                                 READY   STATUS             RESTARTS         AGE
mcp-github-server            0/1     CrashLoopBackOff   31 (3m54s ago)   137m

• kubectl logs mcp-github-server

GitHub MCP Server running on stdio

• kubectl describe

-Events:
  Type     Reason   Age                    From     Message
  ----     ------   ----                   ----     -------
  Normal   Pulling  3m35s (x33 over 141m)  kubelet  Pulling image "ghcr.io/github/github-mcp-server:latest"
  Warning  BackOff  97s (x644 over 141m)   kubelet  Back-off restarting failed container mcp-github-server in pod mcp-github-server-###)

[manku211]

hii , same issue im facing with stdio , can we do without mcp-proxy , I dont want to change in sse , any thoughts ?

[samarthgaggar]

Hi @williammartin - Please suggest if GKE compatible dockerfile/Image available for us to try?

[williammartin]

I'm not really sure what the issue is here. When you run the docker image with the command ./github-mcp-server stdio it starts a long running server process that interacts over stdio. The server will run until signalled or there is an error:

github-mcp-server/internal/ghmcp/server.go

Lines 233 to 239 in c7a872b

	case <-ctx.Done():
	logrusLogger.Infof("shutting down server...")
	case err := <-errC:
	if err != nil {
	return fmt.Errorf("error running server: %w", err)
	}
	}

What am I misunderstanding?

[samarthgaggar]

Thanks @williammartin for your response. If I use the same image locally, it works fine. However, when I use the same image in a GKE deployment (as specified in the file provided in the original description), the pod fails to start successfully (It remains in "CrashLoopBackOff" status). Here is the output:

kubectl get pods
NAME                                 READY   STATUS             RESTARTS      AGE
mcp-github-server-5555b6bf78-2g2q2   0/1     CrashLoopBackOff   3 (17s ago)   65s

kubectl logs mcp-github-server-5555b6bf78-2g2q2
GitHub MCP Server running on stdio

kubectl get events 
0s          Normal    Created             pod/mcp-github-server-5555b6bf78-2g2q2    Created container: mcp-github-server
0s          Normal    Started             pod/mcp-github-server-5555b6bf78-2g2q2    Started container mcp-github-server
0s          Warning   BackOff             pod/mcp-github-server-5555b6bf78-2g2q2    Back-off restarting failed container mcp-github-server in pod mcp-github-server-5555b6bf78-2g2q2_mcp-git(e2fd6b99-e3be-485e-bf1d-564aac172a1c)
0s          Warning   BackOff             pod/mcp-github-server-5555b6bf78-2g2q2    Back-off restarting failed container mcp-github-server in pod mcp-github-server-5555b6bf78-2g2q2_mcp-git(e2fd6b99-e3be-485e-bf1d-564aac172a1c)
0s          Warning   BackOff             pod/mcp-github-server-5555b6bf78-2g2q2    Back-off restarting failed container mcp-github-server in pod mcp-github-server-5555b6bf78-2g2q2_mcp-git(e2fd6b99-e3be-485e-bf1d-564aac172a1c)

Additionally, I tried to work around the issue by modifying lines 19–26 in the Dockerfile, as shown below. I did this assuming the application inside the container might be exiting with a non-zero status or missing some dependencies. However, this approach did not resolve the problem either.

I am wondering if the image ghcr.io/github/github-mcp-server has been tested on a GKE cluster?

# Use alpine as the base image for runtime
FROM alpine:3.18

# Install any runtime dependencies (if needed)
RUN apk add --no-cache ca-certificates

# Set the working directory
WORKDIR /server

# Copy the binary from the build stage
COPY --from=build /bin/github-mcp-server .

# Ensure the binary is executable
RUN chmod +x github-mcp-server

# Command to run the server
CMD ["./github-mcp-server", "stdio"]

[williammartin]

There's almost no chance that the image has been tested on a GKE cluster, sorry. I think what's unclear to me here is how you are handling the stdio streams in your deployment.yaml. I suspect what's happening is that k8s is starting the pod and closing stdin, resulting in the server exiting. How are you intending to connect to the stdio streams for usage?

[samarthgaggar]

Thanks @williammartin for clarifying that. Reason for GKE deployment so that MCP GitHub server can act as fully remote production MCP server that functions like standard web service to centralize the broader AI ecosystem within an organization. This also helps in one place to manage and easy to discover MCP server instead of running various docker containers locally (which is even harder for Non Technical Teams to follow)

How it works:

• MCP server runs as a web service accessible via HTTPS (not rely on stdin)
• AI clients connect directly without local configuration or proxies (configuration through LLM application settings UI rather than JSON files)
• Authentication happens through standard OAuth 2.1 web flows (Credentials managed through OAuth tokens, not local files)

Is it possible to release another or enhance existing dockerfile https://github.com/github/github-mcp-server/blob/main/Dockerfile to support to include certificate management and server configuration for HTTPS? If not, any suggestions how to address this for remote server deployment such as GKE.

[williammartin]

MCP server runs as a web service accessible via HTTPS (not rely on stdin)

This is never going to work right now, sorry. There is no support in this OSS project for the HTTP transport. If you want that right now, you'll have to build it yourself or wait for someone else to. Currently, the intention is for GitHub to host a server, so it's not a priority to work on introducing it here.

[manku211]

is there any other way we can deploy stdio mcp-server on kubernetes, I have checked smithery deployed their stdio mcp-server also, @williammartin

[williammartin]

@manku211 I don't have any experience hooking up stdio streams to k8s pods. I guess my main question would be "how are you intending to connect to the stdio streams in order to send it RPC requests?". Maybe you can point me to what you're seeing with smithery? I suspect that they wrap stdio servers in an http adapter.

[samarthgaggar]

Thanks for the update @williammartin . Need to explore mcp-proxy to establish a connection from stdio to SSE/HTTP. However, there are still questions about how to host a remote server for HTTP transport.

[manku211]

"Hi @williammartin, thanks for the clarification on the HTTP transport limitations.
Following up on my earlier question about deploying stdio MCP servers on Kubernetes without mcp-proxy - I have a broader use case I'd like to discuss:
I need to deploy multiple MCP servers on a Kubernetes cluster and make them available to users simultaneously. Given that the stdio model doesn't work well with K8s (as we've established), I'm exploring options for:

Multi-server K8s deployment: What's the best architectural approach for running multiple MCP servers concurrently on Kubernetes?
Transport layer conversion: Is there any way to convert the stdio communication to streamable HTTP connections that would be more K8s-friendly?

I see that Smithery has managed to deploy their stdio MCP server (as I mentioned earlier) - I'm curious about the general patterns or workarounds that might be viable for cloud deployments.
Any guidance on architectural approaches or potential solutions would be really helpful. I understand the current limitations but want to explore what's possible within those constraints.

[williammartin]

Multi-server K8s deployment: What's the best architectural approach for running multiple MCP servers concurrently on Kubernetes?

I have no idea, sorry. I'm not involved at all in running MCP servers on kubernetes or otherwise.

Is there any way to convert the stdio communication to streamable HTTP connections that would be more K8s-friendly?

It seems like mcp-proxy linked above would satisfy that.

Your questions would probably be better asked on the MCP discord.

[samarthgaggar]

@manku211 - I have tried https://github.com/smithery-ai/reference-servers/tree/main/src/github but still having same issue at GKE. Are you able to run GKE pod successfully for MCP Github server?

[manku211]

@samarthgaggar I am changing my dockerfile and install mcp-proxy server inside it and running mcp-proxy command at CMD level so it changes stdio to streamable http and this file im deploying on gke and it is working fine , smithery does not give its architecture document , how they are deploying exactly for stdio.