GitHub vs Forgejo: which to choose

GitHub vs Forgejo: when each fits a source hosting decision

GitHub fits best when managed operations and an existing Actions investment matter more than control over where code and CI run, and Forgejo fits best when a self-hosted, GPL-licensed forge with non-profit governance is the requirement. Most readers arriving here are facing a renewal, a data residency rule, a licensing change or a lock-in concern, and the answer depends on which of those is driving the decision. GitHub's strengths are a managed service, a large marketplace of Actions and integrations, and a developer base that already knows the interface. Teams with many workflows, reusable actions and third-party apps wired into GitHub will find that switching costs are real and should be counted before any migration is scheduled.

Forgejo fits when the organization wants the forge itself inside its own infrastructure, under a license that cannot be changed by a single vendor. Forgejo is licensed GPL-3.0-or-later from v9.0 onward, and Codeberg e.V., a non-profit association registered in Berlin, owns its domains while project governance stays independent. Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with it, so existing workflows need review, and runners must be operated by the team. Confirm the current LTS line on the Forgejo releases page before choosing a version, since LTS support windows drive how often the instance must be upgraded.

The decision turns on four things: CI, integrations, operating capacity and migration scope. Count the workflows, reusable actions, secrets and bots that depend on GitHub, and decide whether they are rewritten, kept on another CI system or retired. Assess who will patch, back up and upgrade the server, and whether that work is staffed or outsourced under a written scope. Finally, decide what must move: Git history can be cloned or mirrored, while issues, pull requests and reviews need the dump-repo and restore-repo commands, so test one representative repository end to end before committing to a date.

Which scenarios favor GitHub or Forgejo

This table maps common situations to the platform that usually fits better and the condition that tips the decision. Read each row as a starting point, then confirm the condition in your own environment before choosing. The main takeaway is that Forgejo fits best when self-hosting and independent governance are requirements, while GitHub fits best when the workflow library and hosted operations matter more than location.

Scenario	Better fit	Condition that makes it so
Data residency rules require self-hosting	Forgejo	Your regulator or contract requires source code and metadata to stay in facilities you control, and you can staff the server, backups and upgrades.
Large existing Actions workflow library	GitHub	Many workflows depend on marketplace actions and GitHub-specific features, since Forgejo Actions is designed to be familiar but is not compatible with GitHub Actions.
Small platform team without spare operations capacity	GitHub	Nobody can own patching, backups, upgrades and runner fleets, so a hosted service with vendor-run operations reduces the work you must staff.
Need for GitHub Enterprise Server-style self-management	Forgejo	You want software you run on your own infrastructure with an open-source license, and you accept that support comes from a different model than an enterprise vendor contract.
Need for an independent community forge	Forgejo	Your organization values a GPL-3.0-or-later project with governance independent of any single commercial vendor, with Codeberg e.V. holding its domains.
Existing Gitea installation to keep running	Forgejo	You can use the documented upgrade path from Gitea up to v1.22 in two steps, first to Forgejo v10.0.x and then to later versions.
Heavy reliance on GitHub Copilot or GitHub Marketplace integrations	GitHub	Your developers depend on those integrations daily, and moving them would cost more in lost productivity than hosting savings.
Need for a regular LTS track with a fixed support window	Forgejo	You plan around LTS releases published in the first quarter of each year, and you confirm the support dates for the release you adopt on the Forgejo releases page.

How Forgejo Actions differs from GitHub Actions

Teams whose workflows build, run tests and publish artifacts with a few steps usually have the smallest migration. Forgejo Actions is a built-in CI system that hands jobs to separate runners, and it is designed to feel familiar to people who already write GitHub Actions workflows. That familiarity covers the general structure of a workflow file, but Forgejo Actions is not compatible with GitHub Actions, so each file still needs a review against the Forgejo documentation before it runs.

Workflow location: Forgejo reads workflows from .forgejo/workflows and falls back to .github/workflows when the first folder is absent, so existing files may run without a move.
Runner setup: Jobs need at least one registered runner, which is a separate process you operate, so plan for its host, labels and updates.
Standard shell steps: Plain run steps that call compilers, test runners or deployment scripts usually carry over with little change.
Runner environment: Confirm the tools and images a job expects are present on your runner, since a hosted GitHub runner image includes many preinstalled tools.
Secrets: Repository secrets do not export from GitHub, so create them again in Forgejo before the first run.

Before cutover, run each simple workflow on a test repository and compare its output and logs with the GitHub run.

