# Remote or local GitHub MCP server: which should you run?

Source: https://forum.codelifter.com/posts/remote-or-local-github-mcp-server-which-should-you-run/
Site: CodeLifter Forum, category MCP and tools
Published: 2026-10-16. Updated: 2026-10-16. Replies: 0.

## Question by CodeLifter editors (staff), 2026-10-16

Run the remote server if you use github.com and your client supports remote MCP servers: there is nothing to install, and OAuth asks for scopes as tools need them. Run the local server if you use GitHub Enterprise Server, your client only supports local servers, or you want to choose when the server version changes.

## What each one is

Both come from the same repository. GitHub's [remote server documentation](https://github.com/github/github-mcp-server/blob/main/docs/remote-server.md) says the hosted version "is built using this repository as a library" and that GitHub "regularly update[s] the remote server to include the latest version of this code."

- **Remote.** GitHub runs it at `https://api.githubcopilot.com/mcp/`. Your client connects over HTTP.
- **Local.** You run it yourself, either as the public Docker image `ghcr.io/github/github-mcp-server` or by building the Go binary from `cmd/github-mcp-server` and running `github-mcp-server stdio`. Your client starts it as a local process.

Either way, the tools call the GitHub API with your credentials. The choice is about where the MCP process runs, who updates it and how you sign in, not about whether GitHub sees your requests.

## Side by side

| Factor | Remote | Local |
| --- | --- | --- |
| Install | None | Docker, or a Go build |
| Client requirement | Remote MCP support (the README names VS Code 1.101 or later, Claude Desktop, Cursor and Windsurf among others) | Any client that can start a local server |
| Sign-in | OAuth with scope challenges, or a personal access token | OAuth login on first use, or `GITHUB_PERSONAL_ACCESS_TOKEN` (the token takes precedence) |
| GitHub Enterprise Server | Not supported | Supported with `--gh-host` or `GITHUB_HOST` |
| GitHub Enterprise Cloud with data residency (ghe.com) | Supported, at `copilot-api.YOURSUBDOMAIN.ghe.com/mcp` | Supported with `GITHUB_HOST` |
| Choose toolsets | `X-MCP-Toolsets` header or `/x/{toolset}` URL | `--toolsets` flag or `GITHUB_TOOLSETS` |
| Read-only mode | `X-MCP-Readonly` header or `/readonly` URL | `--read-only` or `GITHUB_READ_ONLY` |
| Exclude tools | `X-MCP-Exclude-Tools` header | `--exclude-tools` or `GITHUB_EXCLUDE_TOOLS` |
| Extra toolsets | `copilot_spaces` and `github_support_docs_search` are remote only | Not available |
| Updates | GitHub updates it | You decide when to pull or rebuild |

The configuration rows come from the [server configuration guide](https://github.com/github/github-mcp-server/blob/main/docs/server-configuration.md); the rest from the repository [README](https://github.com/github/github-mcp-server). The README states plainly: "GitHub Enterprise Server does not support remote server hosting."

## The case for remote

The remote server is the shortest path for someone who wants to try MCP against github.com. With OAuth, the [scope filtering document](https://github.com/github/github-mcp-server/blob/main/docs/scope-filtering.md) says "when a tool needs a scope you haven't granted, you're prompted to authorize it," so you are not asked for every scope at the start. You also skip keeping a token in a config file.

Things to check first:

1. Your client must support remote servers and, for OAuth, the README notes that "Each MCP host application needs to configure a GitHub App or OAuth App." If yours has not, use a personal access token instead.
2. If you work in an organisation, the README lists "Any applicable policies enabled" as a prerequisite. An owner may need to allow it.
3. The URL form only takes one toolset (`/x/issues`, not `/x/issues,repos`). To combine toolsets, use the `X-MCP-Toolsets` header.

A minimal read-only setup in VS Code's `mcp.json`:

```json
{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "X-MCP-Toolsets": "repos,issues,pull_requests", "X-MCP-Readonly": "true" }
    }
  }
}
```

## The case for local

Run it locally when the remote option cannot work or when you want control over the process:

- **Enterprise Server.** Only the local server can point at your own host. The README says the host must use `https://`, and that "non-HTTPS hosts are refused" except for loopback hosts during local development.
- **Clients without remote support.** Any client that can launch a command can run the Docker image.
- **A fixed version.** The remote server changes when GitHub deploys it. Locally, nothing changes until you pull a new image or rebuild.
- **Isolation.** The Docker image runs in a container you start and stop. Add `--rm` so nothing is left behind.

A local setup with a token and the same limits:

```json
{
  "servers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "-e", "GITHUB_TOOLSETS", "-e", "GITHUB_READ_ONLY",
               "ghcr.io/github/github-mcp-server"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}",
        "GITHUB_TOOLSETS": "repos,issues,pull_requests",
        "GITHUB_READ_ONLY": "1"
      }
    }
  }
}
```

The README also documents an OAuth login for the local server: the Docker install buttons publish a callback port on `127.0.0.1:8085`, and the resulting token "is kept in memory only." If you use a token instead, the README's advice is to keep it in an environment variable, add `.env` to `.gitignore`, and run `chmod 600` on any config file that holds it.

## What does not change between them

Both versions support the same toolsets, read-only mode, excluded tools and lockdown mode. The configuration guide describes lockdown mode as "a best-effort content filter, not a security boundary," so do not treat it as protection on either side. Neither version reduces what your credential can do: the token or OAuth grant is the real limit. The thread on [which token scopes the GitHub MCP server needs](/posts/which-token-scopes-does-the-github-mcp-server-need/) covers how to keep that small.

## A short decision path

1. On GitHub Enterprise Server? Run local.
2. Client cannot connect to remote servers? Run local.
3. Need to pin the version for a team or a course? Run local.
4. Otherwise, start with remote in read-only mode, and add write toolsets only when a task needs them.

For a full list of tools and what each can change, see the CodeLifter [GitHub MCP server page](https://codelifter.com/mcp/github/). If you also give an assistant file access on your machine, the thread on [sandboxing the Filesystem MCP server](/posts/how-do-you-sandbox-the-filesystem-mcp-server/) covers the local side, and [who is the author of a commit made through an MCP server](/posts/who-is-the-author-of-a-commit-made-through-an-mcp-server/) covers what happens once writes are on.

---
Cite as: CodeLifter Forum, "Remote or local GitHub MCP server: which should you run?", https://forum.codelifter.com/posts/remote-or-local-github-mcp-server-which-should-you-run/, accessed 2026-10-16.