Gitea vs GitHub
Gitea and GitHub are both Git platforms with official MCP servers, and the comparison is essentially self-hosted-and-lightweight versus hosted-and-ubiquitous. Gitea is the self-hosted, lightweight Git service written in Go, and its official server connects an agent to your own Gitea instance over an access token so it can create and fork repos, manage branches and tags, read and write files, open and review pull requests, file and edit issues, cut releases, manage org labels and secrets, drive Gitea Actions CI/CD, and even edit the wiki. GitHub's official server connects to the GitHub platform — reading repo files, searching code across all of GitHub, managing issues and pull requests, inspecting commits and releases, and driving Actions — with tools grouped into toolsets you can enable selectively to keep context lean. Both cover the full repo workflow; the decision is where your code lives and how you want to run the server. Here is how they compare.
How they compare
| Dimension | Gitea | GitHub |
|---|---|---|
| Where your code lives | Your own self-hosted Gitea instance — point the server at any Gitea server you operate; ideal when you keep source inside your own infrastructure. | The hosted GitHub platform, including code search across all of GitHub — the default home for open source and most teams' repos. |
| Workflow coverage | Repos, branches and tags, files, full PR review flows, issues, releases, org labels and secrets, an extensive Gitea Actions toolset (secrets, variables, workflows, runs, jobs, logs), and wiki CRUD. | Repos and files, code search across GitHub, issues and pull requests, commits and releases, and Actions, organized into toolsets (repos, issues, pull_requests, actions, code_security, dependabot, discussions, projects, and more). |
| Context management | Surface grouped by area (user/org lookup, repo and branch management, commits and files, PR reviews, releases, Actions, wiki). | Selectable toolsets so you enable only what a given agent needs and keep its tool list and context lean. |
| Deployment and auth | Local stdio or an HTTP server, configured with GITEA_HOST and GITEA_ACCESS_TOKEN (or --host/--token); canonical install is the official Docker image, with binaries and a Go module also published. | Hosted remote endpoint at api.githubcopilot.com/mcp/ with OAuth for interactive clients or a PAT for headless use; a local Docker image reads GITHUB_PERSONAL_ACCESS_TOKEN. |
| Best-fit task | Teams running their own Gitea who want a first-party way to put a coding agent to work on a self-hosted platform, including its CI and wiki. | Teams on GitHub who want the backbone integration for acting on real repositories, with cross-GitHub code search and security toolsets. |
Verdict
Pick by where your repositories live. Choose the Gitea server if you self-host on Gitea and want an agent that operates your own instance end to end — repos, PR reviews, issues, releases, Gitea Actions, and even the wiki — with a Docker-first install and a host/token config. Choose the GitHub server if your code is on GitHub and you want the ubiquitous integration: cross-GitHub code search, selectable toolsets (including code security and Dependabot), and a hosted OAuth endpoint. Both cover the full repo workflow; the real axis is self-hosted control (Gitea) versus the hosted GitHub ecosystem and its breadth. Teams that mirror to both can run each server against its platform.
FAQ
- Can the Gitea server search code across all repositories like GitHub?
- It searches within your Gitea instance (repos, users, and content there), but it cannot search across all of GitHub — that cross-platform code search is a GitHub-server feature, since GitHub hosts those repositories centrally.
- How do I run each server?
- Gitea's canonical install is its official Docker image (with binaries and a Go module too), configured via GITEA_HOST and GITEA_ACCESS_TOKEN. GitHub offers a hosted remote endpoint with OAuth or a PAT, plus a local Docker image reading GITHUB_PERSONAL_ACCESS_TOKEN.