Forgejo vs Gitea: when each one fits
The choice between Forgejo and Gitea turns on four things: licensing stance, Actions compatibility, support model and whether an existing Gitea install has to move. Teams answering to security, compliance or procurement should settle those four before comparing feature lists, because each one changes what a contract, a pipeline or a migration plan can assume. Forgejo is licensed GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT, and Codeberg e.V. owns its domains while project governance stays independent. Gitea is MIT licensed, and CommitGo, Inc. provides leadership and commercial support for it. Start by asking legal and procurement which license terms they will accept for the forge, then have them confirm how those terms affect your modifications and internal distribution.
Choose Forgejo when GPL-3.0-or-later terms, a non-profit steward and a published LTS track matter more to your governance than a vendor-backed commercial tier. Forgejo LTS v15 is supported until July 15, 2027, and v17.0.0 is supported until January 28, 2027, so plan upgrade windows around those dates. Choose Gitea when MIT terms, a commercial support contract or the Gitea Enterprise controls, such as SAML 2.0 service provider support, audit logging and mandatory two-factor authentication, are part of the requirement. Gitea Actions is designed to be compatible with GitHub Actions, while Forgejo Actions is designed to feel familiar to GitHub Actions users without being compatible with it, so reuse of existing workflows points toward Gitea.
Use five drivers to score the decision: license terms, governance, CI workflow reuse, paid features and upgrade path. For the upgrade path, check whether your current Gitea install is on v1.22 or earlier. Forgejo documents an upgrade from Gitea up to v1.22 in two steps, first to Forgejo v10.0.x and then to a later Forgejo version. Installs on later Gitea lines, including the v1.27 line, need the migration route confirmed before you commit, and you should rehearse it on a copy of the data. For CI, inventory the workflows and actions you depend on and run them on both runners. Finally, list the Enterprise controls your auditors expect and get support terms in writing before procurement signs.
Which platform fits which team scenario
This table matches common team situations to the platform that fits them better, with the condition that would reverse the choice. Read each row as a starting point, then check the licensing, upgrade and feature details against your own requirements and your current Gitea version.
| Team scenario | Better fit | Reason | When the other platform fits better |
|---|---|---|---|
| Existing Gitea install that must stay on a supported path | Forgejo | Forgejo documents transparent upgrades from Gitea up to Gitea v1.22, done in two steps: first to Forgejo v10.0.x, then to any later Forgejo version. | If you already run a Gitea release above v1.22, the documented Forgejo path does not cover you directly. Confirm the supported route with both projects before planning. |
| CI workflows already written for GitHub Actions | Gitea | Gitea Actions is designed to be compatible with GitHub Actions, so existing workflow files are more likely to carry over. | Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with it, so Forgejo fits teams that can rewrite or adapt workflows. |
| Organization that needs SAML 2.0 service provider support or audit logging | Gitea | Gitea Enterprise from CommitGo, Inc. adds SAML 2.0 service provider support and audit logging, along with IP allowlisting and mandatory two-factor authentication. | If you require the GPL-3.0-or-later license and do not need commercial features, Forgejo is the fit. Confirm which of these features Forgejo provides in your target version. |
| Team that requires GPL-3.0-or-later terms and published LTS windows | Forgejo | Forgejo is licensed GPL-3.0-or-later from v9.0 onward. LTS releases are published in the first quarter of each year and receive critical bugfixes and security support for one year and three months. | Gitea is MIT licensed, so teams with permissive-license preferences may prefer it. Confirm Gitea's release support windows directly with the project before comparing them to Forgejo's. |
| Team that wants a managed option | Gitea | Gitea is offered as Gitea Cloud, a managed service, alongside self-hosted installs. | Forgejo's public instance, Codeberg, accepts only free and open source projects with no availability guarantees, so it does not replace a managed service for private company code. Self-host Forgejo if you need control of the environment. |
| Organization that needs a federated or community-governed forge with independent project governance | Forgejo | Forgejo project governance stays independent, and Codeberg e.V., a non-profit association registered in Berlin, owns its domains. | Forgejo federation is experimental, so teams that need federation today should not rely on it. Gitea is the choice if you prefer a single commercially supported vendor relationship with CommitGo. |
| Team that needs many package registry types from one forge | Gitea | Gitea supports more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts. | Confirm the registry types Forgejo provides in your target version before choosing it for a package-heavy workflow. |
| Small server or constrained hardware, such as a Raspberry Pi | Gitea | Gitea runs on Linux, macOS and Windows, including small systems such as a Raspberry Pi, and supports MySQL, PostgreSQL, SQLite and MSSQL. | Confirm the supported operating systems and database backends for Forgejo in its documentation before deciding, especially if MSSQL is required. |
What the licenses and paid editions actually cover
Forgejo is licensed under GPL-3.0-or-later from v9.0 onward, and earlier versions were published under MIT. The change matters most if you plan to modify the code and redistribute your changed build, since GPL-3.0 requires that redistributed modifications stay under the same terms. Codeberg e.V., a non-profit association registered in Berlin, owns the Forgejo domains, while project governance is documented as independent of that ownership. The license itself carries no paid tier, so the cost of running Forgejo is the staff, infrastructure and support you arrange around it.
- Version boundary: Builds from v9.0 onward carry GPL-3.0-or-later, and anything older falls under MIT.
- Stewardship: Codeberg e.V. holds the domains, and the Forgejo FAQ describes project governance as independent.
- No paid edition: The supplied facts describe no commercial Forgejo edition, so support and hardening are contracted separately.
- Redistribution: Internal use and redistribution carry different obligations under GPL-3.0.
Confirm with your counsel which Forgejo versions your environment uses and what GPL obligations apply if you ship a modified build to others.
Gitea is licensed under MIT and written in Go. MIT is a permissive license that allows modification, redistribution and use in proprietary products as long as the copyright notice is kept. For many organizations, this is simpler to document than a copyleft license, especially where internal policy favors permissive terms. The core Gitea project is the MIT-licensed code, and CommitGo, Inc. sells commercial support and the Gitea Enterprise edition on top of it.
- Permissive terms: MIT requires preservation of the copyright and license notice, and does not require derivative works to be released.
- Core features: Git hosting, code review, package management and CI/CD are described as part of the self-hosted software.
- Gitea Cloud: A managed service is also offered alongside self-hosted installs.
- Commercial layer: Paid features come from the Enterprise edition, not from relicensing the core.
Confirm with your counsel whether an MIT notice requirement fits your distribution model, and confirm with CommitGo which features ship in the MIT core versus Enterprise.
Gitea Enterprise is the paid edition from CommitGo, Inc., and it adds features that the supplied facts list as Enterprise-only. These features mainly address identity, audit and access controls, which are common requirements in regulated environments. Pricing and terms come from CommitGo and are not stated in this page, so request a written quote that lists the features and support level. Forgejo has no equivalent paid edition in the supplied facts, so compare controls directly against your own requirements.
- SAML 2.0 service provider: Adds SAML 2.0 service provider support for single sign-on.
- Audit logging: Records administrative activity for review.
- Branch protection inheritance: Applies branch protection at the organization level.
- IP allowlisting and mandatory 2FA: Restricts access by network address and requires two-factor authentication.
- Dependency scanning: Reports on vulnerable dependencies in repositories.
Ask CommitGo to show how each feature is configured and whether it works with your identity provider and log pipeline.
The supplied facts do not describe a paid Forgejo edition with features that are locked behind a license. If you need controls such as SAML service provider support, audit logging or IP allowlisting on Forgejo, you need to confirm whether they exist in the release you run, or whether you must build or configure them with other tools. This is a question for your own testing rather than something to assume from the license alone. Ask whether any control you need is a configuration option, a plugin, or an external component you must operate.
- Check each control: Test SAML, audit logs and access restrictions in a staging instance before relying on them.
- Identify external components: Some controls may depend on a reverse proxy, firewall or log platform.
- Plan support: Any engineering needed to close gaps is scoped and priced separately.
- Track release changes: Feature availability can change between releases, so verify against each version.
Confirm the feature list for your target Forgejo version before you compare it with the Gitea Enterprise list.
How each forge is built and what that means for operations
Forgejo and Gitea share a Git hosting core and a similar feature set, so the differences that matter show up in operations. The cards below cover the parts that change day-to-day work: the CI model, the database and registry scope, federation status, and the upgrade path. Confirm each against the version you plan to run.
Shared Git hosting core
Both products run Git hosting, code review, team collaboration and CI/CD from a single service, so one process, one database and one set of backups cover most of the platform. Backups must capture repository data, the database and attachments together, or a restore can produce repositories without matching issue or review records. Ask each vendor for its documented backup procedure for the version you run, and test a full restore before go-live.
Actions CI with separate runners
Forgejo Actions and Gitea Actions both hand jobs to runners that are separate processes from the forge. Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with GitHub Actions, while Gitea documents its Actions as designed to be compatible. Check whether your existing workflows, actions and runner images work unchanged, and budget runner patching, capacity and secret handling as ongoing work.
Database backend support
Gitea documents MySQL, PostgreSQL, SQLite and MSSQL as supported databases. SQLite suits small single-node installs, while PostgreSQL and MySQL support the separate database backups and high availability most regulated teams expect. Forgejo's supported list is not confirmed in this research, so confirm its database matrix in the Forgejo documentation before you commit to a backend or a migration path.
Package registry scope
Gitea supports more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts. If your teams publish several of these formats from one forge, this affects how many registries you back up and patch. The Forgejo registry count is not confirmed in this research, so list the package types you need and check each one against Forgejo's current documentation.
Federation status
Forgejo federation is experimental and under active development, built on the ForgeFed protocol, which is based on ActivityPub. Gitea does not have an equivalent in the supplied facts. Treat federation as a roadmap item rather than a production dependency: do not plan cross-instance workflows, identity or data sharing on it until the feature is stable and your own tests pass.
Upgrade path from Gitea
Forgejo documents transparent upgrades from Gitea up to Gitea v1.22, performed in two steps: first to Forgejo v10.0.x, then to a later Forgejo version. Installs on newer Gitea lines need a different plan, so confirm your exact version before you schedule the change. Take a full backup, rehearse the two-step path on a copy of production, and check every extension, runner and Actions workflow after each step.
How Forgejo and Gitea compare on the features that decide the choice
This table sets Forgejo and Gitea side by side on the capabilities that usually decide a self-hosted Git forge choice. Where a value is not established for one platform, the cell names what to confirm with that vendor. Read the Actions, support window and database rows first if you rely on existing GitHub Actions workflows or plan to upgrade from Gitea.
| Capability | Forgejo | Gitea |
|---|---|---|
| License | GPL-3.0-or-later from v9.0 onward; earlier versions under MIT | MIT licensed and written in Go |
| Governance | Codeberg e.V., a non-profit in Berlin, owns the domains; project governance stays independent | CommitGo, Inc. provides leadership and commercial support |
| Actions compatibility with GitHub Actions | Built-in CI designed for GitHub Actions users, documented as not compatible | Gitea Actions designed to be compatible; test your own workflows to confirm |
| LTS or support windows | v15 LTS supported until July 15, 2027; LTS releases get one year and three months of security support | Ask CommitGo which release lines receive long-term support and for how long |
| Paid edition | Confirm with the Forgejo project whether a commercial edition or paid support exists | Gitea Enterprise adds SAML 2.0, audit logging, IP allowlisting and mandatory 2FA |
| Managed offering | Confirm with the Forgejo project or hosting providers which managed options exist | Gitea Cloud is offered as a managed service alongside self-hosted installs |
| Federation | Experimental, built on the ForgeFed protocol over ActivityPub, under active development | Confirm with CommitGo whether federation is available and how mature it is |
| Package registries | Confirm which package and registry types your target Forgejo version supports | More than 20 registry types, including npm, PyPI, Maven, container images and Helm charts |
| Database backends | Confirm supported database backends for your target version before sizing | MySQL, PostgreSQL, SQLite and MSSQL; runs on Linux, macOS and Windows |
How governance and the fork history affect long-term risk
The fork history matters most because it decides who can change the license, the release calendar and the commercial terms of the software you will run for years. Forgejo began as a community fork of Gitea, and the two projects now have different stewards. Codeberg e.V., a non-profit association registered in Berlin, owns the Forgejo domains, while project governance stays independent of that ownership. Gitea is maintained with leadership and commercial support from CommitGo, Inc., which also sells Gitea Enterprise. For a buyer, the practical question is how much weight you place on a single commercial company steering the roadmap and the paid edition, compared with a steward whose income does not depend on selling licenses.
Governance risk matters most when your organization is regulated, when you already worry about vendor lock-in, or when your Git forge will hold code that must stay under your own control for a long time. In those cases, ask both projects for their written license terms for the version you plan to deploy. Forgejo is licensed GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT, so confirm which license applies to any older build you inherit. Gitea is MIT licensed. Also confirm which Enterprise features your audit or access-control requirements depend on, because those features are sold by CommitGo, not supplied by the community project. Ask CommitGo how it would handle the Enterprise terms if it changed ownership or direction, and write that answer into your contract or risk register.
Governance risk matters less when your team runs only community features, can migrate between forges without much effort, and already keeps repository backups and exports in standard Git form. Git data is portable whichever fork you choose, so the real exposure is in the surrounding configuration, CI workflows, package registries and identity integration. Plan a periodic exit test: restore a copy of your instance, confirm that repositories, users and Actions workflows survive, and record the time it takes. Keep the upgrade path in view as well, since Forgejo documents transparent upgrades from Gitea up to Gitea v1.22 in two steps, which gives a Gitea shop a defined route to evaluate the fork without an immediate rebuild.
Moving an existing Gitea install to Forgejo
This sequence takes a running Gitea instance through the documented upgrade path into Forgejo, with backups and checks at each stage so the team knows what moved, what needs rebuilding and when the migration is safe to close. Confirm each step against the upgrade guide for your exact installed version before you begin.
Confirm the installed Gitea version
The platform team records the exact Gitea version running in production, including the database engine and the Actions and package features enabled. This is the gate for the whole sequence: the documented transparent path covers upgrades from Gitea up to v1.22, and the supplied facts do not document a transparent path from later Gitea versions, such as the v1.27 line or the v28 releases. If the instance is above v1.22, stop here and ask Forgejo maintainers and your DeployOpen team to confirm the supported route. Done when the version is written in the change record and matched against the upgrade guide.
Read the upgrade guide for your version
The team reads the Forgejo upgrade guide section that applies to the installed Gitea release and writes down each required step, configuration change and database action in order. The guide describes the upgrade in two steps: first to Forgejo v10.0.x, then to a later Forgejo version. Ask the platform owner to confirm which Forgejo target is current and whether it is the LTS release (v15, supported until July 15, 2027) or a stable release (v17.0.0, supported until January 28, 2027). Done when a signed-off runbook lists every step with its owner.
Back up repositories and the database
The administrator takes a full backup of the Git repositories, attachments, LFS objects, configuration file and the database (MySQL, PostgreSQL, SQLite or MSSQL), then copies it to storage outside the Gitea host. Restore a backup to a separate test host to confirm it is complete before the upgrade begins. This is the rollback path if the upgrade fails. Done when a test restore has been opened, a sample repository has been cloned from it and the backup location is recorded in the runbook.
Upgrade in a staging copy
The team runs the two-step upgrade on a staging copy built from the production backup: first to Forgejo v10.0.x, then to the chosen later Forgejo version, following the guide without skipping steps. They check that the service starts, database migrations complete without errors and the web UI loads. Staging is the place to find problems with custom templates, reverse proxy rules or plugins. Done when staging passes login, repository browsing, a push and a pull request review.
Test Actions workflows and runners
Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions, so the team reviews every workflow file, reusable action and secret in use and runs each one on a Forgejo runner in staging. Workflows that rely on GitHub-specific contexts, actions or marketplace steps are expected to need changes. Confirm which runner labels and images your jobs require and that each runner registers against the upgraded instance. Done when every production workflow has a passing run, or a logged rebuild task with an owner.
Validate integrations and access
The team checks each third-party integration, including webhooks, CI servers, single sign-on, package registries, container registries and chat notifications, against the upgraded staging instance. Confirm that authentication, API tokens and webhook secrets still work, since integrations built against Gitea endpoints may need updates. Package registry users, such as npm, PyPI, Maven, container and Helm clients, should each push and pull a test artifact. Done when each integration has a recorded test result and any broken connection has a fix or a documented workaround.
Cut over and confirm what transferred
During a planned window, the team repeats the approved steps on production, using the verified backup as rollback, then checks that repositories, users and issues are present and that the upgrade path has carried issue data as the guide describes. Record which items transferred cleanly and which need rebuilding, such as workflows, runners and integrations. Keep the old Gitea backup until the team has run a full working cycle. Done when the production checks match the staging results and the migration record lists each open item with an owner.
What drives the running cost of each forge
Both forges are self-hosted in your infrastructure, so the license fee is rarely the largest line item. The cost comes from who runs the server, how often upgrades are forced by support windows, how CI capacity is sized, and what support contract sits behind the platform. Use these cards to turn each driver into a question for your quote.
Infrastructure hosting
Both Forgejo and Gitea are self-hosted in your own cloud accounts, data centers or air-gapped networks, so you pay for the compute, storage, backups and high availability you provision. Gitea supports MySQL, PostgreSQL, SQLite and MSSQL, and Forgejo's database choice affects the backup and replication design you need. Ask the implementer which database engine, storage tier and backup target the quote assumes, and whether the hosting cost is included or billed separately.
Staff skills and time
Running either forge is mostly operations work: upgrades, database maintenance, reverse proxy and TLS, user lifecycle and backup restores. Both products are Go-based and easy to install, but the team still needs someone accountable for the server after go-live. Ask who is paid for initial setup, who holds the on-call duty, and whether knowledge transfer and runbooks are part of the fixed scope.
Commercial support options
Forgejo is community-governed under GPL-3.0-or-later from v9.0 onward, so support comes from the community, from a partner such as DeployOpen, or from a vendor you contract separately. Gitea's commercial support comes from CommitGo, which sells Gitea Enterprise with SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. Ask what response commitments the quote includes and whether an Enterprise license fee is recurring or one-time.
Upgrade effort and support windows
Forgejo stable releases get full support for three months plus a two-week window, while LTS releases get critical bugfixes and security support for one year and three months. Forgejo v15 is the LTS release supported until July 15, 2027, and v17.0.0 is supported until January 28, 2027, so choosing a stable line means upgrading more often. Gitea's v1.27 line is the one to plan around for the Gitea side. Ask the implementer to price upgrades per window and to state who tests them.
Runner and CI capacity
Forgejo Actions and Gitea Actions both hand jobs to separate runners, so CI cost depends on how many runners you host, what they run on and how many build minutes your teams generate. Forgejo Actions is not compatible with GitHub Actions, while Gitea Actions is designed to be compatible, which affects how much existing workflow code you can reuse. Ask what runner hosts, autoscaling and job concurrency are included, and what a workflow rewrite would cost if you move from GitHub.
Migration effort from Gitea
Forgejo documents transparent upgrades from Gitea up to Gitea v1.22 in two steps, first to Forgejo v10.0.x and then to any later Forgejo version. A Gitea install on a newer line, such as v1.27 or the v28 releases, needs its own compatibility check before the same path applies. Ask the implementer to confirm your exact Gitea version, the migration steps, a rollback plan and the data verification method before agreeing to a fixed scope.
What implementing each forge involves and where projects run long
Plan the work around the parts that a Forgejo or Gitea deployment in your own infrastructure actually touches: the hosting platform (VMs, Kubernetes or bare metal), the database backend (MySQL, PostgreSQL, SQLite or MSSQL for Gitea, and the databases Forgejo documents for its own installs), TLS termination in front of the application, and identity integration with your directory or SSO provider. Each of these is a decision you make before installation, and each one changes the test plan. Backup and restore testing belongs in the same plan. Run a restore of the repositories, the database and the Actions data into a separate environment and confirm that users can clone, log in and see their pipelines. Upgrade planning is the other recurring cost. 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, so confirm which Gitea version you run today before you choose a target. Document each step as a runbook your operations team can repeat.
Projects that run long usually do so for three reasons. The first is undocumented CI workflow differences. Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions, while Gitea Actions is designed to be compatible with GitHub Actions. Inventory every workflow, action reference and secret before migration, and treat each incompatibility as a rewrite item in the scope. The second is identity integration that has never been tested under load. Single sign-on, group mapping and API tokens can work for a few test accounts and fail when hundreds of developers and automated jobs authenticate at the start of a working day. The third is runner capacity assumptions. Runners are separate from the forge, so the number, size and placement of runner pools is a planning decision that needs a measured baseline, not an estimate made at the desk.
Ask for the written scope, deliverables and timeline before work starts. DeployOpen agrees scope, deliverables and timelines in writing for most engagements, and a quote follows from that scope. Ask the implementer to name the restore test, the identity test under realistic login volume, the workflow compatibility inventory and the runner sizing method as separate deliverables. Those items, not the installation itself, determine how long the project takes and what you have to maintain afterward. Confirm the support window for the release line you choose in the Forgejo releases listing, and confirm Gitea's commercial support terms with CommitGo before you rely on them for compliance evidence.
Questions buyers ask before choosing Forgejo or Gitea
Can a Gitea instance move to Forgejo without rebuilding it?
Yes, for Gitea up to v1.22. Forgejo documents transparent upgrades from Gitea up to Gitea v1.22 in two steps: first to Forgejo v10.0.x, then to any later Forgejo version. Teams on a Gitea release after v1.22, including the v1.27 line and the v28.x releases, should not assume the same path. The supplied material does not confirm a documented route from those versions, so confirm the supported starting point with Forgejo before you plan the cutover. Rehearse each step on a copy of the database and repositories, and verify a restore before you touch production. Follow the Forgejo upgrade guide closely, since the steps are order-dependent.
Does Forgejo Actions run our existing GitHub Actions workflows?
No. Forgejo Actions is designed to feel familiar to GitHub Actions users, but it is not compatible with GitHub Actions, so most workflows need edits before they run. Gitea Actions, by contrast, is designed to be compatible with GitHub Actions, which matters if your team relies on a large library of existing workflows. Forgejo also hands jobs to separate runners, so runner hosts, labels and capacity need planning alongside the workflow changes. Start with an inventory of workflows, third-party actions, secrets and runner requirements, then estimate the rewrite from that list. Review the Forgejo Actions overview to confirm the syntax differences that affect your pipelines.
Which license applies to each Forgejo and Gitea version?
Forgejo is licensed GPL-3.0-or-later from v9.0 onward, and earlier Forgejo versions are under MIT. Gitea is MIT licensed. A team that deploys Forgejo v9.0 or later takes on GPL obligations when it distributes or modifies the software, while an MIT Gitea deployment carries permissive terms. Codeberg e.V., a non-profit association registered in Berlin, owns the Forgejo domains, and project governance stays independent according to the Forgejo FAQ. Have your legal team confirm the obligations that apply to your own distribution and internal modifications, and record the exact version and license in your software bill of materials.
What does Gitea Enterprise add, and do we need it?
Gitea Enterprise, sold by CommitGo, Inc., adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. It is needed when your policy requires those controls inside the forge itself. If your identity provider, log pipeline and CI scanning already enforce them, the edition may add cost without adding control. Ask CommitGo for the current subscription terms and pricing, because the supplied material gives no figure. Then check each control against the Forgejo documentation, since the comparison should be based on what you actually deploy.
How long does support last for each Forgejo release line?
Stable Forgejo releases receive full support for three months plus a two-week window. 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 v17.0.0, released October 15, 2026, is supported until January 28, 2027. For Gitea, the supplied material shows the v1.27 line and v28.x releases but does not state support windows, so ask CommitGo or check the Gitea release notes before you commit to a version. Track the end dates in your upgrade calendar, as each one sets a required upgrade window. Review the Forgejo releases page for current dates.
What does a fixed-scope Forgejo migration cover?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure. Most engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing before work starts. For a forge migration, the written scope typically lists the source and target versions, database, repositories, user and identity integration, runner setup, backup and restore checks, cutover steps and documentation. DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing upgrades, support and continuous testing are available as retainers. Ask for the scope in writing and check that it names every item above.
Can our own team migrate Gitea to Forgejo themselves?
A capable team can, if it has Linux, database and Git server administration skills and time for rehearsals. The documented upgrade path reduces guesswork for Gitea v1.22 and earlier, but your team must supply the staging environment, a tested backup and restore, runner capacity, identity configuration and a named owner for cutover and rollback. Effort recurs with each upgrade, and the LTS and stable support windows set how often that work arrives. Outside help becomes more useful when your version gap is large, your workflow count is high or your compliance evidence has to be produced on a deadline. Decide after you complete the inventory, not before.
How DeployOpen helps teams choose and implement a self-hosted forge
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For Forgejo vs Gitea, we start from your license, upgrade and CI requirements, then build and hand over a forge that your own team can run.
How we scope
- Written scope covers the forge version, database choice, and whether the existing Gitea instance is upgraded or replaced.
- We document which CI approach your teams need, including whether existing GitHub Actions workflows must run unchanged.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We install and configure the chosen Forgejo or Gitea release inside your cloud accounts, data centers or air-gapped network.
- Where you migrate from Gitea, we follow the documented two-step upgrade path and test each step before cutover.
- We configure authentication, backups, runners and access controls, then test them against the agreed scope.
How we hand over
- You receive runbooks covering installation, upgrades, backup restore and runner maintenance written for your own team.
- Handover includes the configuration record and an evidence pack that your auditors can use for compliance readiness.
- We walk your administrators through the upgrade calendar, including the support window of the release line you chose.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover moving to a later Forgejo LTS release when your current support window approaches its end.
- Ask any quote to state which items are one-time work and which recur under a retainer.
