Self-hosted GitHub Actions alternative for air-gapped networks

When builds must run with no internet access, GitHub's answer is GitHub Enterprise Server with self-hosted runners and actions copied in with actions-sync. Here is how Gitea, Forgejo, Woodpecker CI and Jenkins compare under that constraint.

Book a callTalk to us
On this page

Why an air-gapped network changes the GitHub Actions decision

GitHub's own answer for an isolated network is GitHub Enterprise Server with self-hosted runners, and several open-source engines can also run with no internet access. The choice turns on one question: must the forge and the CI engine both live inside the isolated zone, or can the repositories stay where they are while only the builds move? GitHub's documentation states that Actions on GitHub Enterprise Server is designed for environments without full internet access, and that by default workflows cannot use actions from GitHub.com or GitHub Marketplace. That default is the first thing to test, because many existing workflows call marketplace actions by name. Ask your team to list every uses: reference across its workflows before choosing a path.

If the forge must also sit inside the zone, your options are GitHub Enterprise Server, Gitea or Forgejo, each with its own built-in CI. Gitea describes itself as an MIT-licensed, self-hosted service that combines Git hosting, code review, package management and CI/CD, and Gitea Actions is designed to be compatible with GitHub Actions workflows. Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with them, so existing workflows need edits and a separate runner. If the code can stay in a forge that the isolated network can reach, Woodpecker CI connects to GitHub, GitLab, Gitea, Forgejo, Bitbucket and Bitbucket Datacenter, so builds can run offline while the repositories remain in that forge. Confirm the forge path with your network team before relying on it.

Whichever engine you choose, plan for the copy-in work, because it recurs. GitHub's documentation says actions-sync can only download actions stored in public repositories on GitHub.com, and that bundled actions are replaced during GitHub Enterprise Server upgrades, so the sync must be rerun after each major or minor upgrade. Jenkins has a similar maintenance point: its integrations come from more than 2,300 plugins, and Jenkins LTS 2.580.1 stopped bundling several plugins, including the SSH server and JUnit plugins, so administrators must install them through the plugin manager. Before approving a design, confirm with each vendor how every action, plugin or package will be copied in, updated and verified inside the zone. Manually syncing actions from GitHub.com sets out the GitHub side of that process.

What an air-gapped CI setup must satisfy

An isolated network removes the default path between your builds and GitHub.com. Each card below is a requirement that the CI design has to meet before any pipeline runs, and each one is a point to check with GitHub or your chosen platform before you commit to a design.

No default access to GitHub.com

Workflows on GitHub Enterprise Server cannot use actions from GitHub.com or GitHub Marketplace by default, because the instance is designed to work without full internet access. Your builds therefore fail on any uses: reference to a public action until that action is present locally. Inventory every action your workflows call before the network is cut, since a missing action surfaces as a failed run rather than a warning.

Actions must be copied in

Without GitHub Connect, actions-sync copies selected action repositories from GitHub.com into the instance. It can run in pull and push steps when no single machine reaches both systems at once, which suits a transfer through a controlled staging host. Decide who approves each action, who runs the transfer, and how the transfer is logged so the enclave keeps a record of what entered it.

Only public repositories sync

actions-sync can only download actions stored in public repositories on GitHub.com. Any action that is private, vendored inside a closed repository, or published only as a container image from a private registry needs a separate route into the enclave. Check each action's source repository visibility during the inventory, and plan a rebuild or internal mirror for anything that fails this test.

Rerun the sync after upgrades

Bundled actions are replaced during GitHub Enterprise Server major and minor upgrades, so a sync that worked last quarter can leave pipelines broken after an upgrade. Treat the sync as a standing step in the upgrade runbook, verify the copied versions afterward, and confirm with GitHub which bundled actions change in each release you plan to adopt.

Runners inside the enclave

Self-hosted runners must sit inside the isolated network and reach only the internal instance, package mirrors and registries you control. Confirm how each runner gets its base images, toolchains and language packages without pulling from public sources, because a runner that quietly fetches from the internet breaks the isolation model.

Logs, artifacts and secrets stay put