Workflows that depend on actions from the GitHub Marketplace need more attention. Many marketplace actions are published as GitHub-specific code that calls GitHub APIs or expects GitHub runner features, and those calls will not behave the same way on Forgejo. The safest path is to inventory every uses: line in your workflows and decide, action by action, whether to keep it, replace it with a shell step, or vendor a copy into your own repository.

Inventory first: List each external action with its version reference, since pinned tags and commit hashes behave differently from floating references.
Replace with shell steps: Many setup or packaging actions are thin wrappers over commands that a run step can call directly.
Vendor carefully: Copying an action into your own repository gives you control, but you then own its updates and its security review.
Check API dependence: Actions that create releases, comments or deployments through the GitHub API need a Forgejo equivalent or a rewrite.
Confirm compatibility: Test each retained action on a runner, because compatibility depends on the action's code, not only on its name.

Ask your platform team to produce this inventory before scheduling the migration, since it sets the real scope of the rewrite.

Organizations that share reusable workflows, composite actions and organization-wide templates across many repositories face the largest rework. A reusable workflow that GitHub resolves from a central repository must be reviewed for the paths, syntax and context values it depends on, and every caller in every repository must point to the new location. Because the change touches many repositories at once, sequence it deliberately and test one template before changing the rest.

Central templates: Move shared workflow repositories first, then update callers in batches so a single error does not block every project.
Context and expression differences: Review uses of github.* context values and any function or event that a Forgejo runner does not provide.
Versioning: Pin shared workflows to tags or commits so a template change does not silently alter running pipelines.
Runner pools: Size and label runners for the heavier jobs that shared templates create, and separate sensitive deployments onto controlled runners.
Audit trail: Keep a record of which workflow version ran for each release, since auditors often ask for it.

Confirm the exact behavior of reusable workflows in the current Forgejo Actions documentation and in your own pilot before committing a migration date.

What Forgejo's GPL license and Codeberg e.V. governance mean for buyers

Forgejo's license, domain ownership, governance and federation status each affect a different part of a buying decision. Read them separately, because a legal team, a procurement team and an architecture review will weigh them differently.

GPL-3.0-or-later license from v9.0

Forgejo is licensed GPL-3.0-or-later from v9.0 onward, while earlier versions were under MIT. The copyleft terms matter if you modify Forgejo and distribute the modified build to customers, partners or subsidiaries, because those recipients may receive source code rights. If you only run it internally, the obligations are usually lighter. Ask counsel to confirm which case applies to your deployment before you patch or fork the code.

MIT history before v9.0

Installations on releases before v9.0 fall under MIT, which is a permissive license. If your organization already runs an older Forgejo or a Gitea-derived build, check which version your copy is and which license applies to it. Mixed fleets of versions can mean mixed license terms, so record the version of each instance in your asset inventory and in your upgrade plan.

Non-profit domain ownership by Codeberg e.V.

Codeberg e.V., a non-profit association registered in Berlin, owns Forgejo's domains, while project governance stays independent. For buyers, this separates the project's name and web presence from any single company's commercial decisions. Ask your procurement team to record who holds the domains and trademarks you depend on, and to confirm how the project would handle continuity if the stewardship changed.

Independent project governance

Forgejo's governance does not sit with one vendor that sells a paid edition, which is the central difference from GitLab's model. Independence can make the roadmap more community-driven, but it does not replace contracted support. Commercial support for Forgejo comes from firms that offer it, so ask any provider you evaluate to name the support scope, response expectations and the release branches they cover.

Experimental federation over ForgeFed

Forgejo's federation is experimental and under active development, based on the ForgeFed protocol built on ActivityPub. Do not design a production workflow that depends on federating repositories, issues or pull requests between instances. If cross-organization collaboration is a requirement, treat federation as a future option and confirm its status in the current release notes before planning around it.

Compared with GitLab and Gitea

GitLab is open core: its Community Edition is MIT licensed, but files in the ee/ directory are proprietary and need a paid subscription. Gitea is MIT licensed, with commercial support available from CommitGo. Forgejo's GPL terms are stricter for redistribution, while its non-profit stewardship is different from both. Compare the license of each code path you will run, not only the headline license, and confirm with counsel which features your plan includes.

How Forgejo LTS releases and upgrades affect operations

Forgejo has two support tracks, and the one you choose decides how often your team must upgrade a production forge. Stable releases receive full support for three months plus a two-week window, which means a team on stable releases must plan a version change roughly every quarter. LTS releases, published in the first quarter of each year, receive critical bugfixes and security support for one year and three months. For an organization that cannot schedule upgrades every few months, the LTS track is the operational default to evaluate first, with the caveat that the support window is shorter than the time between two stable upgrades only if you skip releases.

