Should you self-host Forgejo or use Codeberg?
A team that needs a Git forge for company code and asks whether Codeberg is enough should know that Codeberg fits open source projects that accept its terms, while private company code, SSO and uptime needs point to self-hosting. Codeberg's Terms of Use open the service to projects under a free and open source software licence, allow private repositories only for things required for FLOSS projects, and state that Codeberg makes no guarantees about the availability of hosted content. A company that wants private repositories for proprietary work, or that depends on the forge for releases and deployments, falls outside that scope.
Both options run Forgejo, so the choice is not about features in the software itself. It is about who operates the instance, where the data sits and who carries availability and compliance risk. On Codeberg, Codeberg e.V., a non-profit association, operates the service and sets its rules. Self-hosting moves operation, backups, access control, identity integration and evidence collection into your own infrastructure, which means your team or a partner such as DeployOpen carries that work. Confirm with Codeberg in writing whether your use case is permitted under its terms before you rely on it.
This section sets out the decision points this page covers: control, compliance, features, effort, cost structure and migration. Each one changes the answer. Ask who must be able to restore the forge after an outage, which regulator or customer audit will ask for access logs and change records, whether SSO through your identity provider is required, and what it would cost your team to run upgrades on a supported Forgejo release. Those answers tell you whether Codeberg is a starting point for public work or whether a self-hosted instance is the right foundation for company code.
How Codeberg and self-hosted Forgejo compare on each factor
This table sets Codeberg's public instance against a Forgejo instance your team runs itself, row by row. Where a cell depends on configuration such as SSO, backups or access controls, it says who sets it, so you can check each row against your own requirements before shortlisting.
| Factor | Codeberg (hosted Forgejo) | Self-hosted Forgejo |
|---|---|---|
| Eligibility | Open to projects under a free and open source software licence, per Codeberg's Terms of Use | Any organization, since your team decides who uses the instance |
| Private repositories | Allowed only for things required by FLOSS projects, so private company code does not fit | Available for any private code, subject to your own access design |
| Availability commitment | Codeberg makes no guarantees about the availability of hosted content | Set by your team and your infrastructure, backed by your own monitoring and recovery plan |
| Who operates the instance | Codeberg e.V., a non-profit association registered in Berlin | Your team, or DeployOpen under a written scope if you contract implementation and support |
| Data location | Codeberg's infrastructure, outside your control | Your cloud accounts, data centers or air-gapped networks, chosen by your team |
| Software version control | Codeberg runs Forgejo with modifications, so confirm which version and changes apply with Codeberg | You choose the Forgejo version, such as an LTS release, and when to upgrade |
| Licensing | Forgejo code is GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT | Same Forgejo license terms apply, so license cost is not a differentiator |
| Upgrade timing | Set by Codeberg, so confirm its schedule and any notice it gives | Set by your change process, within the support windows published for each Forgejo release |
| Identity integration (SSO) | Confirm with Codeberg whether any external identity option is offered | Set by your team during configuration, so confirm the options your Forgejo version supports |
| Cost structure | No paid tier is described in the supplied terms, so confirm any charges with Codeberg | You pay for infrastructure, staff time and any implementation scope agreed in writing |
What control, data location and compliance look like in each model
Codeberg and a self-hosted Forgejo differ less in features than in who holds the data, who operates the service and who answers when something goes wrong. The cards below cover the questions a security or compliance lead should settle before choosing a model.
Where the data lives
A self-hosted Forgejo keeps repositories, issues, attachments and backups inside your cloud accounts, data center or air-gapped network, so you decide the region, the storage tier and the network path. Codeberg stores your content on a service run by Codeberg e.V., a non-profit association, under its Terms of Use. Before relying on Codeberg for any regulated or client data, ask the association for its data processing terms in writing, including where data is stored and who can access backups.
Administrative access
On Codeberg, administrators of the instance are staff of the association, and you have no administrative access to the server, its database or its logs. On a self-hosted instance, your own operators hold root and database access, which means your access reviews, privileged account controls and logging cover the Git platform directly. Write down who may administer the instance, how that access is granted and removed, and how it is recorded.
Availability responsibility
Codeberg's Terms of Use state that it makes no guarantees about the availability of hosted content, so an outage or a long maintenance window is outside your control and outside any contract you hold. A self-hosted instance moves that responsibility to you or to your implementation partner, which means you must define backups, failover, recovery objectives and maintenance windows in writing. Ask what your model requires for recovery before you need it.
Incident and evidence handling
When a security incident involves source code, you need logs, timestamps and access records that you can hand to an investigator or an auditor. With self-hosting, you define log retention, forward audit events to your own SIEM and set the chain of custody. On Codeberg, evidence depends on what the association provides, so confirm in advance which logs are available, how long they are kept and how requests for them are handled.
Identity and access control
Team membership, branch protection and single sign-on decide who can read and change private code. A self-hosted Forgejo lets you connect your own identity provider and enforce your own access policy, though you must confirm the exact authentication options for the version you run. Codeberg's account model is the one the association provides, so check whether it meets your requirements for single sign-on, enforced multi-factor authentication and offboarding before you move any private repositories.
Compliance proof each model supports
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration records, access reviews and backup tests, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Whichever model you choose, ask your auditor which evidence it expects from a Git platform and confirm whether Codeberg's terms and records can supply it.
What Codeberg's terms mean for company code
Codeberg's Terms of Use decide the question for most companies before any feature comparison. Codeberg e.V. describes itself as a non-profit organization funded by member contributions and donations, and it opens its service to projects under a free and open source software licence. Private repositories are allowed only for things required by FLOSS projects, and the service excludes use as a personal cloud or media storage. Proprietary product code, internal tooling, customer-specific configuration and infrastructure repositories generally fall outside that eligible use. If your code is not released as free software, the feature comparison that follows is moot on Codeberg, and self-hosting is the path to evaluate.
The terms also say Codeberg makes no guarantees about the availability of content hosted on the platform. For a company, this matters as much as eligibility. A build pipeline, deployment repository or release artifact that stops being reachable is an outage for your team, and Codeberg's terms give you no contractual recourse for it. Ask your legal and security leads to read the availability clause against your internal service expectations, and decide whether any repository used for production delivery can tolerate that risk. Self-hosted Forgejo, run inside your own infrastructure, puts uptime, backups and restore testing under your control, with the operating effort that comes with them.
If a company wants to use Codeberg for an open source component it publishes, read the full Terms of Use before relying on it, not only the summary above. Confirm which repository types are covered, what counts as a required private repository, and how the availability statement applies. The terms can change, so check the current text at the link provided and record the version you reviewed. Re-check it when you plan a new repository or change how the project is governed or funded.
Which hosting model fits each situation
A public project whose code is already under a free and open source license is the case Codeberg was built for. Codeberg's Terms of Use open the service to projects under a free and open source software licence, and the service runs Forgejo with modifications, so the day-to-day workflow will feel familiar. Hosting on Codeberg means you do not operate servers, back up the instance or patch it. The trade-off is that Codeberg makes no guarantees about the availability of content hosted on the platform, so a project that cannot tolerate outages should plan a mirror or a fallback.
- Recommended model: Codeberg, using its public repositories and free and open source licensing.
- Fit: Community contributions, issue tracking and releases on a non-profit, Forgejo-based forge.
- Condition that changes it: Heavy automated CI, large binary artifacts or a release process that must always be reachable may push the project toward a self-hosted instance.
- Mirror option: Keep a second copy of critical repositories somewhere you control, since availability is not guaranteed.
- Governance note: Forgejo is GPL-3.0-or-later from v9.0 onward, and Codeberg e.V. owns its domains while project governance stays independent.
Confirm the current Terms of Use before committing, especially any limits on repository size and what counts as an eligible project.
Some open source projects have a company sponsor that wants private planning repositories, such as roadmap notes, security advisories in progress or customer-specific forks. Codeberg's Terms of Use allow private repositories only for things required for FLOSS projects, so private planning material that is not tied to the project's own development is outside that allowance. In this case the public project can stay on Codeberg while the sponsor runs a self-hosted Forgejo for private work.
- Recommended model: Split hosting, with public code on Codeberg and private planning on a self-hosted Forgejo.
- Illustrative example: A sponsor keeps unreleased security fixes in a private repository on its own instance, then publishes them to the public project at release time.
- Condition that changes it: If the sponsor's private work is required by the project itself, confirm with Codeberg whether it qualifies.
- Operating cost: The sponsor takes on backups, upgrades and access control for its own instance.
- Sync process: Define who moves code between the two instances and how credentials are handled.
Ask Codeberg how it interprets private repositories for FLOSS projects before you rely on that split.
Private company code is the main reason to self-host. Codeberg's Terms of Use exclude use as a personal cloud or media storage and limit private repositories to things required for FLOSS projects, so proprietary source code does not fit the public service. A self-hosted Forgejo keeps repositories, access rules and backups inside your own infrastructure, where your security team sets the retention and recovery targets.
- Recommended model: Self-hosted Forgejo in your own cloud account, data center or private network.
- Illustrative example: An internal platform team hosts proprietary service code and infrastructure definitions on its own instance, with backups stored in a separate account.
- Condition that changes it: If the code is only a public mirror of an open project, Codeberg may be enough.
- Ownership: Your team pays for hosting, patching and backups, and those costs recur every year.
- Ask your provider: Request the written scope for installation, hardening, backup testing and upgrades before work starts.
Check your own policies for code residency and vendor access before choosing a hosting location.
Regulated organizations need evidence about where code lives, who can change it and how the platform is recovered. Codeberg's Terms of Use say Codeberg makes no guarantees about the availability of content, and the public service is not run under your organization's control, so an auditor will usually expect the forge to be inside your own boundary. A self-hosted Forgejo lets you document access reviews, backup restores and change records as part of your own control set. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors make that determination.
- Recommended model: Self-hosted Forgejo inside the regulated boundary, with documented controls.
- Evidence to plan: Access logs, backup restore tests, upgrade records and role reviews.
- Condition that changes it: If the regulator and auditor accept a third-party hosted service with contractual terms, the decision may differ.
- Support window: Choose a Forgejo release line with a published support window, such as the LTS line, and plan upgrades around it.
- Ask the auditor: Confirm which control evidence they expect for the forge before you design it.
Confirm the applicable framework requirements with your auditor, not with the platform vendor.
A team that wants single sign-on across its tools needs the forge to authenticate against the company identity provider. Codeberg is a shared public service that you do not configure, so you cannot attach your own identity provider to it. A self-hosted Forgejo can be connected to the identity provider your organization already runs, which keeps offboarding and access reviews in one place. Confirm the exact authentication methods supported by the Forgejo version you plan to run, since the supported options are part of its configuration rather than something this page can promise.
- Recommended model: Self-hosted Forgejo wired to your central identity provider.
- Benefit: Disabling a user in the directory removes access to the forge as well.
- Condition that changes it: If your team only needs local accounts for a small public project, Codeberg accounts may be sufficient.
- Integration effort: Account mapping, group sync and login testing are one-time tasks with recurring review needs.
- Confirm first: Check the Forgejo documentation for the authentication options in your target version.
Test a non-production login flow before you move any users onto the instance.
What your team runs in each model
This table lists the operating tasks behind a Forgejo deployment and shows who carries each one on Codeberg versus a self-hosted instance. Read it as a responsibility map: on Codeberg the association runs the instance and your team manages only its own accounts and workflows, while self-hosting moves every row to your team or a services partner you contract. Use it to scope the work before comparing costs.
| Task | Codeberg (hosted by Codeberg e.V.) | Self-hosted Forgejo (your team or a services partner) |
|---|---|---|
| Instance installation | Codeberg e.V. operates the service. Your team has no installation work. | Your team or a partner installs Forgejo, chooses the database, storage, reverse proxy and network placement inside your environment. |
| Upgrades | Codeberg e.V. applies platform changes. Your team does not schedule or test upgrades. | You choose the Forgejo release line, such as the LTS track or stable releases, and own testing, rollback and the upgrade calendar. |
| Backup and restore | Codeberg e.V. manages platform backups. Your team keeps local clones of critical repositories as its own safeguard. | You define backup scope for repositories, database, attachments and configuration, run restore tests, and set retention in line with your policy. |
| Monitoring and alerting | Your team has no visibility into platform health beyond what Codeberg publishes. | You select metrics, logs and alerts for availability, storage, and runner queues, and staff the response. |
| Access administration and SSO | Your team manages only its own user accounts, teams and repository permissions within the public service. | You manage the identity integration, administrator roles, account lifecycle and SSO configuration. Confirm which SSO options your Forgejo version supports before scoping. |
| Runner management | Codeberg operates the CI infrastructure for hosted projects. Your team manages only its own workflows. | Forgejo Actions hands jobs to separate runners, so your team or partner sizes runner capacity, isolates runner hosts, manages secrets exposure and patches runners. |
| Incident response | Your team reports issues to Codeberg. Restoration timing is outside your control because Codeberg makes no availability guarantees. | Your team or partner runs detection, containment, communications and recovery, and defines the escalation path and service targets written into the contract. |
| Vendor coordination | Your relationship is with the non-profit association under its terms of use, which exclude private cloud and media use. | You coordinate with the Forgejo community for releases, your hosting provider for infrastructure, and any services partner under a written scope. |
Keeping a self-hosted Forgejo on a supported release
Choosing a self-hosted Forgejo means choosing a release line, and the release line sets how often your team must upgrade. Forgejo documents that 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. Under the stable model, v17.0.0 (released October 15, 2026) is supported until January 28, 2027, so a team that tracks stable releases must plan a roughly quarterly upgrade cycle. The LTS line, v15, is supported until July 15, 2027, which allows a slower calendar but still requires an upgrade before that date. Confirm the current support dates on the Forgejo releases page before you set your schedule, because dates move as new releases ship.
On Codeberg, the upgrade calendar belongs to the operator. Codeberg decides when the platform moves to a new Forgejo version, and Codeberg's Terms of Use say it makes no guarantees about the availability of hosted content, so your team has no say in timing and no control over maintenance windows. When you self-host, the calendar is yours. Your team decides which line to run, when to test a release against your SSO, backup and CI configuration, and when to schedule downtime. Those tasks also carry recurring labor cost: someone must read release notes, rehearse the upgrade in a staging copy, restore a backup if something fails and document the result. Ask any implementation partner for a written upgrade runbook, the staging environment they will use, and how upgrades are priced: one-time, per release, or under a retainer.
The Gitea upgrade path matters only if you are migrating from Gitea. 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 already running Forgejo, or starting fresh, do not need this path. Teams on an older Gitea must plan the two steps as separate, tested changes, with a backup taken before each one, and should confirm that their installed Gitea version falls within the documented range before scheduling work. Check the Forgejo upgrade guide for the exact steps and any conditions that apply to your database and configuration.
Moving repositories between Codeberg and your own Forgejo
This sequence moves a Forgejo project in either direction, from Codeberg to a self-hosted instance or back, with each step closing on a check that the data, access and automation arrived intact. It is most useful when the move is planned in writing before anyone touches the source instance.
Confirm eligibility and data needs
Start by checking the Codeberg Terms of Use against the project. Codeberg accepts projects under a free and open source licence, allows private repositories only for what a FLOSS project requires, and excludes use as personal cloud or media storage. Moving private company code to Codeberg is outside those terms, so a company moving back to its own instance has the simpler path. Write down which repositories, issues, pull requests, releases, wiki pages, Actions workflows and secrets must move, and who owns each. Done means a signed inventory that names the source version and the target Forgejo version. Your own target version should be one you can support, such as a release within its published support window.
Confirm what export tooling preserves
Before choosing a method, confirm with the Forgejo documentation for your target version which metadata its export and migration tooling carries across. Ask specifically about issue and pull request history, comments, labels, milestones, releases and attachments, and whether Actions workflow files and their secrets are included. Forgejo federation is experimental and under active development according to the Forgejo FAQ, so do not plan the move around it. Done means a written list of what transfers automatically and what must be recreated by hand, agreed by the project owner.
Export or mirror repositories
Copy the Git history first, using a full mirror clone of each repository so branches, tags and refs come across. Run the mirror at least once more close to cutover so late commits are captured. Push the mirror to the target instance and compare commit counts, tag lists and default branches between source and target. Done means each repository matches the source on refs and a sample of recent commits checks out with the same hashes.
Move issues, pull requests and releases
Use the migration tooling confirmed in the earlier step to bring issues, pull requests, labels, milestones and releases across. Where the tooling does not carry a field, export it to a file and recreate it manually, marking each item as transferred or pending in the inventory. Release binaries and attachments often need a separate download and upload. Done means a spot check of a set of issues and pull requests from each category confirms titles, authors, state, comments and linked commits match the source.
Rebuild identity and access
Recreate organizations, teams and repository permissions on the target instance, and map every source account to an account or SSO identity on the target. Confirm how authentication works on your own instance, since a self-hosted deployment is where you control the identity provider integration and the admin roles. Remove stale accounts and tokens rather than carrying them over. Done means each team lists the same members with the same permission levels as the source, and a test login works for each role.
Switch runners, secrets and webhooks
Forgejo Actions is built into Forgejo and hands workflows to separate runners, and it is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions. Register new runners on your own instance, re-enter repository and organization secrets, and recreate every webhook that notifies downstream systems. Confirm each workflow runs on the new runners before you disable the old ones. Done means a test run of each critical workflow succeeds and each webhook delivers a test event to its consumer.
Cut over and retire the old instance
Freeze pushes to the source, run the final mirror sync, update remote URLs on developer machines and CI configs, and publish the new location to contributors. Keep the source read-only for a period you agree in writing with the project owners, so late links and clones have a path. Archive the source export, then retire it. Done means every active contributor has pushed to the new remote, the source is read-only and the archived export is verified and stored.
Questions teams ask before choosing self-hosted Forgejo
What drives the cost of self-hosting Forgejo compared with using Codeberg?
Self-hosting costs come from three places: the infrastructure you run Forgejo on, the people who operate it, and any services you engage for planning, integration and hardening. Codeberg's published price data was not available for this page, so ask Codeberg directly what its terms and any fees mean for your organization, particularly because its terms restrict private repositories to what FLOSS projects require. For a self-hosted instance, the one-time work includes scoping, identity integration, migration and runner setup. The recurring work includes patching, backups, upgrades and monitoring. A DeployOpen quote follows the written scope, so ask for each cost as a separate line: one-time implementation, recurring support and upgrades, and infrastructure you will pay for directly.
How long does a self-hosted Forgejo rollout take?
The duration depends on scope, not on Forgejo alone. The main drivers are the identity integration you need, the number of repositories and the history you must migrate, the CI runners you plan to deploy, and how many teams must be trained and cut over. Forgejo's release calendar matters too: stable releases get full support for three months plus a two-week window, while LTS releases get one year and three months of critical bugfix and security support, so the version you choose affects how often you upgrade after go-live. No fixed duration is stated here. Ask for a timeline tied to a written scope with named deliverables, and ask which items are in the fixed price and which are optional.
What does the client's team need to provide for a self-hosted Forgejo project?
Your team needs to supply the hosting environment, the identity source for sign-in, decisions on who owns repositories and access, and people who can approve changes to DNS, certificates and network rules. Plan for a named owner for backups and restore tests, and someone who can review the upgrade path when a new release arrives. If you plan to run CI, assign owners for runner hosts and the secrets they hold. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so your team keeps control of the environment and the accounts. Ask the provider to list every dependency on your side before work starts.
Can an internal team run self-hosted Forgejo on its own?
Yes, many internal teams run Forgejo without an outside partner, but it depends on your skills and capacity. A small team needs to handle installation, upgrades between Forgejo releases, backups and restore testing, identity configuration, runner maintenance and security patching. Forgejo's documentation covers these tasks, and its upgrade guide describes the path from Gitea up to v1.22 in two steps if you are migrating from that version. The practical test is whether someone on your team can restore the instance from backup without help and whether they have time to do it every release cycle. If not, ask a provider to take on part of the work under a retainer, which covers ongoing support, upgrades and continuous testing.
Can Forgejo use SSO and automated backups in a self-hosted setup?
Plan for both, but confirm the exact settings against the Forgejo documentation for the version you choose before you commit to a design. SSO requirements, such as the protocol your identity provider supports, how users are provisioned and how group membership maps to teams, should be written into the scope before work starts. Backups need to cover the database, repository data and configuration, and a restore must be tested, not just a backup job that reports success. Ask your provider to show the exact configuration keys and backup procedure for your target version, and to document how a restore is run. The Forgejo upgrade guide is the right starting point for version-specific steps.
Can Forgejo Actions replace my GitHub Actions workflows?
No. Forgejo Actions is a built-in CI system that hands workflows to separate runners, and it is designed to be familiar to GitHub Actions users, but the Forgejo documentation says it is not compatible with GitHub Actions. Existing workflow files will need to be reviewed and rewritten or adapted before they run on Forgejo. Plan for that effort in the migration scope, and include runner setup, secrets handling and testing of each pipeline. Your team should inventory which workflows depend on GitHub-specific actions or features, then decide case by case what to port, replace or retire. Ask your provider to estimate that work from your actual workflow inventory.
Can a Codeberg project move to a private self-hosted Forgejo later?
Moving is possible in principle because Forgejo is the software Codeberg runs, but the move is a migration, not a switch. Codeberg's terms open the service to projects under a free and open source licence and restrict private repositories to what FLOSS projects require, so the reason for moving is often private code or company needs. Plan the move around repositories, issues, pull requests, users, permissions, CI configuration and any integrations, and confirm with Codeberg what export options exist for your project data. Verify the exact import path against the Forgejo documentation for your target version. Keep the Codeberg copy running until the new instance is verified, and update clone URLs and webhooks for every consumer.
How DeployOpen scopes and supports a self-hosted Forgejo
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a self-hosted Forgejo, that means the instance, its identity integration, backups and operating documentation are designed around your uptime, access and retention requirements rather than a shared public service's terms.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope should state which repositories are private, which users need SSO, and who owns the instance.
- Ask for the Forgejo version and support window to be named explicitly, since LTS and stable tracks differ.
How we build
- Installation runs in your own infrastructure, with hosting, database, storage and network placement set by your environment.
- Identity integration, backup routines and any Forgejo Actions runners are configured and tested as part of the defined scope.
- Customizations and modifications are documented so later upgrades can be planned against a known baseline.
How we hand over
- Handover includes operating documentation covering upgrades, backups, restore steps and access administration.
- Restore procedures are exercised so your team knows the recovery path before it needs it.
- Ask the vendor to confirm exactly which artifacts, runbooks and configuration records are included in the handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work.
- Retainer scope should specify which Forgejo releases are covered and how upgrades are timed against support windows.
- Request the support response expectations in writing, since DeployOpen does not publish a price list or fixed service levels.
