Can CircleCI run builds in an air-gapped network without a vendor dependency?
CircleCI Server can be installed in an air-gapped network, but the installation still depends on the vendor. According to CircleCI's air-gapped installation guide for Server 4.10, you copy the images and Helm chart from CircleCI's registry at cciserver.azurecr.io, and you need a username and token that CircleCI provides. Inside the network you must also run a container registry, a Kubernetes cluster, S3-compatible object storage, GitHub Enterprise as the code source, and Nomad virtual machines for builds. Each of these becomes a component your team operates. Before a renewal, confirm with CircleCI how registry access and Server updates are handled for your contract, and who on your side can receive and approve new image bundles.
If the goal is builds that keep working with no vendor registry in the path, the open-source options are Jenkins, Woodpecker CI and GitLab CI/CD. Jenkins is MIT-licensed and can run on agents you control, with plugins installed from your own mirror or artifact store. Woodpecker CI is Apache-2.0 licensed and runs container steps on Docker or Kubernetes, but it connects to a forge, so its fit depends on whether your repositories live on GitHub Enterprise, Gitea, Forgejo, GitLab or Bitbucket. GitLab CI/CD fits best when source hosting and CI can move onto one self-managed platform, and GitLab documents offline, air-gapped installs. The right choice depends on where your source code lives and whether your team wants to run a CI engine or a full forge. Map those answers first, then test each option with an offline build.
What an air-gapped CI network requires
CircleCI Server in an isolated network depends on several components that must all live inside the boundary: a container registry, a Kubernetes cluster, object storage, a code source and build machines. Each one needs its own owner, sizing decision and offline update path, and each one is a place where hosted CI would otherwise have handled the work for you.
Container registry for images and the chart
CircleCI's air-gapped guide requires copying the Server images and Helm chart from CircleCI's registry into a registry you run inside the network. Copying needs a username and token that CircleCI provides, so confirm access and the transfer process with CircleCI before the isolated environment is built. Plan the same copy step for every upgrade, because the network cannot pull new versions on its own.
Kubernetes cluster for Server
CircleCI Server 4.10 installs into a Kubernetes cluster that you operate, so the cluster is part of your build platform from day one. Your team owns node sizing, storage classes, patching and access control. Confirm with CircleCI which Kubernetes versions the 4.10 installation supports before you choose a distribution for the isolated network.
S3-compatible object storage
Server needs an S3-compatible object storage system inside the network to hold build data that hosted CI would otherwise keep on its own infrastructure. Check that the store supports the S3 API calls CircleCI requires, and decide who backs it up and how long data is retained. Object storage is also where build artifacts end up, so its retention settings matter for compliance.
GitHub Enterprise as the code source
For CircleCI Server in an air-gapped environment, GitHub Enterprise is the required code source, so repositories, pull requests and webhooks must all be served from inside the network. Confirm which GitHub Enterprise version CircleCI supports and how users, teams and SSO map to CircleCI projects before you cut over. Your repositories then depend on that server's own backup and patch cycle.
Nomad virtual machines for builds
Builds run on Nomad virtual machines that sit inside the air-gapped environment, so you must provision, image and patch the machines that execute your jobs. Each build needs its toolchains, language packages and base images available offline. Ask CircleCI which Nomad versions and VM images the 4.10 guide expects, and plan capacity for peak build queues.
Artifacts and secrets stay in-network
Hosted CI keeps build artifacts for limited periods, and CircleCI sets 30 days as both the default and the maximum, so artifacts that matter must be copied out before they expire. Environment variable values in hosted platforms cannot be read back once set, so the secrets for an isolated build must be recreated in your own vault and rotated as part of the move.
Where CircleCI Server meets the air-gapped requirement and where it adds dependencies
CircleCI Server 4.10 is built to install into the customer's own Kubernetes cluster, and CircleCI publishes an air-gapped installation guide for that purpose. The catch is in the installation path. The images and Helm chart must be copied from CircleCI's registry at cciserver.azurecr.io using a username and token that CircleCI issues. Before any air-gapped install starts, the operations team needs that vendor-provided credential, and it needs a documented process for holding it, rotating it and recording who used it. Ask CircleCI in writing how the credential is scoped, how long it lasts and what happens to access if the contract changes.
The same copy step repeats for every upgrade cycle. Each new release means a fresh transfer of images and chart across the boundary, so the upgrade calendar depends on CircleCI's release timing and on your change-control window. Plan for that transfer as recurring work, not a one-time install task. Confirm with CircleCI whether an offline upgrade path has any additional conditions, which versions remain supported and what licensing terms apply to a self-managed Server deployment inside an isolated network. Get the answers in the contract or order form, not from a sales conversation.
The air-gapped footprint is larger than the Kubernetes cluster alone. The guide requires a container registry, an S3-compatible object storage system, GitHub Enterprise as the code source, and Nomad virtual machines inside the isolated environment. Each of those is a system you must operate, patch, back up and secure without internet access. GitHub Enterprise also needs its own licensing and upgrade plan. Before committing, map every component to an owner and confirm the Nomad VM image sources and the versions of GitHub Enterprise that CircleCI supports. This list is the starting point for the dependency inventory that an assessor or internal audit will ask to see.
How Jenkins, Woodpecker CI and GitLab compare for offline builds
Jenkins is an automation server distributed under the MIT License, so you can run it inside an isolated network without a license negotiation. Offline operation depends on mirroring what Jenkins fetches at runtime: the core WAR or container image, the plugin set, the update site metadata and the tool installers that jobs download. Builds usually run on agents that pull container images or base images from an internal registry you populate in advance.
- Licensing: The MIT License covers the core project, and the plugins you install carry their own licenses that you should review.
- Plugin mirroring: Plugins, their dependencies and the update center metadata must be mirrored internally, and the plugin list should be pinned to tested versions.
- LTS upkeep: Jenkins ships LTS baselines on a fixed cycle, and LTS 2.580.1 stopped bundling several plugins, so administrators must install them explicitly.
- Configuration: Jobs are defined in Jenkinsfiles, and the Configuration as Code plugin reads YAML from
CASC_JENKINS_CONFIGbut does not install plugins. - Source hosts: Jenkins works with most forges through plugins, so repository access depends on the plugin you choose.
Before committing, confirm with your team which plugins your pipelines require and who will own the offline mirror and upgrade testing.
Woodpecker CI is licensed under Apache-2.0, with its documentation under CC BY-SA 4.0, and it runs each workflow step inside a container image you specify. For an air-gapped network, the main inputs are the Woodpecker server and agent images, the step images your pipelines reference, and any plugin images, all hosted in an internal registry. Woodpecker connects to GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter, so the forge can stay in the isolated network too.
- Licensing: Apache-2.0 for the engine, with a permissive license that fits internal redistribution.
- Step model: Every step runs in a container, so offline use depends on mirroring each base image your builds reference.
- Database: Woodpecker uses SQLite by default, and PostgreSQL or MariaDB is recommended for larger instances.
- Plugins: Plugins are container images, and Drone plugins generally work but may need adjustments.
- Forges: Connecting multiple forges to one server is still experimental according to the forge documentation.
Confirm the Woodpecker version you will mirror, the forge you need, and whether your Kubernetes backend will meet the shared volume requirements for multi-step pipelines.
GitLab documents running self-managed instances in offline, air-gapped environments, which makes it the option that also covers source hosting in the same isolated network. The GitLab offline environments guidance covers installation packages and the separate steps for running GitLab security scanners and GitLab Duo Self-Hosted offline. Runners execute jobs from container images that you mirror into an internal registry.
- Licensing: Open core: content under the ee/ directory uses the GitLab Enterprise Edition license, and content outside it is MIT.
- Footprint: Reference architectures scale from 1,000 users to 50,000 users, and high availability for 3,000 or more users uses Gitaly Cluster, PostgreSQL with Patroni, Redis Sentinel and Consul.
- Kubernetes limits: Stateful components such as PostgreSQL and Redis are not supported inside Kubernetes in the reference architectures.
- Upgrades: Upgrades must pass through required upgrade stops, such as 18.2, 18.5, 18.8 and 18.11.
- Paid tiers: Premium and Ultimate add features such as advanced CI/CD and compliance tooling, so confirm which features your build policy needs.
Before choosing GitLab, confirm the tier and feature set you need for offline operation and whether a single-node or high availability layout fits your user count.
Air-gapped requirements side by side
This table compares what each platform needs inside an isolated network: licensing, components, offline documentation, supported forges and what must be copied in for updates. Cells marked verify are not confirmed by the sources used here, so ask the vendor or project before you commit. The main takeaway is that CircleCI Server depends on a vendor-issued registry login and a fixed set of components, while the open-source options differ mainly in the components you operate and the update material you mirror.
| Requirement | CircleCI Server | Jenkins | Woodpecker CI and GitLab CI/CD |
|---|---|---|---|
| License | Commercial license. Verify terms and redistribution rights with CircleCI. | MIT License. | Woodpecker: Apache-2.0. GitLab: MIT outside the ee/ directory, Enterprise Edition license inside it. |
| Components required inside the network | Container registry, Kubernetes cluster, S3-compatible object storage, GitHub Enterprise and Nomad virtual machines. | Controller and build agents. Kubernetes is optional, so confirm the agent model you plan to use. | Woodpecker: server, agents and a database (SQLite by default). GitLab: instance plus GitLab Runner, with PostgreSQL and Redis for high availability. |
| Offline installation documentation | Air-gapped installation guide exists for Server 4.10. Verify it covers your target version. | Verify offline installation and plugin steps for your version with the Jenkins project. | Woodpecker: verify offline steps with the project. GitLab: documented offline and air-gapped environment guidance exists. |
| Source forges supported | GitHub Enterprise as the code source, per the air-gapped guide. | Git and other source control through plugins. Verify the plugin for your forge. | Woodpecker: GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter. GitLab: its own forge, hosting source and CI together. |
| What must be copied in for updates | Images and Helm chart copied from the vendor registry with a username and token CircleCI provides. | Verify your mirror process for core packages, LTS updates and plugins. | Woodpecker: server and agent images, plugin images. GitLab: packages and container images. Confirm the update process with GitLab. |
| Release cadence to plan for | Verify with the vendor which Server releases and image sets must be mirrored. | New LTS baseline every 12 weeks, with point releases in four-week cycles. | Woodpecker: 3.19.0 released October 7, 2026. GitLab: monthly minor releases and required upgrade stops at x.2, x.5, x.8 and x.11. |
How to deploy a self-hosted CI engine inside an isolated network
This sequence moves CircleCI pipelines, secrets and build history into a self-hosted CI engine that runs entirely inside an isolated network, with every image, plugin and update staged through an internal registry and a controlled offline bundle process.
Inventory pipelines, secrets and build history
Your team lists every CircleCI project, its config file, orbs, contexts, environment variables and artifact needs, and records which repositories and deploy targets each project touches. Secret values cannot be read back from CircleCI's app once set, so the inventory records names, owners and the systems each credential unlocks. Artifacts are downloaded through the API before the 30-day retention window closes. The step is done when every project has an owner, a dependency list and an export status.
Choose the engine and the source forge
Decide which self-hosted engine fits your pipelines and where the repositories will live inside the isolated network. Woodpecker CI, Jenkins and GitLab CI/CD each have different runtime, plugin and operations models, and the forge choice affects webhooks and authentication. Confirm with each vendor or project that the chosen version runs without internet access and that its required components can be mirrored internally. The step closes with a written decision record naming the engine, the forge and the version baseline.
Build the internal registry and mirror images and plugins
Your platform team stands up an internal container registry and copies every image, Helm chart, plugin and language package the pipelines need from a connected staging network, then verifies the checksums before import. CircleCI's own air-gapped guide requires copying its images and Helm chart from its registry with credentials CircleCI provides, so confirm the licensing terms for any CircleCI components you keep. The step is complete when a test pipeline pulls every referenced image from the internal registry with no outbound traffic.
Deploy the controller or server with its database
Your platform or DevOps team installs the CI controller or server inside the isolated cluster or virtual machines, configures a production-grade database such as PostgreSQL, and connects it to the internal forge and identity provider. Store the controller home directory or configuration, plugin set and secrets on backed-up storage, because Jenkins keeps its configuration, plugins and secrets in $JENKINS_HOME. Plan for a documented backup and restore test before any pipeline depends on the system. The step is done when the UI or API responds and a restore of the database and configuration has been rehearsed.
Attach build agents in isolated segments
Your team connects build agents in the segment that needs them, so builds run close to the code they test and the controller only handles requests and coordination. Woodpecker agents can run workflows on Docker, Kubernetes or the local machine, and Jenkins recommends dedicated build agents for the same separation. Confirm that agents reach only the registry, forge and deploy targets they require. The step is complete when a test job runs on each agent pool and the network policy blocks any outbound destination not on the approved list.
Re-create secrets in the new secret store
Your security team re-creates each credential in the new platform's secret store, scoped to the projects that need it, and rotates every value so no secret copied from CircleCI remains in use. Hosted CI exports return names but not values for many platforms, so the source of each credential usually lives in your vault or the target system. Limit access by project and environment, and record who approved each secret. The step is done when every inventoried secret has a new owner, a scope and a rotation record.
Run a parallel pilot
Your engineering team runs selected pipelines on the new engine alongside CircleCI, compares artifacts, test results and deployment outputs, and records every difference in config behavior, plugin behavior or timing. Keep CircleCI active until the pilot pipelines match on the agreed checks, and treat any unexpected external call as a blocking finding. The step closes when the pilot owner signs off on each migrated project against its checklist.
Cut over and keep an offline update procedure
Your team moves each project's triggers to the new engine, disables the CircleCI project, and records the final artifact export. It then sets a recurring process for offline bundles: new images, plugins, LTS or stable releases and security fixes are reviewed on a connected staging network, copied across, tested and approved before they reach production. For Jenkins, check the LTS line and Java support policy before each bundle; for GitLab, confirm the upgrade stops it requires. The step is done when the update calendar, bundle owner and rollback procedure are documented and tested.
Questions buyers ask before moving CI into an air-gapped network
What does moving CI into an air-gapped network cost, and what drives it?
The cost is mostly people, hardware and recurring maintenance, not a license fee, because the open-source engines in this comparison carry no license charge. Cost components include build servers or Kubernetes capacity, object and artifact storage, the internal registry and mirror that carry packages and images across the gap, staff time for installation and pipeline conversion, and ongoing upgrades and patching. CircleCI's own air-gapped path requires a container registry, a Kubernetes cluster, S3-compatible object storage, GitHub Enterprise and Nomad virtual machines inside the isolated environment, so those components apply to that option as well. Ask any provider for a written scope and quote that lists each component, who pays for it, and which items are one-time versus recurring.
How long does an air-gapped CI migration take?
Timing depends on the size of the pipeline estate, how many repositories and build types must move, how much network transfer and approval the isolated environment needs, and how many pipelines must run in parallel with the old system during cutover. No duration is set in advance. The main variables are the number of CircleCI config files to convert, the number of orbs or contexts to replace, the work to rebuild secrets that CircleCI will not display, and the time required to copy images, packages and the chart across the air gap. Ask for a timeline in the written scope, with milestones for the pilot pipeline, the parallel run and the final cutover.
What does our team need to provide for an air-gapped CI project?
Your team must supply access to the isolated environment, the approved transfer process for images and packages, and the people who own the source forge, identity, and the build targets. You will also need an internal owner for secrets, since CircleCI does not expose environment variable values after they are set and those values must be re-entered from their original sources. Expect the engineering team to review converted pipelines, approve plugin and base image choices, and decide retention rules for artifacts and logs. Confirm these responsibilities, along with any change windows, in the scope before work starts.
Can our own engineers run an air-gapped CI platform without outside help?
Yes, a capable platform team can run an open-source CI engine internally, but it depends on the engine, the skills in-house and the operating commitment. Woodpecker CI runs its server and agents on Docker, Kubernetes or a local machine, and it uses SQLite by default with PostgreSQL or MariaDB recommended for larger instances. Jenkins requires backing up $JENKINS_HOME, managing plugins and following its LTS cycle, and GitLab is a larger system with its own reference architectures and an offline installation guide. Outside help is commonly used for installation, plugin and pipeline conversion, hardening, backup testing and upgrade planning. Ask any partner to separate those tasks in the written scope so you can see what your team keeps.
How do updates and security fixes reach an offline CI network?
Updates reach an isolated network only through a transfer process you define and approve, so every release must be downloaded outside, verified and carried in. Jenkins publishes LTS releases with only backported fixes in four-week cycles, so you can plan a regular intake. Woodpecker publishes tagged releases on GitHub, and GitLab ships monthly minor releases with patch releases twice a month, with required upgrade stops at versions such as 19.2, 19.5, 19.8 and 19.11. Container images, Helm charts and plugins also need mirroring, and the GitLab maintenance policy notes that security fixes are backported to more releases than bug fixes. Agree on an intake schedule and a rollback plan in writing.
Can secrets and build history be exported from CircleCI?
Build history and secret values are the two items that do not move cleanly. CircleCI sets 30 days as both the default and maximum artifact retention, so artifacts must be downloaded through its API before that window closes. Environment variable values are not readable in the CircleCI app once set, so they must be recreated from their original systems, and the January 4, 2023 incident report told all customers to rotate secrets after an attacker exfiltrated environment variables and the keys needed to read them. Config files already live in your repositories and move with them. Plan a secret rotation as part of the migration rather than a copy of old values.
Is any open-source CI engine certified for a specific security or compliance standard?
No open-source CI engine is certified against a standard by its project alone, and DeployOpen does not issue certifications or audit reports. Certification concerns the operated system and its controls, which an independent auditor or certification body assesses for your environment. Jenkins is MIT licensed and hosted by the Continuous Delivery Foundation, Woodpecker is Apache-2.0 licensed, and GitLab offers offline guidance for its scanners, but none of these facts establish compliance. DeployOpen can prepare systems, controls and evidence for an assessment. Name the standards you must meet in the written scope so the evidence plan matches what your auditor expects.
Evidence auditors ask for from an offline CI platform
An air-gapped CI platform is only as defensible as the records behind it. The cards below cover the records an assessor usually asks for, from the component inventory to upgrade history. DeployOpen prepares these records, but independent auditors and certification bodies issue any assessment or attestation.
Current component inventory
Keep a dated list of every CI component inside the isolated network: the controller or server, agents, container registry, Kubernetes cluster, object storage, Git forge and each plugin or image with its exact version. For a CircleCI Server replacement, the air-gapped installation guide lists the required pieces, such as a container registry, Kubernetes, S3-compatible storage, GitHub Enterprise and Nomad machines. Check the inventory against what is actually running, not against the plan.
Offline image and plugin transfer records
Record how every container image, Helm chart, plugin and package entered the network: the source, the version, the checksum, who approved the transfer and who verified it on the inside. Confirm with each vendor which artifacts it publishes for offline use and how it signs them. Without this trail, an assessor cannot tell whether a build ran on software that was reviewed.
Access control and secret storage records
Document who can change pipeline configuration, who can read stored secrets, and which identity provider or role mapping governs each permission. Hosted CI services have exposed customer secrets before, and a CircleCI incident report told customers to rotate their secrets, so the rotation log matters as much as the access list. Confirm where secret values are stored and whether the platform can show the names of secrets without showing values.
Controller configuration backup and restore tests
For Jenkins, the configuration, plugins and secrets live in the JENKINS_HOME directory on the controller, so that directory is the core of any backup. Record the backup schedule, the storage location inside the network, the encryption of backup media and the date of each restore test. A backup that has never been restored is not evidence of recoverability, so keep the test results with the backup logs.
Upgrade and patch change log
Keep a log of every version change to the platform, with the release notes reviewed, the test environment result and the approval record. Jenkins LTS releases can drop bundled plugins, which means an upgrade may need a plugin installed by hand. GitLab requires passage through upgrade stops, and security fixes reach only some earlier releases. Record the patch cadence you committed to and the exceptions you accepted.
Which option fits which network and team
Start with the source forge, because it decides how much of the platform you must rebuild. If your repositories already live on GitHub Enterprise Server or another self-managed forge, Woodpecker CI is the lighter fit: it connects to GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter through forge webhooks, so repositories stay where they are and only the build engine moves inside the enclave. Confirm with your forge administrator that the forge is reachable from the isolated network and that webhook and gRPC traffic between the Woodpecker server and agents is allowed. Also confirm that multi-forge connections, which the Woodpecker forge documentation describes as experimental, are not required by your setup.
If your engineers already write Jenkinsfiles, know the Jenkins controller and agent model, or run Kubernetes pod agents, Jenkins is the familiar choice, but it moves a recurring maintenance load onto your team. Plan for plugin ownership: every plugin, its dependencies and its security advisories become your responsibility, and LTS changes can require you to install plugins that were previously bundled. Also plan for the controller's $JENKINS_HOME as the single place where configuration, plugins and secrets live, so backup and restore must be designed before go-live. GitLab CI/CD is the consolidated option: it brings source hosting, CI, a runner fleet and its own upgrade stops into one platform. GitLab documents offline, air-gapped installs, but its required upgrade stops mean a scheduled upgrade path that your team must follow, and the tier you need for advanced CI/CD or security features should be confirmed on the GitLab pricing page before you commit.
Decide how much platform you want to maintain versus how many systems you want to run. A single-platform choice such as GitLab reduces integration points but moves source hosting, which is a larger migration than replacing only the build engine. A Woodpecker or Jenkins choice keeps the forge stable but leaves you operating two systems that must both be patched inside the isolated network. Whichever you choose, ask each vendor or project for its supported offline installation method and its update process for air-gapped systems, and write those answers into the scope before procurement or implementation starts.
How DeployOpen deploys CI inside your isolated network
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For a CI replacement, that means scoping the build environment, deploying the chosen engine and its runners on your hardware, and handing over the runbooks your team needs to operate it without an internet connection.
How we scope
- Inventory the repositories, pipelines, runners and build dependencies that must move into the isolated network
- Confirm which forge hosts the code, such as an on-premises GitLab, Gitea, Forgejo or GitHub Enterprise Server
- Agree in writing which CI engine, runner model and offline package sources the engagement covers
How we build
- Deploy the CI controller, agents and runners inside your cloud account, data center or air-gapped network
- Mirror container images, plugins, Helm charts and language packages through an approved internal process
- Test pipelines, secrets handling and artifact storage against the agreed scope before cutover
How we hand over
- Document the architecture, offline update procedure, backup and restore steps and access model
- Deliver configuration as code and runbooks so your engineers can reproduce the environment
- Provide evidence of controls prepared for your compliance assessors, who make the formal determination
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Plan offline upgrade bundles and patch cycles that match the platform's own release policy
- Keep your team's knowledge current through documentation updates and operator training sessions