Check the current dates on the Forgejo releases page before you commit to a version. At the time of writing, the listed release v15 is the LTS release supported until July 15, 2027, and v17.0.0 was released on October 15, 2026 with support until January 28, 2027. Build the upgrade calendar from those dates, not from memory, and confirm them again when you schedule each change window. Also confirm whether any patch releases fall inside your window, since security fixes arrive on the supported version only.

If you are migrating from Gitea, the upgrade path is a separate planning item. Forgejo documents a transparent upgrade from Gitea installations up to Gitea v1.22, and the Forgejo upgrade guide describes two steps: first to Forgejo v10.0.x, then to any later Forgejo version. Plan the first step as its own change with a tested backup of the database and the app.ini configuration file, and rehearse both steps on a copy of production. Gitea installations newer than v1.22 need an assessment before you move, so confirm your exact version with your implementation partner or in your own environment before you set a date.

Where repository data lives and who runs the platform

Choosing between GitHub and Forgejo is partly a decision about where source code, metadata and audit trails sit and who operates the software that holds them. The cards below separate hosting location, regional options, operator responsibilities, access control, audit logs and the compliance evidence you must produce yourself.

GitHub cloud and data residency

Standard GitHub.com stores repositories in GitHub's multi-tenant cloud, and you cannot choose where that storage sits. GitHub Enterprise Cloud with data residency on GHE.com offers EU, Australia, US and Japan regions, but it is a separate tenancy with its own URL and admin model. Ask GitHub which metadata, backups, Actions logs and support access stay inside the chosen region before you assume the whole service is regional.

GitHub Enterprise Server on your infrastructure

GitHub Enterprise Server runs as a self-managed appliance on infrastructure you operate, so repository data stays in your data center or cloud account. You still depend on GitHub's release cadence, appliance upgrade path and licensing terms, and your team performs patching, backups and capacity planning. Confirm which GitHub Enterprise Server release line your organization is on and how long each one receives support.

Forgejo on servers you control

A Forgejo instance keeps repositories, issues, pull requests and the database on hosts you choose, whether that is a private cloud, a data center or an air-gapped network. Nobody outside your organization holds the data or the admin keys unless you grant access. The trade-off is that your team owns backups, restores, database maintenance and incident response, which are the costs a hosted service absorbs for you.

Identity, access and audit trails

On GitHub, access runs through organization roles, SAML single sign-on and audit log features that depend on your plan. Forgejo uses its own accounts and teams, and you connect external identity through the authentication sources your administrators configure. Map who approves access, how offboarding removes tokens and SSH keys, and where audit records are retained, then test that export works before you migrate.

Who operates and supports the platform

Forgejo is governed independently, with Codeberg e.V. holding its domains as a non-profit association, so no single vendor controls the upgrade path. Commercial support for Forgejo is a matter for the operator or a third party you contract, and you should confirm that contract's scope in writing. Compare that with GitHub's paid support tiers and its single operator for the service.

Compliance evidence you still produce

Whichever platform you choose, auditors will ask for evidence of access reviews, change control, backup tests and retention settings, and that evidence comes from your system and your records. DeployOpen can prepare those controls, configuration baselines and evidence collection for your environment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.

How a GitHub to Forgejo move is structured

The move runs as a sequence: inventory, export and restore, re-platform automation and credentials, then a parallel period before cutover, so that repositories, their collaboration history and the teams using them land on Forgejo without a gap in service. Each stage produces a checkable output before the next one starts.