Run logs, build artifacts, caches and secrets must be stored on enclave storage, with retention and access policies you set. Ask each platform where it writes these objects, how it encrypts secrets at rest, and whether any telemetry or update check leaves the network. These answers belong in your security review before the first production pipeline.

How each option handles offline builds

This table compares how GitHub Enterprise Server, Gitea Actions, Forgejo Actions, Woodpecker CI and Jenkins handle builds with no internet access, along with license and upkeep trade-offs. Read each row as a question to confirm in your own isolated network, since the supplied facts describe design intent and documented behavior rather than tested results in your environment.

OptionOffline approach and what to confirmLicense and main trade-off
GitHub Enterprise Server with actions-syncRuns without full internet access by design, but workflows cannot use GitHub.com or Marketplace actions by default. actions-sync copies selected public actions in, and must be rerun after each major or minor upgrade.Commercial GitHub Enterprise license. Trade-off: only public GitHub.com action repositories can be synced, so private actions need another path.
Gitea ActionsBuilt into the Gitea forge and designed for GitHub Actions compatibility. Confirm that runners, container images and any actions a workflow references are vendored inside the isolated network, since actions are not fetched from github.com there.MIT license. Trade-off: GitHub Actions compatibility is designed, not complete, so workflows need review and you vendor the actions you use.
Forgejo ActionsBuilt-in CI that hands jobs to separate Forgejo Runners. Confirm runner registration, image mirroring and action sources work with no outbound route, because the supplied facts do not describe a tested offline setup.GPL-3.0-or-later from v9.0 onward. Trade-off: familiar to GitHub Actions users but not compatible, so workflow files need edits and actions must be vendored.
Woodpecker CIContainer-step engine that can run builds on agents inside the network. Confirm the forge connection, plugin images and base images are mirrored locally, because plugins are normally pulled from registries.Apache-2.0 license. Trade-off: not a GitHub Actions clone, so you maintain plugin images and translate marketplace actions into container steps.
JenkinsController and build agents run inside the network, and plugins are installed from a local update mirror or artifact store. Confirm the plugin mirror and Java runtime are available offline.MIT license. Trade-off: plugin upkeep and LTS upgrades are your work, and some bundled plugins now need manual installation after LTS 2.580.1.
Ongoing vendoring effortEvery option needs a process to copy actions, plugins, base images and dependencies into the isolated network and to refresh them on a schedule.Recurring staff time. Ask each vendor or your team to document the update path for each artifact type.

Where GitHub's offline path needs the most manual work

The main manual work on GitHub's offline path comes from actions-sync, the tool that copies actions into a GitHub Enterprise Server instance without GitHub Connect. GitHub's documentation says it can only download actions stored in public repositories on GitHub.com, so any private or internal action your workflows depend on has to be handled another way, such as moving it into the isolated network through your own review process. Before you commit to this path, inventory every uses: reference in your workflows and confirm which of those actions live in public repositories and which do not. The tool also works in pull and push steps when no single machine can reach both GitHub.com and the enterprise instance at once, so the transfer becomes a repeated handoff through a staging host rather than one automated call.

The heavier recurring burden is the upgrade cycle. GitHub's documentation states that bundled actions are replaced during GitHub Enterprise Server upgrades, so the sync must be rerun after each major or minor upgrade. For a platform team, that makes every GitHub Enterprise Server upgrade a dependency event: freeze the set of approved action repositories and versions, run the pull and push steps in order, verify that each action resolves on the isolated instance, and record the result before workflows go back into service. Ask GitHub or your account team to confirm the current upgrade sequence for your version, and ask who owns each step in your change process.

A DeployOpen engagement would document this procedure for your environment: the approved action list, the staging host and transfer media controls, the sync runbook, the upgrade checklist, and the evidence each run produces. Where it fits your scope, the transfer and verification steps can be scripted and tested in a cyber range before production use. We do not promise a fixed reduction in effort or a specific outcome; the scope, deliverables and timeline are agreed in writing before work starts.

Which engine fits which air-gapped situation

