Deployment guides
How to host an existing GitHub MCP server without losing control
A practical deployment checklist for repository owners: runtime compatibility, private access, secrets, consumer keys and a real first tool call.
Start with the server you actually have
A repository that runs on your laptop is a starting point, not proof that it can be offered as a remote service. Before choosing a host, identify the language, runtime version, package manager, entrypoint and transport. A stdio server reads and writes protocol messages through a local process; it does not automatically expose a public HTTP URL. Note whether it needs persistent files, browser automation, native dependencies or a long-lived session. Those requirements change the deployment design. For an initial rollout, choose one read-only workflow and one client rather than trying to support every tool immediately.
Pin the source and inspect the build
Use a specific commit as the release input. Inspect the lockfile, installation scripts and build command before executing repository code. A branch name can move between review and deployment; a pinned revision gives you something concrete to investigate later. Record which command builds the project and which compiled file starts the server. If a build produces dist/index.js, verify that the file actually exists after a clean build. A successful package installation is not a successful MCP deployment. Also check the repository license and your right to host or distribute its functionality.
Keep repository access separate from runtime secrets
Private repository credentials authorize reading source code. Upstream credentials authorize the business actions performed by tools. They are different permissions and should not be bundled into one token. Limit repository access to the required repository, and keep tokens out of image layers, build output and copied client configurations. Pass upstream credentials through the hosting system’s supported secret mechanism. Before storing any customer credential, establish whose account it accesses and whether the deployment serves one customer or several. A shared upstream account does not provide per-user data isolation just because each caller has a different gateway key.
Give each consumer an independent key
Create a named consumer key for each integration, environment or test client. Start with only the tool calls it needs, add an expiry where practical, and choose a rate limit that matches the intended workflow. Test revocation and a denied call as well as the happy path. The distinction between tool visibility and tool execution matters: an execution allowlist is not a promise that every upstream server hides disallowed tool metadata. Never paste a live key into a repository README, screenshot or support conversation. Store it in the client’s intended credential field.
Prove the complete connection
Check the hosted endpoint from outside the runtime network. Initialize the MCP connection using the client’s supported protocol revision, list the tools, and make one read-only call against known test data. Confirm that the response came from the intended upstream system and that the request appears in operational history. Try a missing key, a revoked key and a deliberately exceeded request limit. If the client requires OAuth or a legacy SSE endpoint, an API-key-only JSON connection is not a substitute. Resolve that mismatch before the customer starts onboarding.
Define a useful handoff
For MCP Ops guided early access, the repository import path currently supports Node.js stdio servers. Public repositories and scoped private-repository access can be reviewed; GitHub App installation and universal runtime support should not be assumed. The hosted gateway uses Streamable HTTP with JSON responses and consumer bearer keys. A useful handoff includes the pinned commit, entrypoint, secret names—not their values—endpoint, permitted tools and a repeatable acceptance check. Keep the customer’s original working deployment until the hosted workflow has passed that check. Request a deployment review if your repository needs a different runtime or authentication model.
git rev-parse HEAD
git status --shortRead-only commands. Run inside your repository.