Inventory repositories, metadata and dependencies
Start by listing every repository in scope, its owners, default branches, open issues and pull requests, releases, wikis, Actions workflows, secrets, webhooks, GitHub Apps and OAuth integrations, and any package registries it publishes to. Note which repositories are large, because hosted Git services cap repository size, and check your own storage plan before you export anything. Owners of build, deployment and chat integrations should be named now. The output is a signed-off inventory that tells you which repositories move, in what order, and which teams must test afterwards.
Export history with clone or mirror
Mirror each repository with a bare Git clone so that every branch and tag comes across unchanged. Git history moves between any two forges this way, but it carries no issues, pull requests or reviews. Plan for the API rate limits on the source side if you script bulk reads of metadata, since the source platform throttles high-volume requests and a long export can stall. The output is a set of mirror clones, each checked by comparing branch and tag lists against the source.
Export and restore metadata with dump-repo and restore-repo
Use Forgejo's dump-repo command to export issues, pull requests, releases, labels, milestones, comments and wikis from GitHub, then restore-repo to load them into Forgejo. Run a trial on one non-critical repository first and compare issue counts, pull request states, comment threads and attachments with the source. Confirm in the Forgejo command-line documentation which fields come across for your version, and record any gaps for manual handling. The output is a restored repository on a staging Forgejo instance that a named owner has reviewed.
Re-platform Actions workflows and runners
Forgejo Actions is designed to be familiar to GitHub Actions users, but it is not compatible with GitHub Actions. Review each workflow in .github/workflows, check which marketplace actions and runner labels it depends on, and decide per workflow whether to keep it, adapt it, or replace it. Forgejo can fall back to .github/workflows for some setups, but you should verify that behavior against the Forgejo Actions overview for your version. Register runners in your own infrastructure. The output is a list of workflows with a status for each, and a green run for every workflow kept on staging.
Re-create secrets, tokens and access
GitHub Actions secrets do not export, so every secret used by a workflow must be re-entered in Forgejo by its owner, from the system that issued it. Recreate teams, roles and branch protection rules, and issue new personal access tokens and deploy keys for service accounts. Record who holds each credential and where it is stored. The output is a secrets register and an access matrix that the security team has checked against the GitHub inventory, with old tokens scheduled for revocation.
Redirect integrations and webhooks
Update every system that calls GitHub: CI triggers, deployment tools, chat notifications, issue links, package publishing, and any code-scanning or dependency bots. Point each webhook and API client at Forgejo and test it with a harmless event. Keep a short list of integrations that cannot be redirected yet, so they can run against the source for a limited period. The output is an integration map with each connection tested and its owner named.
Run a parallel period
Keep the GitHub repositories readable and let a pilot group develop on Forgejo while the mirrored repositories are kept in sync. Track failed builds, missing notifications and access complaints, and fix them before the cutover date. Ask your Forgejo support provider or internal team to confirm the upgrade path for the version you run, because a parallel period is also when you learn whether backups and restore tests work. The output is a list of resolved parallel-run issues and a restore test that succeeded on the Forgejo backup.
Cut over and retire the source
Freeze pushes to GitHub for each repository, run a final mirror and metadata sync, switch developer remotes and integrations to Forgejo, and then set the GitHub repositories to archived. Confirm that the last commit hashes match on both sides and that the new instance is included in backups. The output is a cutover record for each repository, showing the final commit, the time of freeze and the owner who signed off.

What drives the cost of running Forgejo versus GitHub

The cost comparison turns on who pays for what. On the GitHub side, the bill is made up of per-user seats on a Team or Enterprise plan, Actions minutes and storage consumed by workflows and packages. On the Forgejo side, there is no license fee, so the cost sits in servers or virtual machines, block and object storage, backup targets, a monitoring stack, the Forgejo Actions runners that execute jobs, and the staff time to operate all of it. No figures are given here. The structure of each line item, and what to ask for when pricing it, is laid out on the cost-by-component page, and the reader should fill in their own seat count, job volume and storage growth before comparing totals.

Most of the one-time cost is front-loaded. The migration itself (running dump-repo and restore-repo for each repository, checking issues, pull requests and wikis after restore, and rewriting workflows from .github/workflows to run on Forgejo Actions runners) is a project with a start and an end. Re-creating Actions secrets, which do not export from GitHub, and building the runner pool are also one-time tasks. Recurring cost is the operations side: patching and upgrades on the Forgejo release schedule, backup restore tests, runner capacity as build volume grows, certificate and monitoring upkeep, and the on-call time that a hosted service would otherwise absorb. Ask whether the upgrade and support model for the chosen Forgejo release line, including its LTS or stable support windows, is priced into the quote.

When requesting a quote, ask the provider to separate one-time work from retainers and to state each recurring item in its own line: infrastructure sizing for the Forgejo server and runners, storage and backup retention assumptions, upgrade cadence, security patch response, and any monitoring or on-call coverage. Ask for the assumed number of repositories, the volume of CI jobs, and the expected data growth, since these are the inputs that move recurring cost most. Compare that total with GitHub seats, Actions consumption and storage for the same period, and confirm that the quote excludes or includes staff time in a way your finance team can read.

Questions buyers ask before switching from GitHub to Forgejo

Can Forgejo run our existing GitHub Actions pipelines unchanged?

