GitHub Enterprise Server vs Forgejo: when each one fits
Many teams reach this comparison because their self-managed GitHub appliance costs more to keep current than they expected, or because a licensing or hardware review has asked whether a lighter forge would serve the same developers. Forgejo fits when the goal is a smaller self-hosted footprint, predictable long-term support through its LTS releases, and a path for teams already running Gitea, since Forgejo documents transparent upgrades from Gitea up to Gitea v1.22. GitHub Enterprise Server fits when the organization depends deeply on GitHub-hosted features, when GitHub Actions workflows must run unchanged, or when a vendor-backed appliance and its support model are a procurement requirement. The reader should not assume that either choice is cheaper by default.
The decision turns on three factors. The first is workflow compatibility: Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions, so every workflow, action reference and self-hosted runner setup needs an inventory and a test before any commitment. The second is pull request and issue volume and shape: teams should count open repositories, review load, issue history and wiki content, and confirm which of these a platform importer can carry across, because Git history moves with a clone or mirror while the rest needs a tool such as dump-repo and restore-repo. The third is staff capacity: someone must own upgrades, backups, runners and access control on either platform. Ask the reader's own team how many hours per month that work can absorb and whether it has an on-call path, then confirm the current appliance's required hardware and support terms with GitHub before comparing totals.
A practical check is to run a pilot with a representative set of repositories and one real pipeline, including a restore test, before choosing. Document the results against the Forgejo release and support dates published on forgejo.org, and compare them with the GitHub Enterprise Server release schedule in the vendor's documentation. If the workflow inventory shows heavy GitHub Actions use that must stay unchanged, or if the organization's procurement requires the appliance vendor's support, GitHub Enterprise Server may remain the better fit even with its higher upkeep. If the workflows are modest and the team wants a smaller platform it can operate, Forgejo is a strong candidate to test first.
Which option fits each scenario
This table maps common situations to the better fit between GitHub Enterprise Server and self-hosted Forgejo. Read each row against your own constraints, since the advantage in the Why column depends on the stated condition. Most of the decision turns on how much of your workflow depends on GitHub Actions, GitHub-specific integrations and the appliance's operating model.
| Scenario | Better fit | Why |
|---|---|---|
| Many existing GitHub Actions workflows | GitHub Enterprise Server | Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with it, so workflows need rewriting and testing. The advantage holds only if rewrite effort is acceptable to the team. |
| Small platform team with limited hardware | Forgejo | Forgejo is a lighter self-hosted forge than the GitHub Enterprise Server appliance, which is sized partly by license count and Actions load. Confirm the footprint for your user count and CI volume in a test environment. |
| Regulated site that must keep all code on premises | Forgejo | Both run on your own infrastructure, so location is not the differentiator. Forgejo's open license and smaller operating model can simplify evidence collection, but the choice should be checked against your assessor's expectations. |
| Team migrating from Gitea | Forgejo | Forgejo documents transparent upgrades from Gitea up to Gitea v1.22 in two steps. This matters only if you run Gitea today; teams on GitHub Enterprise Server need a platform importer instead. |
| Need for GitHub-specific integrations or apps | GitHub Enterprise Server | Third-party GitHub Apps, marketplace actions and tooling built against GitHub's APIs may not work unchanged on Forgejo. Inventory every integration and confirm compatibility before deciding. |
| Deciding after a licensing renewal | Depends on the renewal terms | Compare the per-user Enterprise license and appliance upgrade effort with Forgejo's LTS schedule and migration work. Ask for the renewal cost, the appliance hardware plan and a migration estimate in writing before choosing. |
Does a lighter footprint reduce operating effort?
A smaller forge can reduce hardware, upgrade and backup work, but only when your real load is modest. The saving depends on how many repositories you host, how many Actions or CI jobs run each day, how much large binary content sits in Git or Git LFS, and how many users push at the same time. A team with a few hundred developers, light CI and little binary content will feel the difference more than a team running heavy pipelines against large artifacts. Before you assume a lighter footprint, write down those four numbers from your current GitHub Enterprise Server instance and use them as the basis for every comparison.
The GitHub Enterprise Server appliance is a fixed unit with its own sizing and maintenance cycle. Ask GitHub for the current hardware requirements for your user count and your Actions usage, in writing, and confirm whether they differ by appliance release. Also confirm the procedure and downtime for each feature upgrade, the backup and restore steps the appliance supports, and how long your team must stay on a supported release. Those answers, not the marketing footprint, determine how many people your operations team needs to keep the instance current.
Forgejo's footprint is not fixed by the software. It depends on the database you choose, the number and placement of Forgejo Actions runners, the storage backend for repositories and attachments, and whether you run a reverse proxy, backups and monitoring on the same hosts. Those choices can make a small deployment cheap to run or make it as heavy as the appliance. The only reliable sizing evidence is a load test using your own repositories, your own CI workload and your own peak push and clone patterns, run before you commit to a hardware plan or a migration date.
GitHub Enterprise Server vs Forgejo, capability by capability
This table compares GitHub Enterprise Server and Forgejo across the capabilities teams check first: repositories, review, CI, registries, identity, audit, federation and migration. Where the research does not settle a cell, it says what to confirm and with whom. The main takeaway is that core repository workflows and migration are well covered, while CI compatibility, registries, identity and audit need checking against your specific version before you plan a move.
| Capability | GitHub Enterprise Server | Forgejo |
|---|---|---|
| Repositories and pull requests | Git repositories and pull requests with branch protection and merge controls, administered on your own appliance. | Git repositories and pull requests with merge options and branch rules; confirm the exact merge settings for your version. |
| Code review | Inline review comments, suggested changes and required approvals on pull requests. | Inline review comments and approvals on pull requests; confirm required-review rules for your version. |
| Issues and labels | Issues, labels and milestones scoped to repositories and organizations. | Issues, labels and milestones, all of which the dump-repo export carries across. |
| CI | GitHub Actions workflows run on self-hosted runners attached to the appliance; plan runner capacity and Actions limits. | Forgejo Actions runs workflows on separate runners and is designed to feel familiar to GitHub Actions users, but workflows are not compatible with GitHub Actions. |
| Package and container registries | Confirm with GitHub which package types are enabled on your appliance version and how they are backed up. | Confirm with the Forgejo documentation which package and container formats your version supports before migration. |
| SAML and SSO | SAML single sign-on is part of the Enterprise offering; confirm supported identity providers and provisioning options with GitHub. | Confirm the supported SSO methods and identity providers for your Forgejo version in the Forgejo documentation. |
| Audit logging | Confirm with GitHub which administrative and user events are logged, retention periods and export options. | Confirm which administrative and repository events are logged and how they can be exported as compliance evidence. |
| Federation | Not covered by the supplied research; confirm with GitHub before relying on cross-instance sharing. | Experimental and under active development, using the ForgeFed protocol based on ActivityPub; do not plan production use around it yet. |
| Import and export tooling | Confirm with GitHub's migration documentation how issues, pull requests and wikis can be exported from the appliance. | dump-repo exports a repository from git, GitHub, Gitea or GitLab with issues, pull requests, releases, labels, milestones, comments and wiki; restore-repo loads it into Forgejo. |
What licensing and release cadence commit you to
Licensing and release cadence decide what you pay, how often you upgrade and who controls the upgrade calendar. GitHub Enterprise Server ties cost to users and moves on a feature-release clock, while Forgejo is free software with two support tracks. The four cards below set out what each commitment means for your budget and your upgrade plan.
GitHub Enterprise Server per-user licensing
GitHub Enterprise Server is licensed per user under GitHub Enterprise, so your license count moves with headcount and any contractor access you grant. The appliance must also stay on a supported feature release, and each one receives about a year of support. That means upgrades recur on the vendor's schedule, with their own downtime and hardware checks. Open the GitHub Enterprise Server releases page and note the end-of-support date for the release you run today. Ask your account team how license counts are reconciled at renewal.
Forgejo's GPL-3.0 license
Forgejo is licensed GPL-3.0-or-later from v9.0, and earlier versions remain under MIT. Codeberg e.V., a non-profit association registered in Berlin, owns the Forgejo domains, while project governance stays independent of that association. For you, the license carries no per-user fee and no single vendor controls the roadmap. Copyleft obligations do apply when you distribute modified binaries to others, so ask counsel how those terms interact with internal changes and with your vendor contracts before you fork anything.
Forgejo's two release tracks
Stable releases receive full support for three months plus a two-week window, so a stable track means planning upgrades several times a year. LTS releases are published in the first quarter of each year and receive critical bugfixes and security support for one year and three months, which suits teams that want fewer upgrades. v17.0.0 was released on October 15, 2026 with support until January 28, 2027. Check the releases page before choosing a track, because a stable release can leave support sooner than an LTS line.
Staying current on each side
On GitHub Enterprise Server, your team must track the end-of-support date for each feature release and complete the appliance upgrade before it closes, including the 3.19 end date. On Forgejo, choose LTS or stable deliberately, subscribe to release announcements and keep a tested upgrade path. If you come from Gitea, follow the documented two-step route through Forgejo v10.0.x. On either platform, staging, backups and a rollback plan remain your responsibility unless a support retainer covers them. Assign a named owner to each calendar entry.
How hosting and data control differ by environment
In a connected data center or private cloud, both GitHub Enterprise Server and Forgejo run inside infrastructure your team controls, so repositories, issues, pull request data, CI logs and backups stay in your storage accounts or on your hypervisor. The difference is the software and its upkeep. GitHub Enterprise Server is a virtual appliance that your team upgrades on the vendor's release schedule, while Forgejo is an application you install on your own Linux hosts, with the database, reverse proxy and runners configured by you.
- Data location: Repositories, the database, attachments and Forgejo Actions logs sit on volumes you choose. Confirm the backup target and retention for each.
- Patching: Your platform team applies appliance upgrades for GHES and operating system and Forgejo updates for the rest of the stack, so the patch owner is named in your runbook.
- Identity: Connect the forge to your directory through the authentication options each product supports, and confirm which login methods and group mappings are available in your version.
- Auditor evidence: Expect requests for the running version, the upgrade history, backup restore tests, access reviews and admin audit logs.
Confirm with each vendor which features your chosen version supports before you commit to an identity or logging design.
On an air-gapped network, nothing reaches the public internet, so every upgrade, package, runner image and dependency must be moved in by a controlled transfer. Hosted or cloud-linked features are unavailable, and the platform team has to plan for offline installation media, internal mirrors and a documented process for importing updates. Forgejo runs as a self-contained application with its own runners, which makes the dependency list shorter, but the team must still stage every component.
- Data location: All code, issues, CI logs and backups stay on internal storage. Backup copies to removable or separate media need a documented chain of custody.
- Patching: Your team builds the update bundle, scans it and imports it through an approved change window. Security fixes arrive only when someone carries them across the boundary.
- Identity: Use an internal directory or a self-hosted identity provider. Confirm that no login path depends on an external service.
- Auditor evidence: Expect records of each transfer, checksums of imported artifacts, offline restore tests and the list of software versions in use.
Confirm with each vendor which installation and update paths they support offline, and how they document them.
In a regulated environment with data residency rules, the question is where each copy of the data lives and who can reach it. GitHub offers a data residency option for GitHub Enterprise Cloud on GHE.com, which lists EU, Australia, US and Japan regions. That is a hosted service with its own controls, not your appliance, so you must check which region applies to your data and which records the vendor keeps. Azure DevOps stores customer data in the geography chosen for the organization but keeps tokens and SSH keys in a US datacenter. A self-hosted forge avoids these split locations, but it moves the controls onto your team.
- Data location: With a self-managed forge, you choose the region and the backup location. Confirm that mirrors, object storage and CI artifacts follow the same rule.
- Patching: Your organization owns the patch cycle. Check whether a hosted option gives you different responsibilities for updates.
- Identity: Map who can view source and secrets by jurisdiction, and confirm where authentication logs are kept.
- Auditor evidence: Expect a data flow diagram, a register of storage locations, access logs, and records showing that residency rules were tested.
Confirm which regions and controls apply to your own infrastructure with each vendor and your legal team before you assume any residency guarantee. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the reports and certifications.
What GitHub Enterprise Server and Forgejo cost to run
The cost of GitHub Enterprise Server is mostly recurring and tied to seats, while the cost of Forgejo is mostly one-time setup plus the infrastructure and people that run it. GitHub Enterprise Server carries per-user Enterprise licenses, appliance hardware sized for the license count and Actions volume, blob storage, backups, and the staff time spent on upgrades and maintenance windows. Forgejo has no license fee under GPL-3.0-or-later, so its line items are servers or virtual machines, storage, backup targets, Forgejo Actions runners, staff time, and any optional support contract. Ask your vendor and your own team to confirm which of these lines apply to your environment before comparing totals.
Separate one-time costs from recurring ones before comparing. One-time costs on the Forgejo side include migration of repositories, issues, pull requests and wikis (the dump-repo and restore-repo commands cover repositories, issues, pull requests, releases, labels, milestones, comments and wikis), Forgejo Actions runner setup, integration with your identity provider, hardening, and documentation. The same kinds of work apply when you leave GitHub Enterprise Server, so count them on both sides. Recurring costs on both sides include licenses or subscriptions, patching, upgrades, backups, runner capacity and monitoring. Forgejo's LTS releases, which receive critical bugfixes and security support for one year and three months, are a useful input when you estimate how often upgrade effort will recur.
Cost drivers are user count, Actions job volume, storage growth and upgrade frequency. Every additional developer adds a GitHub Enterprise Server license and sizing headroom, while on Forgejo the main driver is runner capacity and storage for artifacts and large repositories. Ask for a written quote that states the scope (users, repositories, Actions workload, integrations and migration sources), the sizing assumptions for CPU, memory, storage and runners, the upgrade plan with its expected downtime and rollback steps, and the handover, including documentation and who runs each recurring task afterward. A quote that cannot show these items cannot be compared with another.
What a move from GitHub Enterprise Server to Forgejo involves
The sequence moves repositories, Actions workflows, runners and access from the GitHub Enterprise Server appliance into a Forgejo environment you run, with a tested rollback before the appliance is retired.
Scope repositories and integrations
Your team lists every organization, repository, team, webhook, GitHub App, OAuth application and external tool that depends on the GitHub Enterprise Server instance, and marks which ones must move in the first wave. Engineering leads and the platform team own the list, and the output is a signed-off inventory with an owner for each item. Confirm the repository sizes, large file usage and any Git LFS content before you choose the first wave, because these affect export time and storage in the target environment.
Confirm export limits on your instance
Before you plan the export window, confirm the API rate limits and bulk export constraints that apply to your GitHub Enterprise Server instance, including the token type and any administrative limits your site sets. GitHub's published limits for hosted services, such as its 5,000 REST requests per hour for personal access tokens, are a useful baseline, but your appliance configuration may differ. The check is complete when your team has a written figure for each limit and a schedule that fits within it.
Inventory Actions workflows and runners
Your DevOps team catalogs every workflow file, reusable workflow, composite action, marketplace action, secret, variable and self-hosted runner used on the appliance. Each workflow is tagged as one of three groups: runs unchanged, needs small edits, or needs a rewrite. Forgejo Actions is designed to feel familiar to GitHub Actions users, but it is not compatible with GitHub Actions, so the group assignment must be verified on a test runner, not assumed. The output is a migration backlog for CI with an owner for each pipeline.
Build the target Forgejo environment
Your infrastructure team deploys Forgejo in your own cloud account, data center or isolated network, with a database, storage, backups, TLS, and separate Forgejo Actions runners for the workloads identified in the previous step. Security and platform engineers configure authentication, logging and access controls to match your policies. The environment is ready when a test repository can be created, a pull request reviewed, and a sample runner job completed, and when restore from backup has been tested once.
Run a pilot export and restore
On a non-production copy of a representative repository, your team runs the Forgejo dump-repo command against the source to export git data with issues, pull requests, releases, labels, milestones, comments and wiki where the source supports them, then runs restore-repo to load it into Forgejo. Compare commit counts, branches, tags, issue numbers, pull request state, review comments, attachments and wiki pages against the source. Note what does not carry over, such as GitHub-specific metadata or app integrations. The pilot is complete when the differences are documented and accepted by the repository owners.
Migrate identities and permissions
Your identity team maps GitHub Enterprise Server users, teams and repository roles to Forgejo accounts, organizations and teams, and decides how single sign-on and SSH keys will be provisioned. Access is granted from the approved inventory rather than copied wholesale, so that dormant accounts and stale tokens do not move. The check is a reconciliation report that shows each active user and team, the role it received, and any user who needs a manual decision.
Cut over with a rollback plan
Your team schedules the production wave in agreed order, freezes pushes to each repository during its final export, updates remotes, webhooks and CI references, and keeps the GitHub Enterprise Server instance read-only but intact. A written rollback plan states who can revert remotes and re-enable the appliance, and what happens to commits made in Forgejo during the window. Each wave closes with a sign-off from the repository owners that the latest commits, pull requests and pipelines work in the new system.
Retire the appliance after data is confirmed
Once every wave is signed off and a defined retention period has passed, your team takes a final backup or archive of the GitHub Enterprise Server data, documents its location and access controls, and then shuts down the appliance and releases its hardware and licenses. The retention period and archive requirements should come from your records, legal and compliance owners, not from this page. If you run Gitea rather than GitHub Enterprise Server, Forgejo documents transparent upgrades from Gitea up to Gitea v1.22 in two steps, first to Forgejo v10.0.x and then to a later Forgejo version, which matters only for that case. Confirm the current upgrade path with the Forgejo upgrade guide before you plan it.
How much effort does a GitHub Enterprise Server to Forgejo move take?
How long does a GitHub Enterprise Server to Forgejo migration take?
The duration depends on the number of repositories, the size of their history, the number of Actions workflows and the integrations that point at the server, so no single figure applies to every estate. Forgejo's dump-repo and restore-repo commands can move git data plus issues, pull requests, releases, labels, milestones, comments and wiki for each repository, but the workflow rewrite, identity setup and integration testing usually take longer than the data copy itself. Ask for a timeline in the written scope that lists each phase and its exit criteria, rather than relying on a generic estimate.
What does the migration need from our own team?
The work needs named owners on your side for source control administration, identity and single sign-on, CI and deployment, and the business teams that approve cutover. It also needs read access to the GitHub Enterprise Server instance, an administrator account that can run exports, and a test environment that mirrors the target Forgejo configuration. Plan agreed change windows for the final sync and DNS or remote URL switch, and confirm who can approve rollback. Without these, most delays come from waiting for access or approvals rather than from the technical move.
Can our own engineers migrate to Forgejo without outside help?
Yes, for small estates where engineers are comfortable with Git, Linux administration and reverse proxy configuration. Check that you have people who can size and install the server, script repository exports and imports, rewrite CI workflows and test pull request and review history after the move. Count the repositories, workflows, webhooks, deploy keys and external integrations first, since those lists determine whether an internal project is realistic. Larger or regulated estates often bring in an implementation partner for the cutover, testing and evidence, with a fixed scope agreed in writing.
Can Forgejo Actions run our existing GitHub Actions workflows unchanged?
No. Forgejo Actions is built as a built-in CI system with separate runners and is designed to be familiar to GitHub Actions users, but it is not compatible with GitHub Actions. Workflow files, action references, secrets handling and runner labels usually need rewriting and testing, so your workflow inventory is one of the largest effort drivers. Review which third-party actions your pipelines depend on and confirm each one has a working equivalent or an alternative approach before cutover.
How does Forgejo's LTS schedule affect migration planning?
Forgejo publishes LTS releases in the first quarter of each year, and those receive critical bugfixes and security support for one year and three months, while stable releases receive full support for three months plus a two-week window. The current LTS line is v15, supported until July 15, 2027, and v17.0.0 is supported until January 28, 2027. Plan your target version against those dates, and schedule the post-go-live upgrade path before the chosen release leaves support. Confirm the current support table on the Forgejo releases page at the time you sign the scope.
How are large files and Git LFS objects handled during the move?
Large files and LFS objects need separate handling because a standard clone or dump does not guarantee that every LFS object reaches the target. Inventory repositories that use LFS or contain large binaries, and check their size against the limits of the source platform. Hosted services set their own caps, such as GitHub's 100 MB file limit and 2 GB push limit, so an estate that relies on large files may need storage changes on the new server. Test a large repository end to end, verify object counts and checksums, and confirm storage capacity for backups before the cutover.
What does a support retainer cover after the Forgejo go-live?
After go-live, a support retainer covers ongoing operation tasks that the team still needs help with, such as upgrades to later Forgejo versions, backup checks, security patching, monitoring, user and access changes, and responses to incidents. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the exact coverage, response expectations and frequency are set in the written scope. Ask whether the retainer includes upgrade testing against your workflows and integrations, and whether it covers the Forgejo release cycle you have chosen.
What should we ask for in a fixed-scope migration quote?
Ask for a written scope that lists the repositories and their size, the list of workflows to rewrite, the integrations and webhooks to re-point, and the identity and access model for the new server. The quote should separate one-time work, such as the export, import, workflow rewrite and cutover, from recurring work, such as retainer support and upgrades. Confirm which deliverables you receive, including runbooks, backup and restore tests, and cutover records, and what the acceptance criteria are. Cost mainly moves with the number of repositories, workflows and integrations, so use your inventory to compare quotes on the same basis.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For GitHub Enterprise Server vs Forgejo, we start from your repositories, CI workloads and governance needs, then decide with you whether Forgejo fits or another forge does.
How we scope
- Inventory repositories, pull request volume, Actions workloads and LFS or large-file usage before any comparison
- Agree in writing which Forgejo features, runners and identity integrations are in scope
- Confirm with Forgejo documentation which Actions workflows need changes, since Forgejo Actions is not GitHub Actions compatible
How we build
- Install and size Forgejo in your environment, with the hosting, storage and backup layout you choose
- Test a migration rehearsal with a sample of repositories, using the dump-repo and restore-repo commands and issue or wiki checks
- Test security controls, access policies and runner isolation against your written requirements
How we hand over
- Deliver configuration, runbooks and migration reports as documented artifacts your team keeps
- Document the upgrade path from any existing Gitea installation and the Forgejo version you adopt
- Prepare control evidence for your compliance assessment; independent auditors issue any audit reports or certifications
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer
- Ask for a quote based on the written scope, which covers runner hardware, storage and migration effort
