When GitHub Actions or Gitea Actions fits your GitHub Actions alternative decision
Gitea Actions fits teams that want to host Git and CI in their own infrastructure and accept some workflow edits. GitHub Actions fits teams that want hosted runners and no forge to operate. The choice turns on five things you can measure before you commit: how many workflows depend on marketplace actions, which permission scopes those workflows request, how many secrets must be re-created by hand, how long build artifacts must be kept, and who will run the platform after cutover. Gitea Actions is designed to be compatible with GitHub Actions wherever possible, but the documented gaps, such as unsupported permission scopes and ignored problem matchers, mean compatibility is a property you verify per workflow, not something you assume.
Start with an inventory. Count the workflows in each repository, list every uses: reference, and sort them into three groups: actions that are plain shell or Docker steps, actions that are well-known and can be vendored or mirrored, and actions whose behavior depends on GitHub-specific tokens or APIs. The third group sets your real migration effort. Next, review each workflow's permissions: block and the GITHUB_TOKEN scopes it relies on, because a scope the Gitea implementation does not support will fail at runtime rather than at parse time. Export the list of secret names from GitHub, since the REST API returns names without values, and plan to re-enter every value from your secrets source. Also record your artifact retention needs for audit or release purposes, because hosted retention on GitHub is time-limited and your self-hosted retention will be whatever your storage and cleanup policy say.
The operating model decides whether the trade is worth it. Gitea Actions means your team runs the forge, the database, backups, upgrades and at least one runner pool, and the Git hosting itself moves with the CI. If no one on your team owns that work, GitHub Actions with hosted runners, or a commercial self-managed edition with vendor support, may match your constraints better. If you need vendor-backed features such as SAML service provider support, audit logging or IP allowlisting, confirm which edition of Gitea provides them with CommitGo, Inc. before you plan around them. Ask for a written statement of what moves, what stays and who is accountable for each piece, and run a pilot repository with its most complex workflow before you decide the whole estate.
Which option fits which scenario
This table matches common scenarios to the option that fits best, with the documented reason for each choice. Read each row as a starting point, then confirm the named gap or dependency against the current Gitea documentation and your own environment before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Data residency requirement in your own EU datacenter | Gitea Actions or Woodpecker CI on your own infrastructure | Gitea is self-hosted and runs on MySQL, PostgreSQL, SQLite or MSSQL, so repositories, logs and artifacts stay where you deploy them. Confirm where runner caches and logs are written in your setup. |
| Team with many GitHub Marketplace actions | Gitea Actions, after an inventory | Gitea Actions is designed to be compatible with GitHub Actions wherever possible, so workflows that use common actions carry over more easily. Check each action against the documented comparison, since some features are not supported. |
| Workflows that depend on fine-grained GitHub token permissions | Confirm before choosing Gitea Actions | The Gitea comparison documents unsupported permission scopes. Test each permission your workflows request on a staging instance before committing to this path. |
| Air-gapped network with no internet access | Gitea Actions with pre-mirrored actions | Gitea runs fully self-hosted, so the forge and runners can sit inside an isolated network. Actions that reference github.com must be mirrored or hosted on the local instance first, and runner images must be supplied internally. |
| Small team with no dedicated platform staff | Gitea Actions if a single forge is preferred | One self-hosted service covers Git hosting, code review and CI/CD. Someone still has to run upgrades and backups, so ask a provider for the operating model before committing. |
| Team that must keep GitHub as the forge | Woodpecker CI, connected to GitHub | Woodpecker CI connects to GitHub as a forge, so builds can move in-house without moving repositories. Gitea Actions requires the code to live on the Gitea instance. |
| Team that wants a GitLab-style all-in-one forge | GitLab CI/CD on a self-managed instance | GitLab bundles the forge and CI in one product with its own runner executors. Compare its installation and upgrade obligations with Gitea before deciding. |
Where your code, logs and secrets live under each model
Moving CI from GitHub Actions to Gitea Actions changes more than the workflow engine: it changes who hosts the repositories, where run logs and artifacts sit, and who controls identity. The cards below separate the three hosting models and the risks each one carries, so the choice is made against your own data and compliance obligations.
Repositories and workflow files
Under GitHub Actions, repositories, pull requests and workflow YAML sit on GitHub's infrastructure. With self-hosted Gitea, the same data sits on servers you operate, while Gitea Cloud keeps it with a managed provider. Confirm which region and provider hold each copy, and who holds administrative access to the database and file storage. Workflow files live in the repository, so they move with the code during a migration.
Run logs and build artifacts
GitHub Actions keeps artifacts for a default period of 90 days, so logs and artifacts from older builds leave GitHub on a fixed schedule. A self-hosted Gitea instance keeps them according to the retention and storage settings you configure, so retention becomes a policy decision. Check where artifact storage is configured, whether logs contain sensitive values, and how long your audit obligations require them to exist.
Secrets and their custody
GitHub's REST API returns Actions secret names without values, so secrets cannot be copied out of GitHub during a move. Under Gitea Actions, secrets are re-entered in the new instance and stored in its database, which makes the Gitea server and its backups part of your secrets boundary. Plan for rotation of every credential that a workflow used, and restrict who can read or change secrets at the organization and repository level.
Identity, SSO and SAML
Self-hosted Gitea supports sign-in through its own accounts and external authentication sources, so your identity design needs to be settled before users are migrated. Gitea Enterprise from CommitGo adds SAML 2.0 service provider support, mandatory two-factor authentication and IP allowlisting, which are capabilities to compare against your current GitHub organization settings. Confirm which of these features your identity provider and policies require before choosing an edition.
Compliance evidence and audit logging
Auditors will ask who changed workflows, who read secrets and where build data was processed. Audit logging is listed as an Enterprise feature from CommitGo, so a community install may need its own logging pipeline. DeployOpen prepares the systems, controls and evidence for a compliance assessment, but it does not issue audit reports or certifications; an independent auditor or certification body does that work.
Who operates the hosting
GitHub operates the hosted service and its underlying storage, and Gitea Cloud shifts operation to a managed provider. A self-hosted Gitea instance makes your team responsible for patching, backups, database health and access control. Ask any provider for written statements on data location, subprocessors, backup encryption and incident notification, and check whether those terms match your regulatory requirements.
What workflow YAML and actions carry over from GitHub
Gitea Actions is designed to be compatible with GitHub Actions wherever possible, so most of the job structure your team already maintains should carry over: trigger definitions, job graphs and the majority of run steps. Use the Gitea comparison page as the working list of differences and check each workflow against it. Two changes apply to every repository. Workflows must sit under .gitea/workflows, so a file left in .github/workflows will not run until it is moved or copied. Actions referenced without a host are fetched from github.com or from your local instance, so list every external action your pipelines use and confirm whether your runners can reach github.com or whether those actions must be mirrored to your own instance first.
The review work concentrates on two areas. The first is permissions. Workflows that restrict the GITHUB_TOKEN with a permissions block, or that depend on a scope Gitea does not honor, will behave differently, so identify every step that calls the API, publishes a release or writes to another repository and confirm how Gitea handles that scope in the version you deploy. The second is problem matchers. Gitea ignores them, so any pipeline that relies on them to turn compiler or linter output into inline annotations needs an explicit replacement, such as a parsing step that fails the job or writes a summary. Record each change in the repository so reviewers can see what was altered and why.
Test each workflow on a registered Gitea runner before cutover. Use a staging repository or a non-production branch, trigger every event type the workflow handles (push, pull request, tag and manual dispatch), and compare the results with the matching GitHub runs. Secrets never leave GitHub in readable form, so re-enter each one on the Gitea side and confirm that the jobs which read it succeed. Run deployment steps against a non-production target first. Keep the GitHub workflow active until every pipeline passes, and confirm the exact compatibility behavior with the Gitea release you plan to run, since the documented gaps can change between versions.
How runner setup and day-two operations differ
On GitHub, most teams start with GitHub-hosted runners, so GitHub provisions the build machines and your team manages only workflow files, repository settings and secrets. Jobs run on capacity the platform operates, which means no build hosts sit in your network. Self-hosted runners are also available on GitHub, but pricing for them has moved: GitHub announced a per-minute charge for self-hosted Actions runners and then postponed it, so confirm the current terms before you model costs.
- Provisioning: Runner machines are managed by the platform, so your team patches and scales none of them.
- Control over images and network: Hosted images, egress paths and runner sizes follow GitHub's options, so list the labels and tools your jobs depend on.
- Secrets: Secrets are set in repository or organization settings, and the REST API returns secret names without values.
- Retention: Artifacts default to 90 days, which sets how long you have to export run history before a move.
Before you replace hosted runners, check which runner labels, images and network paths your current workflows rely on.
Gitea Actions runs jobs on Gitea Runner, which you install on machines you control and register against your Gitea instance. Each registered runner advertises labels, and a job runs only on a runner whose labels match the runs-on value in the workflow. Your team therefore chooses the host, the labels and the isolation model, and owns the capacity that GitHub supplies today. The Gitea documentation describes the registration steps for each version.
- Registration token: Obtain a registration token from the instance and bind the runner to the instance URL. Confirm where tokens are generated for your version.
- Labels: A job whose label matches no registered runner waits, so register runners for every label your workflows use.
- Action sources: Actions referenced without a host are fetched from github.com or the local instance, so confirm outbound access from runners in restricted networks.
- Isolation: Decide whether runners are shared across projects, dedicated per team, or ephemeral, and record the choice for auditors.
Test one repository on a single registered runner before you open the runner pool to other teams.
A self-hosted Gitea instance makes upgrades your responsibility. The release history covered here runs from the v1.27 line, where v1.27.3 shipped on August 29, 2026, to the v28 line, where v28.0.0 was released on September 29, 2026 and v28.1.0 on October 6, 2026. Treat each move between lines as a planned change with a tested rollback point, because Gitea Actions compatibility with GitHub is a design goal, not a guarantee for every workflow.
- Release tracking: Follow the go-gitea/gitea releases page and read the notes for every version between your current install and the target.
- Staging copy: Upgrade a copy of production data, including the database and repositories, before touching the live instance.
- Runner versions: Check that each Gitea Runner version works with the instance version you move to.
- Workflow retests: Rerun representative workflows after each upgrade, since runner and syntax behavior can change.
Ask who owns upgrade windows, approvals and rollback, and confirm the rollback steps in the notes for your target version.
Gitea supports MySQL, PostgreSQL, SQLite and MSSQL, and the database choice shapes backups, failover and the skills your operations team needs. Repository data on disk and the database must be backed up together so that they describe the same point in time. TLS, certificate renewal and the reverse proxy in front of the instance are also yours to operate, so each of these duties needs an owner before go-live.
- Database choice: SQLite fits small single-node installs. Teams with larger workloads usually plan for a server database, so confirm which engines your organization supports and maintains.
- Consistent backups: Capture the database and repository storage at the same point, and schedule restores as well as backups.
- Wider backup scope: Include attachments, any package registry storage you enable, and the runner configuration.
- TLS termination: Terminate HTTPS at the instance or at a reverse proxy, and automate certificate renewal.
- Platform support: Gitea runs on Linux, macOS and Windows, so confirm which platform your operations team can support in production.
Request a documented restore test from your implementation partner before the instance carries production repositories.
How cost splits between GitHub-hosted minutes and running Gitea
The main cost shift is from a metered usage line to fixed infrastructure plus labor. On the GitHub side, the recurring costs are hosted runner minutes, storage for artifacts and logs, and any charge for self-hosted runners. GitHub announced a $0.002 per minute charge for self-hosted runners and then postponed it, so that line is not settled. Confirm the current runner and storage terms against GitHub's pricing announcement and ask for them in writing, because a postponed charge can return. Your own cost driver is volume: the number of jobs, their duration, and how long you keep logs and artifacts. Those settings are within your control on both platforms.
Gitea itself is MIT licensed, so there is no license fee for the software. The recurring costs are the servers or virtual machines that run Gitea, the database you choose (MySQL, PostgreSQL, SQLite or MSSQL), storage for repositories, packages, logs and artifacts, backups with periodic restore tests, and compute for the runners that execute jobs. Staff time for upgrades and monitoring is usually the largest line and is easy to underestimate. One-time costs include the migration itself, runner setup, and rewriting workflow steps that Gitea Actions does not support. Costs rise with concurrent jobs, longer artifact retention, and high-availability requirements, and fall when you limit retention and right-size runners.
Commercial support from CommitGo is optional. Gitea Enterprise adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning, so it is worth paying for only if those controls are required by your policies. Gitea Cloud is a managed alternative if you do not want to operate the forge. Whatever route you take, ask every quote to list in writing: the license or subscription, the hosting and storage assumptions, backup and restore responsibilities, upgrade work, support hours and response terms, and whether each item is one-time or recurring. Ask DeployOpen the same question, with the scope and deliverables agreed in writing before work starts.
What a move from GitHub Actions to Gitea Actions involves
The sequence moves Git hosting, workflows and secrets from GitHub to a self-hosted Gitea forge with a registered runner, and ends with a tested cutover. Each phase produces a record that the next phase depends on.
Inventory repositories, workflows, actions and secrets
The platform or DevOps lead lists every repository that uses GitHub Actions, the workflow files in each one, the third-party actions they call, the self-hosted runners in use and the secret names defined at repository, environment and organization level. Secret values cannot be read back from GitHub, so the inventory records names and owners only. The step is done when each workflow has an owner, each external action is marked as fetched from github.com or copied locally, and each secret has a named consumer.
Export run history and artifacts before retention expires
Before any cutover, the team exports the run logs and build artifacts that auditors, release managers or incident responders may need, using the REST API or the GitHub CLI. GitHub keeps artifacts for a limited default retention period, so this export has to start early and be checked against the retention settings in each repository. The output is a stored archive with an index that maps each run to its commit, branch and approver. Confirm the current retention settings with GitHub's documentation for your plan.
Migrate repositories with the built-in GitHub migration form
A Gitea administrator or repository owner uses the GitHub migration option in the Gitea interface to copy repositories, and then selects the items to bring across, such as issues, pull requests, labels and releases, where the form offers them. The team compares branch counts, tags and the default branch against GitHub, and checks that issue and pull request references resolve. The step is complete when each migrated repository matches its source for commits, branches and tags, and the known gaps are written down.
Place workflows in the Gitea directory and fix incompatibilities
Developers copy workflow files into the Gitea workflow directory, typically
.gitea/workflows, and then run each one against a test branch. Gitea documents differences from GitHub Actions, including permission scopes it does not support and problem matchers it ignores, so each workflow is reviewed against that list and edited where it relies on an unsupported feature. Actions that have no host on the Gitea instance are fetched from github.com or from a copy on the local instance, which the team confirms against its network policy. The step is done when every workflow passes on a test branch with no silent skips.Re-create secrets that GitHub never returns
The security or platform owner re-enters each secret in Gitea at the matching scope, using values from the system of record that issued them, such as the cloud account, registry or deployment target. Because GitHub's API returns secret names without values, the values cannot be copied across, so tokens that have been exposed or are no longer needed should be rotated at the same time. The step is done when the secret inventory from the first phase is matched name by name, and each deploy credential has been tested on a non-production target.
Register Gitea Runner and set runner scope
The platform engineer installs the Gitea Act runner on hosts or containers inside the organization's network, registers each runner with the Gitea instance using a registration token, and assigns labels that match the
runs-onvalues in the workflows. Runners that build production artifacts are isolated from runners that run untrusted pull requests, and their access to networks and cloud accounts is limited to what each job needs. The step is complete when a test job runs on each label, logs appear in Gitea, and a job without a matching label is shown as waiting rather than failing silently.Run pipelines in parallel and confirm results
For a defined period, both systems run the same pipelines against the same commits, and the team compares build status, test counts, artifact checksums and deployment results between GitHub Actions and Gitea Actions. Differences are logged with a cause and an owner, and any difference that changes a release artifact blocks cutover until it is resolved. The step closes when the team signs off on parity for each critical pipeline, and the product owners agree which failures are acceptable during the overlap.
Cut over and retire GitHub workflows
The team switches the default branch protections, deployment triggers and status checks to Gitea, disables scheduled workflows on GitHub to avoid duplicate runs, and archives the GitHub repositories as read-only. Runbooks are updated with the new run locations and the escalation path for runner failures. The step is done when no production deployment depends on GitHub Actions, the archived history is confirmed as readable, and the team has a documented rollback path for the cutover window.
Questions buyers ask before switching from GitHub Actions
How much does it cost to switch from GitHub Actions to Gitea Actions?
The software itself is free to download under the MIT license, so the cost is in the work and the infrastructure. Expect one-time costs for the migration project, runner hosts, and workflow fixes, and recurring costs for servers, storage, backups, upgrades and the people who operate the forge. The main drivers are the number of repositories and workflows, how many use marketplace actions that need changes, how much run history you keep, and whether you need Gitea Enterprise for SAML, audit logging or IP allowlisting. Ask for a quote built from a written scope that lists these inputs. Ask Gitea for current Enterprise pricing directly, since DeployOpen does not publish prices.
How long does a GitHub Actions to Gitea Actions migration take?
The timeline depends on scope, not on a fixed duration. The biggest variables are how many repositories and workflows you have, how many of them rely on GitHub-only features or on actions fetched from github.com, how many secrets must be re-entered by hand, and how many runners you need to register and test. Teams with a small set of repositories and simple workflows move faster than teams with shared reusable workflows and many environments. Gitea's documented differences, such as unsupported permission scopes and ignored problem matchers, add test cycles. Agree the timeline in the written scope before work starts, and confirm the migration steps with Gitea's documentation for your version.
What does my team need to provide for the migration?
You will need people who own the repositories and workflows, people who can approve access to the target environment, and someone who can make decisions about secrets, runners and deployment targets. Engineers must test each pipeline on the new runners, and your security team should review how the forge and runners authenticate. Plan for someone to own the Gitea server after go-live, covering upgrades, backups, runner capacity and access reviews. Confirm with your own infrastructure team which network, DNS, certificate and storage services the new forge will rely on, and where runners can reach external package sources.
Can we run the switch ourselves without outside help?
Many teams can, provided they have engineers comfortable with Linux servers, containers, Git hosting and CI runners. Gitea's documentation covers installation, the built-in GitHub migration form and runner registration. The harder parts are usually the workflow edits, the secret re-creation and the operational runbooks for upgrades and backups. Outside help is useful when you need a fixed-scope plan, hardening, evidence for an assessment, or a test of workflows before cutover. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, under a written scope. It does not issue audit reports or certifications.
How are secrets and artifact history handled when we leave GitHub?
Secrets do not move automatically. GitHub's REST API returns Actions secret names without their values, so you must re-create each secret in the new system from its source, such as your vault or the team that issued the credential. Plan a rotation for any credential that was exposed or shared widely. Build artifacts and run logs expire on GitHub, and GitHub Actions defaults to 90 days, so export the history you need before the retention window closes. Confirm the export method and the rate limits for bulk export against GitHub's current documentation before you set the plan.
Will Gitea Actions run our existing GitHub Actions workflows unchanged?
Gitea Actions is designed to be compatible with GitHub Actions wherever possible, so many simple workflows carry over with little change. Expect edits where your workflows use features Gitea documents as unsupported or different, such as some permission scopes and problem matchers, which are ignored. Actions that reference github.com must be fetched from github.com or from a copy on your own instance, and that affects air-gapped and restricted networks. Run a sample of your highest-value workflows on a test runner and compare results before you plan the cutover. Gitea's comparison page lists the documented differences to check against your workflows.
Does moving Git hosting off GitHub also require moving CI?
No, you can choose the order. Some teams move repositories and CI together, while others keep code on GitHub and move builds to a self-hosted engine such as Woodpecker CI, which connects to GitHub as a forge. Moving the forge and CI together gives one system to operate, but it also means moving pull requests, issues, permissions and workflow files in one project. Decide which option fits your risk tolerance and staffing before you write the scope.
How DeployOpen helps evaluate and implement a Gitea-based CI
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Gitea-based CI move, the useful first step is a fixed-scope evaluation agreed in writing before any work starts. That evaluation typically inventories the GitHub workflows in use, flags the steps that depend on features Gitea Actions documents as unsupported or ignored (such as certain permission scopes and problem matchers), lists which marketplace actions need a local or github.com source, and records which repositories, environments and deployment jobs depend on secrets. The written scope then sets the deliverables and timelines. A quote follows from that scope. DeployOpen is not a Gitea partner or reseller, and it does not hold any vendor certification for Gitea.
Implementation usually covers three areas. The first is migration of workflows and secrets: moving files into the .gitea/workflows directory, fixing incompatibilities found in the evaluation, and re-creating every secret by hand, because GitHub's REST API returns secret names without values and those values cannot be exported. The second is runner hardening: deciding where Gitea Runner executes jobs, isolating builds that handle production credentials, restricting who can register runners, and keeping runner hosts patched. The third is security testing of the new pipeline and forge, covering workflow injection paths, token scopes and exposed endpoints. Retainers are available for ongoing work such as tracking Gitea release lines, applying upgrades in a test environment first, and running periodic tests. Ask for the Gitea version targeted, the runner design and the acceptance criteria in the written scope, since those drive most of the effort.