No. Forgejo Actions is built in and designed to feel familiar to GitHub Actions users, but it is not compatible with GitHub Actions, so workflows need review and adjustment. Forgejo's documentation describes the Actions overview and how workflows are handed to separate runners, which is the first place to check. Your team should inventory every workflow, third-party action, runner label and secret reference, then test each one on a Forgejo runner before cutover. Pipelines that depend heavily on GitHub-specific actions or context variables usually take the most rework.

How long does a move from GitHub to Forgejo take, and what drives it?

The duration depends on scope, not on a fixed rule. The main drivers are the number of repositories, how much metadata (issues, pull requests, reviews, wikis, releases) must come across, how many CI workflows need rework, and how many secrets must be re-created by hand, since Actions secrets do not export. Forgejo's dump-repo and restore-repo commands carry issues, pull requests, releases, labels, milestones, comments and wikis per repository, so a bulk move is largely scripted, while pipeline and access work is manual. Ask for a written scope with a repository inventory before accepting any timeline.

What does the work require from our team?

Three skill areas are needed: administration of a Forgejo server (or servers) with backups, TLS, identity integration and upgrades; CI engineering to port workflows and set up runners; and an owner who decides how permissions, branch protection and code review rules map to the new system. Your team also needs to agree on a cutover plan, including how developers update remotes and how open pull requests are handled. Each of these tasks has a recurring part, such as runner maintenance and patching, which should be assigned to a named owner before go-live.

Can a small team run Forgejo alone without outside help?

A small team can run Forgejo itself, because it is a single application with a database and documented upgrade paths. Whether it can do so safely depends on whether someone owns backups, restore tests, security patching, runner capacity and upgrades on a fixed schedule. Those duties recur every month, and they are the part most often underestimated. If no one on the team can absorb them, the choice is between hiring for them, using a support contract from a vendor that offers one, or a retainer for ongoing support, upgrades and testing. Confirm each duty by name before deciding.

Which Forgejo release should we pick, and why does LTS matter?

For production, most teams should start from the long-term support (LTS) release rather than the newest stable one. Stable releases receive full support for three months plus a two-week window, while LTS releases, published in the first quarter of each year, receive critical bugfixes and security support for one year and three months. Forgejo v15 is the LTS release supported until July 15, 2027, and Forgejo v17.0.0, released on October 15, 2026, is supported until January 28, 2027. Plan your upgrade calendar around the support end date of whichever release you run, and confirm current dates on the Forgejo releases page before you commit.

Is Forgejo federation ready for production?

No. Forgejo describes federation as experimental and under active development, built on the ForgeFed protocol, which is based on ActivityPub. Do not design a production workflow that depends on federating repositories or identities between instances. If cross-instance collaboration matters to you, treat it as a roadmap item and confirm its status with the Forgejo project before planning around it.

When should we choose GitLab or Gitea instead of Forgejo?

Choose GitLab when you want one platform for repositories, merge requests, CI/CD, package registries and related features, and you can accept a larger footprint and its open-core licensing model, where files in the ee/ directory are proprietary and need a paid subscription. Choose Gitea when you want a lightweight MIT-licensed forge with a built-in GitHub migration and commercial support available from CommitGo. Choose Forgejo when you want GPL-3.0-or-later licensing from v9.0 onward, governance independent of any single company, and a documented upgrade path from Gitea up to v1.22. Compare the three on licensing, CI approach, and who will support you, then test your heaviest workflows on each.

How DeployOpen helps evaluate and migrate to Forgejo

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a GitHub to Forgejo move, we start with a written scope that tests your repositories, workflows and access model against Forgejo before any cutover is planned.

How we scope

Inventory repositories, issues, pull requests, wikis, releases and Actions workflows that must move to Forgejo
Map which GitHub features your teams use and confirm which Forgejo equivalents or gaps apply
Agree deployment location, data residency needs and LTS version choice in writing before work starts

How we build

Deploy Forgejo in your cloud account, data center or air-gapped network with your identity provider integration
Run dump-repo and restore-repo trials on sample repositories and verify issues, pull requests and wikis
Rebuild Forgejo Actions workflows and runners, and test secrets re-creation and the .github/workflows fallback

How we hand over

Document the architecture, backup and restore procedures, upgrade steps and runner configuration for your staff
Deliver a migration runbook with cutover, rollback and redirect steps agreed with your engineering leads
Provide evidence of configuration and controls for your compliance team, noting that independent auditors issue any attestation

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer after handover
Track Forgejo release and support windows so your team plans upgrades ahead of end-of-support dates
Confirm with your team which support model fits, and request a quote based on the written scope

GitHub vs Forgejo