Which fits your GitHub Actions situation: GitHub Actions or Forgejo Actions
GitHub Actions fits best when your code already lives on GitHub, your team wants a managed forge, and your workflows depend on the GitHub marketplace or GitHub-only features. Forgejo Actions fits best when the forge itself must sit in your own infrastructure, when code or build data cannot leave your network, or when you want a non-profit, GPL-3.0-or-later project behind the tooling. Forgejo Actions is designed to be familiar to GitHub Actions users, but it is not compatible with it, so you should expect to edit workflows rather than copy them across unchanged.
The decision turns on four questions. First, where must the code live? If repositories must stay on your servers, GitHub Actions is off the table for that data, and Forgejo becomes the forge plus CI option to evaluate. Second, who operates the forge? A self-hosted Forgejo instance means your team owns upgrades, backups and the Forgejo Runner fleet, and Forgejo's stable and LTS support windows set the cadence you must plan around. Confirm the current release and support dates on the Forgejo releases page before you commit.
Third, how many workflows already depend on GitHub-only features? Count workflows that call marketplace actions, use OIDC federation, environments with approvals or GitHub-specific permission scopes. Each one needs a review against the documented differences in Forgejo Actions. Fourth, does the team need the GitHub marketplace? Forgejo runs actions fetched from a configured source, so marketplace-heavy pipelines need an inventory of which actions are required and where they will be sourced from. Ask your team to produce that list first, since it sizes the migration more accurately than any general estimate.
Which option fits which scenario
This table matches common situations to the better fit between GitHub Actions and Forgejo Actions, and names the condition that tips each choice. Read each row by first checking the condition in the right-hand column, since a single change in that condition often reverses the answer.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Repositories stay on github.com and depend on marketplace actions | GitHub Actions | Your workflows call many marketplace actions that are not mirrored or tested on Forgejo, and you accept hosted or metered runner costs |
| Self-hosted forge inside a regulated datacenter | Forgejo Actions | Source code, logs and artifacts must stay on your own servers, and you run Forgejo Runner in that network |
| Team that wants GPL-3.0-or-later licensing and non-profit governance | Forgejo Actions | Your procurement or legal policy favors copyleft licensing and an independent project governed outside a single vendor |
| Heavy use of GitHub-only workflow features, such as specific permission scopes or hosted services | GitHub Actions | Your workflows depend on GitHub-specific behavior that the Forgejo documentation does not list as supported, so porting would require rewrites |
| Team already running Gitea | Forgejo Actions (evaluate the upgrade) | Forgejo documents transparent upgrades from Gitea up to Gitea v1.22 in two steps, so confirm your version and the migration path before switching |
| Workflows written for GitHub Actions that must run unchanged on a new forge | Neither, confirm first | Forgejo Actions is designed to be familiar but not compatible, so run your existing workflows on a test instance to find the differences |
Where the data lives and who controls it
Moving from GitHub Actions to Forgejo Actions changes where logs, artifacts and secrets are stored, who operates the platform and how users sign in. Each card below covers one of those decisions, with the checks to run before choosing a hosting model.
Logs and artifacts location
On GitHub-hosted runners, run logs and artifacts sit in GitHub's storage, and the default artifact retention is 90 days. With Forgejo Actions, logs and artifacts are stored on the Forgejo instance you operate, so retention and deletion follow your own policy. Ask who can read run logs, how long they are kept and whether any build output contains credentials that must be scrubbed before storage.
Secrets storage and export
GitHub's REST API returns Actions secret names without values, so secrets cannot be copied out of GitHub when you leave it. Forgejo Actions secrets are entered again on the new instance, which means someone must rotate and re-issue each credential. Inventory every secret, record its owner and rotate it during the cutover rather than copying it blindly.
Hosting model and operator
GitHub Actions runs in one of three models: GitHub-hosted runners on GitHub's infrastructure, GitHub Enterprise Server installed in your data center, or self-hosted runners attached to GitHub. Forgejo Actions runs on a Forgejo instance and separate runners that your team installs and operates. Decide who patches the forge, who runs the runners and who answers for an outage before you choose.
Identity and sign-in integration
GitHub Enterprise Cloud and Enterprise Server connect to corporate identity through SAML and SCIM. A self-hosted Forgejo instance has its own user accounts and authentication sources, so confirm which single sign-on and directory options your Forgejo version supports and how account deprovisioning will work. Access to the forge and access to runners should be reviewed separately.
Forgejo support windows and upgrades
Forgejo publishes stable releases with three months of full support plus a two-week window, and LTS releases with one year and three months of critical and security support. Your team takes on patching and upgrades that GitHub otherwise performs. Plan a version policy, choose between stable and LTS tracks and record who receives security advisories.
Compliance evidence and responsibility
Moving the forge changes which controls you own. Under a self-hosted model, your organization is responsible for access logs, backups, encryption and change records that auditors may request. DeployOpen can plan, implement and document these controls and prepare the evidence, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
What the GPL-3.0-or-later license and non-profit governance mean for you
Forgejo's license matters before you deploy it, because the terms differ by version. Forgejo was released under the MIT license for earlier versions, and from v9.0 onward it is licensed under GPL-3.0-or-later. The practical split is simple to state: if you run a Forgejo release that is v9.0 or later and modify it only for your own staff, the copyleft conditions of the GPL are generally not triggered by internal use. If you distribute a modified Forgejo build to customers, partners or other third parties, or ship it inside a product, the GPL requires you to make the corresponding source of that modified version available under the same license. Confirm with your legal team exactly what counts as distribution in your organization, especially for contractors who customize Forgejo Actions or the Forgejo Runner on your behalf.
Governance is the second half of the picture. According to the Forgejo FAQ, Codeberg e.V., a non-profit association registered in Berlin, owns the project's domains, while project governance remains independent of that ownership. For a procurement or risk review, the questions to put to the project are who holds the trademarks and domains, how decisions are made, and what happens to the project if the association's circumstances change. Ask your legal team to read the license text and the Forgejo FAQ together, and to record a decision on the version you will deploy and the internal modification policy before you commit to a fork or a patch set. Do not treat this summary as legal advice.
The Forgejo Runner and when Forgejo fits better than Gitea
Forgejo Actions is the built-in CI system of Forgejo, and it does not run jobs on the forge server itself. The forge schedules workflows and hands them to separate runners, so the Forgejo instance serves repositories and the Forgejo Runner executes jobs on machines you register and control. This separation lets you size build capacity independently of the forge and keep sensitive builds on hosts placed in a controlled network zone.
- Separate execution: the forge dispatches work and runners pick it up, so you can add or remove build capacity without changing the forge server.
- Familiar, not compatible: the Forgejo documentation says the syntax is designed to be familiar to GitHub Actions users, but it is not compatible, so existing workflow files need review before they run unchanged.
- Placement control: runners can sit in a network zone of your choosing, which helps when build hosts must reach internal registries but not the public internet.
- Runner features: labels, execution options, caching and artifact handling change between releases, so check the runner documentation for the version you plan to deploy.
- Secrets and hardening: secrets live in the Forgejo instance you operate, while each runner host needs its own patching, scoped credentials and network policy.
Confirm current runner features and version compatibility in the Forgejo Actions overview, then test a representative workflow on a staging runner before planning production rollout.
Forgejo fits better than Gitea when licensing, governance and the upgrade path matter as much as the workflow engine. Forgejo has a documented route from Gitea, and its license and governance model are the points a legal or procurement review will ask about. Those questions should be answered before any migration plan is drafted.
- License history: Forgejo is GPL-3.0-or-later from v9.0 onward, and earlier versions are under MIT. Confirm which license applies to the version you deploy and what your counsel requires for modifications.
- Governance: Codeberg e.V., a non-profit association registered in Berlin, owns the domains, while project governance stays independent. Ask your procurement team how that structure fits your vendor assessment.
- Gitea upgrade path: 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. Check your current Gitea version against the Forgejo upgrade guide first.
- Support windows: stable releases get full support for three months plus a two-week window, while LTS releases published in the first quarter of each year get critical bugfixes and security support for one year and three months. Confirm the current LTS end date on the releases page.
- Federation status: federation is experimental and under active development on ForgeFed, so do not plan a production dependency on it.
Before committing, confirm your current Gitea version, the upgrade steps that apply to it and the support window of the release you intend to run.
Gitea is the simpler choice when your team already operates it, when your workflows depend on the closest possible GitHub Actions compatibility, or when a migration would add work without a clear gain. Gitea documents that its CI is designed to be compatible with GitHub Actions wherever possible, which makes it the closer match for teams moving GitHub workflow files with few edits.
- Existing Gitea estate: if you already run Gitea, switching forks adds an upgrade and retraining task without changing the workflows your developers write.
- Closest syntax match: the Gitea comparison page lists documented gaps such as unsupported permission scopes and ignored problem matchers, so check those against your workflows before choosing.
- Reused approvals: if your organization has already reviewed Gitea's license and vendor position, you can reuse that review and avoid opening a new one.
- Smaller operating surface: a small team running one instance may prefer the runbooks, backups and monitoring it already has.
- Feature inventory: list the GitHub Actions features your workflows use, then check each one against the Gitea documentation and your own test results.
Test your three most complex workflows on both platforms before deciding, and record every difference you find so the decision rests on evidence from your own pipelines.
What moving from GitHub Actions to Forgejo Actions involves
The sequence moves repositories, issues and workflows to a self-hosted Forgejo instance, then re-establishes CI with runners and secrets, so builds run on infrastructure you control before GitHub is switched off.
Inventory workflows, actions and secrets
Platform or DevOps engineers list every repository with workflow files under
.github/workflows, every third-party action each workflow calls, every self-hosted runner, and every secret and variable name the builds depend on. Secret values cannot be read back from GitHub, so the inventory records names and owners only. The step is done when each workflow has a named owner and each external action is marked as kept, replaced or removed.Stand up the Forgejo instance
The platform team installs Forgejo in the organization's own infrastructure, configures storage, backups and TLS, and confirms the release line it will run, checking the upgrade and support documentation before choosing between a stable release and an LTS release. The check is that a test repository can be created, pushed to and browsed by the intended users. Ask your implementation partner or your own team to confirm the install method against the current Forgejo documentation.
Move repositories and issues
Repositories are migrated with Forgejo's migration tooling, and issues, pull requests and releases are carried across using the dump and restore commands described in the dedicated migration guide. Owners verify branch and tag counts, open issues and recent pull requests against GitHub. The step is complete when a sample of repositories matches the source and the team confirms that review history is readable.
Place workflows in .forgejo/workflows
Developers copy workflow files into
.forgejo/workflowsfor repositories that need Forgejo-specific behavior. Forgejo falls back to.github/workflowswhen.forgejo/workflowsis absent, so unchanged repositories can run without edits, but the fallback should be treated as a transition aid rather than a permanent layout. The check is that each workflow appears in the Forgejo Actions interface and is triggered by a test event.Fix documented differences
Engineers work through the differences listed in the Forgejo Actions documentation, which is designed to be familiar to GitHub Actions users but is not compatible with it. Typical edits involve action references, expressions, permissions and runner labels. Each fix is tested on a branch before merge. The step closes when every workflow passes on Forgejo and any skipped or changed behavior is recorded for the team.
Re-create secrets and variables
Because GitHub returns only secret names through its API, maintainers re-enter each secret value in Forgejo at the repository or organization level, using the names recorded in step one. Deployment credentials should be rotated during this step rather than copied, so that the old values stop working after cutover. The check is that a deploy-free test pipeline can read each secret without printing it in logs.
Register Forgejo Runners
The platform team installs Forgejo Runner on build hosts inside the network, assigns labels that match the
runs-onvalues in the workflows, and restricts runners to the repositories that need them. Runner hosts are hardened and kept separate from production systems. The step is done when jobs queue and run on the expected labels and each runner's host and access are documented.Cut over and retire GitHub pipelines
Teams switch their default remote and webhooks to Forgejo, run a parallel build period agreed in writing with the owners, then disable GitHub Actions for migrated repositories. Build artifacts and logs still held on GitHub are exported before their retention expires. Cutover is complete when all production deployments are triggered from Forgejo, GitHub schedules are disabled, and the runbook has been handed to the operations team.
Cost components on each side
Hosted CI bills for minutes, runners, storage and seats, while a self-hosted forge moves those costs onto servers, runner hosts and the staff who run them. The cards below set each component against its Forgejo counterpart and say whether it is one-time or recurring.
GitHub-hosted minutes and runner charges
GitHub-hosted minutes are a recurring usage charge that scales with build count, build duration and runner size. GitHub announced a per-minute charge for self-hosted runners of $0.002 per minute and then postponed it, so the self-hosted runner line is free today but is not guaranteed to stay that way. Ask GitHub for the current written terms before you size a budget around either option. On the Forgejo side, the matching cost is the compute your Forgejo Runner hosts consume, which you control directly.
Seat and plan costs
On GitHub, the seats and plan tier you pay for are recurring and set how many users can administer and run workflows across private repositories. Forgejo has no per-seat licence fee from the project, so its recurring cost is the staff and infrastructure needed to host it. Confirm with each vendor which features your team actually needs, because some Actions controls depend on the tier you choose.
Storage for artifacts and logs
Hosted storage for artifacts and logs is billed and time-limited. GitHub Actions retains artifacts for 90 days by default, so long-term retention means exporting them and paying for storage elsewhere. On Forgejo, artifact and log storage is a recurring cost on disks or object storage you provision, sized by retention policy. Decide how long build history must stay available, then size storage for that period.
Runner hosts and capacity
On the Forgejo side, runner hosts are the largest recurring line. Each Forgejo Runner needs compute sized to peak concurrent jobs, and idle capacity still costs money. Runners on Kubernetes or VMs add node and autoscaling costs. Ask your team to measure peak concurrency for a typical month, then compare that figure with the GitHub-hosted minutes you would otherwise consume.
Upgrade effort and support
Running Forgejo means planning upgrades. Stable releases get three months of full support plus a two-week window, while LTS releases, published in the first quarter of each year, get one year and three months of critical bugfix and security support. Budget recurring staff time for upgrades, and decide whether to buy support from a vendor or rely on internal skills and community help.
Staff time and backups
Staff time is the cost most often left out. GitHub's operations are included in the subscription, while a self-hosted Forgejo needs people for installation, backups, monitoring, security patching and runner maintenance. Backups of the Forgejo database, repositories and CI data are a recurring duty. Ask for a written estimate of hours per month from anyone quoting the work, and confirm who carries on-call responsibility.
Questions buyers ask before choosing Forgejo Actions
How much does switching from GitHub Actions to Forgejo Actions cost?
The software license is not the main cost. Forgejo is GPL-3.0-or-later from v9.0 onward, so there is no per-seat or per-minute license fee to pay. The recurring costs are the servers or VMs for the Forgejo instance, the Forgejo Runner hosts, storage for logs and artifacts, backups, and staff time for upgrades and monitoring. The one-time costs are migration work: moving repositories, rewriting workflows that use GitHub-only features, re-creating secrets and testing pipelines. Costs rise with the number of workflows, runners, repositories and the amount of run history you keep. Ask any implementation partner for a written scope that lists each of these items separately, plus what is included in ongoing support.
How long does a Forgejo Actions migration take?
Duration depends mostly on how many repositories and workflows you have, how many use marketplace actions or GitHub-specific features, and how much run history you need to keep. A small set of repositories with simple workflows moves far faster than a large monorepo estate with custom actions and deployment environments. Plan a pilot on a few representative repositories first, then batch the rest. Forgejo's own migration tooling covers issues, pull requests and releases through dump-repo and restore-repo, but workflow testing is still manual. Ask for a timeline tied to repository count and workflow complexity in the written scope rather than accepting a generic estimate.
What does my internal team need to run Forgejo Actions?
Your team needs people who can operate a self-hosted Forgejo instance and its runners. That means Linux administration, a database and backup routine, reverse proxy and TLS configuration, runner registration and capacity planning, and a way to apply upgrades. Developers need to understand the differences between GitHub Actions and Forgejo Actions, because Forgejo is designed to be familiar to GitHub Actions users but is not compatible with it. Security staff should review how runners are isolated and how secrets are stored and rotated. Confirm with the vendor or your own environment which runner executors and container runtimes you plan to use, since those choices shape the skills you need.
Can we run a Forgejo Actions migration ourselves, or do we need a partner?
Yes, a capable internal team can do it, provided it has the operations skills described above and time to test workflows. The decision usually comes down to available staff, the number of workflows that need rewriting, and whether you need evidence for an audit. A partner is useful when you want a fixed-scope plan, hardening, backup design and documented runbooks delivered in writing before work starts. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in advance. Ongoing support and upgrades are available as retainers.
How do Forgejo support windows and LTS releases affect our planning?
Forgejo stable releases receive full support for three months plus a two-week window, so a stable version can fall out of full support quickly. LTS releases, published in the first quarter of each year, receive critical bugfixes and security support for one year and three months. The v15 LTS release is supported until July 15, 2027, and v17.0.0, released on October 15, 2026, is supported until January 28, 2027. For a regulated environment, pin to an LTS line and schedule upgrades within its support window. Build the upgrade calendar into your operating budget, because each upgrade needs testing of runners and workflows. Check the current release list on the Forgejo releases page before you commit to a version.
Will our existing GitHub Actions workflows run unchanged on Forgejo Actions?
Not without review. Forgejo Actions is designed to be familiar to GitHub Actions users, but it is not compatible with GitHub Actions, so workflows usually need edits. Forgejo reads workflows from .forgejo/workflows and falls back to .github/workflows when that directory is absent, which eases the first move. Expect to adjust workflows that depend on GitHub-only features, specific permission scopes, or actions that are only published on github.com. Forgejo's upgrade guide and Actions overview are the right places to check which constructs differ before you test. Run each critical pipeline in a staging repository and compare its output with the GitHub run before you cut over.
How do secrets and build history move when we leave GitHub Actions?
Secrets usually cannot be exported. GitHub's REST API returns Actions secret names without values, so you must re-create each secret in Forgejo from its source system and rotate credentials as part of the cutover. Build history is also time limited on GitHub, where artifacts default to 90 days, so export logs and artifacts through the API or GitHub CLI before retention expires. Plan this export early and record which runs must be preserved for audit. Your security team should decide how new secrets are scoped, stored and rotated on the self-hosted instance.
How DeployOpen helps you evaluate and move to Forgejo Actions
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a Forgejo Actions decision, that usually starts with an evaluation scoped in writing before any work begins: which repositories and workflows are in play, which ones rely on GitHub-only features that Forgejo does not match, which secrets must be re-created by hand because GitHub never exports their values, and how much build history must be exported before GitHub retention windows close. Most engagements are fixed-scope, so the deliverables, timelines and acceptance checks are agreed in writing first, and a quote follows from that scope. DeployOpen does not publish a price list.
The migration work covers the forge and the CI layer together: installing and configuring Forgejo, moving repositories, placing workflows in .forgejo/workflows, reviewing where the fallback to .github/workflows is in use, and testing each workflow against the documented differences. Runner hardening is the part teams most often underestimate. A Forgejo Runner executes code from pull requests, so you need decisions on runner isolation, which jobs can reach production credentials, how runner registration tokens are issued and rotated, and where runner logs and artifacts are stored. DeployOpen can document those decisions and produce the configuration and evidence that your own auditors or assessors will request. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications; independent auditors and certification bodies do that work.
After go-live, upgrades are the recurring cost. Forgejo publishes release dates and support windows, so the retainer question is how often your team wants to move to a new stable release versus a long-term support release, and who tests workflows before each upgrade. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which you can scope separately from the initial migration. Ask any implementation partner, including DeployOpen, to state in writing what is included in the fixed scope, what is excluded, who owns backups and restore tests, and what happens if a workflow needs more rework than the scope assumed.