Teams that already maintain .github/workflows files and want the least rewriting should start with Gitea Actions. Gitea designs its built-in CI to be compatible with GitHub Actions wherever possible, so many workflows can be carried over with edits limited to the documented gaps. Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible, so workflows need more editing.

  • Compatibility scope: The Gitea comparison page lists the gaps, including unsupported permission scopes and ignored problem matchers. Review every workflow against that list before the move.
  • Marketplace actions: Actions that reference github.com are not available by default inside an enclave. Each one must be copied in as a local action or replaced with an internal equivalent.
  • Runner model: Gitea Actions uses its own runner process registered to the instance. Build runner images with every toolchain your jobs need, because they cannot fetch dependencies from the internet.
  • Forgejo difference: Forgejo Actions reads .forgejo/workflows and falls back to .github/workflows when the first is absent, but its documented differences still require edits to most workflows.

Confirm with Gitea which GitHub Actions keywords, contexts and expressions your current workflows use, and whether each one is supported in the release you plan to deploy.

How to deploy a self-hosted CI stack inside the enclave

This sequence takes a CI stack from an isolated-network requirement to a tested build that runs with egress blocked, with each step producing evidence the next step depends on.

  1. Confirm the constraint and inventory dependencies

    The security owner and platform lead write down which networks are isolated, what may cross the boundary, and which approved transfer route exists. Then list every dependency the pipelines need: base container images, language packages, actions or plugins, runner operating systems, certificates and licenses. The output is a signed dependency inventory that the transfer process can be checked against. Confirm with your security team how they classify inbound media and whether any cross-domain approval is required.

  2. Choose the forge and CI engine

    Decide whether the enclave needs a full forge (Gitea or Forgejo with built-in Actions, or GitLab) or a CI engine such as Woodpecker CI or Jenkins that works with a forge already inside the enclave. The choice depends on whether repositories must move in and how much workflow syntax must carry over from GitHub Actions. Record the decision with the reasons, the supported versions and the upgrade policy of each candidate. The output is an approved architecture note that names the forge, the CI engine, the runner model and the operators who own each component.

  3. Stage software and packages through the transfer process

    The build team prepares release archives, container images, package mirrors and plugin bundles on the connected side, then records checksums and version numbers for each item. The enclave owner moves them through the approved transfer process and verifies the checksums on arrival. Keep the staged set in an internal artifact store so later rebuilds do not depend on the outside network. The output is a manifest listing every artifact, its version and its verified hash.

  4. Install the forge and runners on isolated hosts

    Platform engineers install the forge, its database and the CI runners on hosts inside the enclave, using the staged packages only. Configure runners with the labels your workflows select, and confirm each runner registers with the forge without contacting external services. Agree the forge's upgrade and support window in writing, since release lines and their support periods differ by project. The output is a running forge with registered runners, verified against the install manifest.

  5. Load actions or plugins from an internal source

    Mirror the actions or plugins your workflows call into an internal source the runners can reach. For GitHub Enterprise Server, this is the actions-sync process, which copies selected public action repositories from GitHub.com in pull and push steps when no single machine reaches both sides. Other platforms use an internal mirror, a vendored plugin directory or an internal plugin registry. Rerun the sync or mirror step after every upgrade, because bundled actions can be replaced during an upgrade. The output is a catalog of internal actions with versions and an upgrade checklist.

  6. Configure secrets, backups and retention in the enclave

    Security engineers load secrets through the forge's secret store or an approved external secrets manager, restricting access by repository and environment. Platform engineers schedule backups of the forge database, repositories, runner configuration and CI home directories, and test a restore to a separate host. Set artifact and log retention to match the enclave's records policy, since hosted services apply their own limits that the self-managed system will not inherit. Ask the vendor or project which values are stored, how they are encrypted and whether a secret can be read back after it is set. The output is a tested restore and a documented retention policy.

  7. Run a test build with egress blocked

    Run representative pipelines with outbound network access blocked at the enclave boundary, covering a build, a test stage, a package fetch from the internal mirror and an artifact upload. Confirm that every call resolves to an internal address and that no step reaches a public registry or action host. Record failures, fix the missing dependencies and rerun until the pipeline passes cleanly. The output is a signed test record, which the security team can keep as evidence for the authorization file.

