CircleCI Server vs self-hosted open-source CI

Before comparing prices, a platform team should understand what CircleCI Server 4.10 expects to run. The edition installs into the customer's own Kubernetes cluster, according to the CircleCI Server 4.10 overview, and the topic's supporting services are MongoDB, PostgreSQL, RabbitMQ, Redis and Vault, with Nomad machines for build execution and S3-compatible storage for artifacts and other data. Each of these is a stateful component your team would patch, back up, monitor, scale and recover, alongside the cluster itself. Confirm with CircleCI which versions of each service it supports, how it expects them to be deployed (managed or self-run), and which of them must be highly available for your expected build volume.

CircleCI does not publish a price for CircleCI Server, so the cost comparison starts with a written quote. Ask the vendor to itemize what is licensed, what is included in support, whether Nomad machine capacity and storage are billed separately, and what changes at renewal. On the other side, a self-hosted Woodpecker CI, Jenkins or GitLab CI/CD deployment has no license fee for the open-source engine, but it still carries recurring costs: infrastructure, storage, upgrades, security patching and the engineering time to operate them. Ask your internal team to estimate those hours and staffing in the same spreadsheet, so both options are compared on the same operating assumptions.

The operating burden is the decision point. Count who will carry the on-call rotation for the stateful services, who tests upgrades against each component version, and where the Vault secrets, database backups and artifact storage will be recovered from if a region or cluster fails. A useful check is to write down the recovery steps for one failed component, such as the message broker or the primary database, and ask both the vendor and your own team to walk through them. If your team cannot staff that work at the required level, the self-managed CircleCI edition and a self-hosted open-source engine both shift risk onto you, and the quote should reflect that difference.

Plan for secrets to be re-created, not copied. CircleCI states that environment variable values are not readable in its app after they are set, so the values a pipeline depends on, such as deploy keys, registry tokens and cloud credentials, have to be retrieved from their issuing systems or from your own password manager and entered again in the new CI engine. The January 4, 2023 incident report is the reason to treat this as a rotation exercise rather than a copy exercise: CircleCI told all customers to rotate secrets after an attacker exfiltrated environment variables, tokens and keys along with the encryption keys needed to read them. Inventory every context and project variable, record which system issues each credential, and rotate them during the cutover window so that the old and new platforms never hold valid copies of the same production secret at once. Confirm with your security team which credentials were already rotated after the 2023 notice, because those still need re-creation but may not need a second rotation.

Build history is the second item that does not move automatically. CircleCI sets 30 days as both the default and the maximum retention for build artifacts, so anything your team needs from older runs, such as test reports, coverage files, signed release bundles or compliance evidence, has to be downloaded through the API before that window closes. Make this an explicit step in the migration plan with an owner and a deadline, and decide which artifacts become the system of record in the new platform, for example a container registry or an object store you run. Check the CircleCI documentation on storing build artifacts for the current retention behavior on your plan, because the window is the constraint that drives the schedule. Export the pipeline run logs and test results you must keep for audits as well, and store them in a location with the same access controls as the source code.

Run the old and new pipelines in parallel for the period needed to confirm that every deployment secret resolves in the new engine, and do not decommission CircleCI contexts until the artifact export is verified. Record each rotation and each exported artifact in a change log, since auditors and incident responders will ask when a credential changed and where its build evidence lives. If your organization treats CI secrets as covered by a password or secrets management standard, bring the new CI platform's secret store into that process from the start rather than after cutover.

Keep CircleCI Server when the network boundary is the hard constraint and your team already runs the platform well. CircleCI Server 4.10 installs into a Kubernetes cluster you control, so builds, artifacts and environment variables can stay inside your network without a full pipeline rewrite. That matters most when orbs, contexts and workflows are embedded across many repositories, when a move would delay release work, or when internal policy expects a named vendor under contract. Before deciding, ask CircleCI in writing which Server releases are supported, what the support scope covers for the Kubernetes, Nomad, MongoDB, PostgreSQL, RabbitMQ, Redis and Vault components, and whether your license counts builds, containers, users or machines. The price is not published, so the answer to that licensing question drives the whole comparison.

Move when the operating load or the unpublished price outweighs the convenience of a vendor-supported install. Server asks your platform team to run Kubernetes and Nomad, operate MongoDB, PostgreSQL, RabbitMQ, Redis and Vault, and carry every upgrade through that stack. Open-source engines shrink it. Woodpecker CI is Apache-2.0, uses SQLite by default with PostgreSQL recommended for larger instances, and runs steps on Docker or Kubernetes, so the footprint can be a server, agents and one database. Jenkins is MIT-licensed and keeps configuration, plugins and secrets in $JENKINS_HOME on the controller, which makes the backup scope clear but puts plugin upkeep on your team. If your forge is also moving, GitLab's pricing page lists Premium at 29 US dollars per user per month billed annually for self-managed installations, and GitLab documents offline operation. The cost moves to your staff: patching, backup restore tests and on-call coverage.

Whichever way the team leans, get the terms in writing before a renewal or migration plan is approved. Ask CircleCI for the Server license terms, the term length, how renewal pricing is set, whether self-hosted build capacity is metered, and exactly which components and versions the support agreement covers. Vendors have changed how they charge for self-managed capacity: Atlassian introduced per-slot pricing for premium Bitbucket Pipelines runners, and GitHub's announced per-minute charge for self-hosted runners was postponed after it was announced. Ask whether a similar change could reach your CircleCI Server agreement. Then build a short exit plan covering config files, a secrets inventory, artifact retention and a rotation schedule, so the option to move stays open whatever the answers show.