Evidence that proves the build network is isolated

A reviewer who accepts that a build network has no internet path still needs to see it. The artifacts below show the boundary, the components inside it, what crossed the boundary and how the system recovers, and they tie together in one evidence set for the air-gapped CI platform. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any attestation.

Network diagrams with egress rules

The diagram shows every path between the enclave, the build runners, the controller, the internal forge and any transfer host, with each allowed flow listed by source, destination, port and protocol. Reviewers check that no runner or controller route reaches github.com, public package registries or container hubs. Ask for the firewall or security group export that matches the diagram, not only the drawing, and confirm that the default-deny rule is the last rule in the chain.

Runner and controller configuration

Reviewers want the exact settings that govern where jobs run and what they can reach: runner registration, labels, executor type, the controller's plugin or extension list, and any setting that enables outbound update checks or telemetry. For GitHub Enterprise Server, the relevant evidence includes whether GitHub Connect is disabled and how bundled actions are handled. Store these files in version control so changes leave a trail.

Record of each transfer into the enclave

Every file, action copy, package or image that crosses the boundary needs an entry with the date, the operator, the checksum, the approving owner and the scan result. Keep the transfer log separate from the build logs. Without it, a reviewer cannot tell whether a dependency entered through an approved path or through a shortcut. Ask whether the process is one-way, and who can release the transfer host from quarantine.

Mirrored actions or plugins with versions

The list names each mirrored action, plugin or pipeline library with its exact version, source repository, license and the date it was copied. For GitHub Enterprise Server, actions-sync copies only actions stored in public repositories on GitHub.com, so the list should also show which required actions were excluded and why. Rerun the sync after each upgrade and record the new list, because bundled actions are replaced during upgrades.

Backup and restore test records

Controller state, configuration, secrets and pipeline definitions must be backed up and restored into a separate environment. The evidence is the restore test record: what was restored, how long it took, which checks passed and who signed off. For Jenkins, the controller's home directory holds configuration, plugins and secrets, so confirm that the backup includes it and that secrets are encrypted at rest. Ask for the date of the most recent successful restore.

Access logs and privileged accounts

Reviewers ask who can change pipelines, approve transfers, read secrets and administer runners, and they want logs that prove it. Collect authentication logs, administrator actions, runner registrations and changes to protected branches, and forward them to a store the build team cannot edit. Confirm that break-glass accounts are documented, used rarely and reviewed after each use. Map each privileged role to a named owner.

Questions buyers ask before choosing an air-gapped CI platform

What drives the cost of running CI on an air-gapped network?

Cost comes from people, infrastructure and the mirror process, and most of it recurs. Licensing for the CI engine itself may be zero for open-source options, but the self-managed editions of commercial tools are paid per seat, per agent or per instance, so ask for that structure in writing. The larger costs are staff time to operate the controller and runners, compute capacity for build agents, storage for logs and artifacts, and the repeated work of moving approved actions, plugins or images across the boundary. GitHub's own documentation for Enterprise Server describes a manual sync step that must be rerun after upgrades, so budget for that recurring task. Ask any provider to split a quote into one-time setup and recurring operations, and to name who maintains the mirror and the transfer process.

How long does it take to deploy CI inside an isolated enclave?

The timeline depends on how many components must be built, approved and transferred, not on the CI engine alone. Confirm with any provider which items are in scope: the forge, the CI engine, runner images, base container images, action or plugin content, and the internal certificate and identity integrations. Each one needs an approved transfer path across the air gap, and that path often sets the schedule. DeployOpen plans and implements engagements under a fixed scope agreed in writing before work starts, so ask for the deliverables and milestones in that written scope rather than a generic duration.

What does our team need to provide before an implementation starts?

Your team supplies the environment and the approvals, and the implementation partner works inside them. Expect to provide:

  • Hosting in your own data center or air-gapped network, with compute, storage and network segmentation defined
  • A documented transfer process for software, container images and packages, including who approves each import
  • Identity integration details, TLS certificates from your internal authority, and the backup target
  • Named owners for the forge, the CI engine, runners and the sync or transfer process
  • Access to the security team for review of secrets handling and network rules

Ask the provider to list these inputs in its scope document so gaps are found before work begins.

Can an internal team run an air-gapped CI platform without outside help?

Yes, a capable internal team can run it, provided it owns the upkeep and has tested the transfer process. The open-source engines discussed here are self-operated: you manage the server, runners, plugins or actions, backups and upgrades. Jenkins, for example, keeps its configuration, plugins and secrets in $JENKINS_HOME on the controller, so backup and restore must be practiced. Jenkins LTS 2.580.1 also stopped bundling several plugins, which means administrators must install them through the plugin manager. Decide early whether the team will take on that routine work or buy it as a retainer, and be clear about who is on call when a build fails inside the enclave.

How are CI platform upgrades handled when there is no internet access?

Each upgrade is a planned transfer, not a download, so the process needs a fixed schedule and a rollback plan. GitHub documents that bundled actions are replaced during Enterprise Server upgrades and that the sync must be rerun after each major or minor upgrade. For open-source engines, check the support window before choosing a version: Forgejo states that its stable releases get three months of full support plus a two-week window, while its LTS releases get one year and three months of critical fixes. Jenkins ships a new LTS baseline every 12 weeks, with three LTS releases per baseline. Ask the provider how it stages upgrades in a test enclave before production.

How do secrets and build artifacts stay inside the enclave?

Self-hosted engines keep secrets and artifacts on storage you control, which is the main reason enclaves choose them. Hosted CI services hold deployment secrets for every connected project, and CircleCI's January 4, 2023 incident report told customers to rotate secrets after an attacker exfiltrated environment variables and the keys needed to read them. In your enclave, define where secrets are held, which secrets manager or credential store is used, how runners receive them, and how artifact storage is encrypted and purged. Also confirm that no build step calls an external endpoint for logs, telemetry or caching. Ask the provider to show the data flow diagram for logs, artifacts and caches before sign-off.

What should a quote for air-gapped CI include?

A useful quote lists scope, deliverables, recurring services and the assumptions behind each price. Ask for these items in writing:

  • The components in scope: forge, CI engine, runners, mirror or transfer tooling, backup and monitoring
  • One-time costs for design, installation, hardening, integration and testing
  • Recurring costs for support, upgrades, backup verification and transfer cycles
  • Assumptions about your hardware, approvals and staff availability, and what changes the price
  • Acceptance criteria and the handover documentation you receive

DeployOpen does not publish a price list, and a quote follows from the written scope. It prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, so confirm with your auditor which evidence it needs.

How DeployOpen deploys CI inside air-gapped networks

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including isolated networks. For air-gapped CI, we scope the build, test and deploy paths first, then deliver a working runner, forge or CI engine with its dependency and action-sync process documented for your team.

How we scope

  • We agree scope, deliverables and timelines in writing before any work starts, since engagements are fixed-scope.
  • We map which repositories, actions, images, packages and secrets your builds need, and which must be copied across the boundary.
  • We confirm the target platform with your team (Gitea Actions, Forgejo Actions, Woodpecker CI or Jenkins) against your build languages and deployment targets.

How we build

  • We install and configure the chosen CI platform, runners and storage inside your own cloud accounts, data centers or air-gapped networks.
  • We set up the offline transfer process for actions, plugins and container images, and test that builds complete with no internet access.
  • We integrate the CI system with your secrets handling, artifact storage and existing internal registries, then run security testing on the result.

How we hand over

  • We document the installation, the update and copy-in procedure, backup of configuration and secrets, and runner operations for your staff.
  • We prepare the controls and evidence your compliance assessors may ask for, though independent auditors and certification bodies issue any reports.
  • We walk your engineers through the runbooks and confirm each deliverable against the written scope before closing the engagement.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after handover.
  • Upgrade work covers re-running the offline copy of actions or plugins after each platform release, so builds keep working.
  • Ask any quote to name what the retainer covers, how upgrades are scheduled, and who performs the security testing.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com