Where TeamCity costs more than self-hosted Jenkins, and where it does not
If you are facing a TeamCity renewal, an Enterprise Plus true-up or the limits of TeamCity Professional, the short answer is this: Jenkins removes the per-agent license line but adds recurring operating labor. Jenkins itself carries no license fee, so the money you save is the agent licensing you no longer pay, and the money you spend is the engineering time to run controllers, agents, plugins and upgrades. No Jenkins or TeamCity price figure is supplied for this comparison, so ask JetBrains for a written quote for your agent count and edition, and build your own estimate of staff time from your environment.
The comparison turns on three variables: how many agents you run, how many builds those agents execute, and what skills your team already has. Jenkins is distributed under the MIT License, as stated in the LICENSE.txt file in the jenkinsci/jenkins repository, so there is no license charge for the server or its agents. TeamCity Professional is free within its build configuration, pipeline and agent limits, so a small estate may never reach a paid line. Once agent count grows, the recurring cost of TeamCity Enterprise licenses is the number to model against your staff hours, and the trade is sharper when agents are numerous but lightly used.
Before you decide, list every cost that recurs: TeamCity subscriptions and agent true-ups on one side, and on the Jenkins side the controller hosting, agent infrastructure, plugin updates, LTS upgrades and the on-call time for failed builds. Also count the one-time work of migrating build configurations, secrets and history, which a fixed-scope implementation partner can price from a written scope. Ask each vendor what triggers a true-up, how Professional limits are enforced on new builds and who pays for plugin security maintenance. Your internal Jenkins skills will decide whether those hours are small or large.
Cost components on each side and what recurs
This table compares who gets paid for each cost component when running TeamCity against self-hosting Jenkins, and whether each cost is one-time or recurring. Agent-based license costs recur at each renewal or true-up, while migration effort is a one-time project cost that the reader should scope in writing before comparing totals.
| Cost component | Commercial side (TeamCity) | Self-hosted side (Jenkins) | One-time or recurring |
|---|---|---|---|
| Software license or subscription | TeamCity Enterprise server and per-agent licenses, with true-up billing for agents added beyond the licensed count; Professional is free within its build configuration and agent limits | Jenkins is MIT-licensed, so no license fee applies to the software itself; paid costs come from support contracts or a commercial distribution if you choose one | Recurring for TeamCity Enterprise renewals and true-ups; none for Jenkins software |
| Controller and agent infrastructure | Servers and build agents sized for your team, plus the agent count your license covers | Controller plus dedicated build agents as recommended by the Jenkins scaling guide, so the controller only handles HTTP requests and manages the build environment | Recurring for compute, storage and cloud or data center capacity on both sides |
| Implementation and pipeline migration | Mostly limited to the effort of keeping existing TeamCity configurations running | Mapping build configurations and build chains to Jenkinsfile stages, templates to shared libraries, and agent requirements to labels | One-time; ask the implementation partner for a fixed-scope estimate in writing |
| Plugin maintenance | Bundled features cover much of the build chain, IDE integration and reporting out of the box | Plugins from the community, more than 2,300 listed on the Jenkins homepage, each need review, version pinning and updates; some bundled plugins were removed from the LTS 2.580.1 bundle and must be installed separately | Recurring; grows with the number of plugins you rely on |
| Upgrades and LTS adoption | Upgrades handled by the vendor under your license terms; confirm what is included in your renewal | Adopting a new LTS baseline every 12 weeks and the Java versions in the Jenkins support policy, with 2.541.3 as the final LTS for Java 17 | Recurring; plan regular upgrade windows and testing |
| Support | Vendor support included with an Enterprise subscription; confirm response terms in the quote | Community support, or a commercial support contract from a vendor or an implementation partner under a written scope or retainer | Recurring if you buy a retainer; community support is free but carries no contractual response commitment |
| Internal skills and operations | Administration skills focused on TeamCity configuration and licensing | Staff who can operate the controller, agents, backups of $JENKINS_HOME and plugin lifecycle, which may need platform or DevOps time | Recurring as staff time; ask who on your team will own it after go-live |
What moves the Jenkins versus TeamCity comparison
The cost gap between TeamCity and self-hosted Jenkins is set less by the list price of the tools than by how many agents, configurations, plugins and operators each side needs. Each driver below changes the bill in a different place, so size them together before comparing totals.
Licensed agents and concurrent builds
TeamCity bills by agent on Enterprise, so the number of agents you run, and how many builds run at once, sets the licence count. Jenkins has no per-agent licence, but every agent is a machine, VM or container you pay to run and patch. Count peak concurrent builds per platform, not total agents, and ask your TeamCity reseller how Enterprise Plus true-up billing treats burst capacity.
Build configuration count and pipeline complexity
TeamCity Professional caps build configurations and pipelines, so a growing estate can push you onto Enterprise even on a small agent pool. In Jenkins the cost moves to pipeline code: each project needs a Jenkinsfile, and shared logic lives in libraries someone must write and review. Inventory configurations and build chains from your versioned settings before estimating either side.
Plugin dependency
Jenkins reaches its breadth through more than 2,300 community plugins, and each one needs versions tracked, security advisories watched and upgrades tested. Some plugins are no longer bundled with the controller, so an upgrade can require installing them explicitly. Count the plugins your current TeamCity features replace, and budget for their maintenance as a recurring task.
Primary and backup controller availability
A single Jenkins controller holds all configuration, plugins and secrets in $JENKINS_HOME, so an outage stops every pipeline. The scaling guide describes a primary and backup controller behind a proxy such as HAProxy or F5, and it also suggests adding controllers per team or project. Each extra controller duplicates hosting, backup and upgrade work, and the availability target you set determines how many you need.
Windows and macOS agent needs
Build chains that target Windows or macOS need agents on those platforms, and the operating system licences, patching and hardware for them often cost more than the Linux agents. TeamCity's Windows agent support is one reason some teams keep it, so confirm which platforms your builds need before choosing a Linux-first engine. Jenkins agents can run on those platforms too, which makes the agent fleet a cost you carry in either case.
In-house Jenkins skills
Moving to Jenkins replaces a vendor-supported product with work your own team, or a partner, must perform: Groovy-based pipelines, controller tuning, plugin governance and incident response. Ask who on staff can own the controller after go-live, and whether the skills to run it exist in-house or must be bought in through a retainer or training. Those people costs usually outweigh the software line.
How to build the comparison with your own numbers
This sequence turns TeamCity's current licensing and your Jenkins hosting estimates into one side-by-side model, so the comparison rests on your inventory and quotes rather than on published list figures. Each step ends with a figure or check you can carry into the next one.
Export the TeamCity inventory from versioned settings
Enable versioned settings on the TeamCity server so that the project configuration is committed to a repository as a .teamcity directory in Kotlin DSL or XML. Your platform or build engineering lead should run the export, then review the committed files to confirm every project, build configuration, template and agent requirement appears. The step is done when the repository history is the single source for your inventory, and the team has agreed which projects are in scope for the comparison.
Count agents and build configurations
From the exported files and the TeamCity administration pages, count the build configurations, pipelines, build chains and the agents you run, separating agents by operating system and by whether they run on-premises or in a cloud account. Note which agents run continuously and which are started on demand. The output is a table with one row per agent pool and one row per project group, which becomes the sizing basis for every later line.
Price each TeamCity renewal line from your quote
Ask your JetBrains reseller or account contact for a written renewal quote that lists each license line separately, including Enterprise server licenses, agent licenses, and any true-up billing for agents beyond what you have licensed. Confirm with the vendor how Enterprise Plus true-up is calculated and when it is invoiced, and whether a Professional tier applies to any part of your estate within its build configuration and agent limits. The output is one annual recurring cost per line, with the quote date and currency recorded.
Estimate Jenkins controller and agent hosting
Using your own cloud or data center rates, price a controller and the build agents that match the sizing from step two. Follow the Jenkins scaling guidance that dedicated agents keep the controller free of build work, and add a backup controller if your continuity requirements call for one. Your infrastructure team should supply the rates, and the output is a monthly or annual hosting figure for each Jenkins component, with the assumptions written beside it.
Add plugin maintenance and migration as separate items
List the Jenkins plugins your inventory needs, then record the effort to test, pin and upgrade them against each LTS release line, which recurs. Separately, estimate the one-time migration work for mapping build configurations to Jenkinsfile stages, templates to shared libraries and agent requirements to labels, and for running both systems in parallel during cutover. Ask your implementation partner or internal team for a written scope and effort estimate for each item. Keep one-time and recurring costs in separate columns so they are not blended.
Add support and operating staff time
Record the support contract you would need for Jenkins, whether a commercial distribution or a retainer with a services provider, and the internal staff hours for patching the controller, managing credentials and monitoring agents. Ask each provider for the scope, response expectations and what is included in writing. Staff time should be expressed as hours per month by role, using your own loaded rates. The output is a recurring operations line that can be compared directly with the TeamCity renewal.
Compare totals over a period you choose
Choose the comparison period with finance, then total the one-time migration costs and the recurring lines for each option across that period, showing the TeamCity side and the Jenkins side in the same currency. Run a sensitivity check by changing the agent count and the true-up assumption to see which inputs move the result most. The step is done when the model reproduces your current renewal, every figure traces to a quote or a rate card, and the open questions are assigned to named owners.
Which Jenkins costs recur after the migration
Replacing TeamCity licenses with Jenkins removes a line item, but it does not remove cost. The recurring work sits in the controller, the agents and the upgrade cycle, and it is paid for in engineer time or in a support contract. Jenkins is MIT-licensed, so the software itself carries no license fee. The controller and build agents still need compute, storage and monitoring, and those costs repeat every month whether or not a build runs. Ask your own infrastructure team to size the controller and agent pools against your current TeamCity agent count and peak concurrency, and to price them on your own cloud or data center rates.
Upgrades are the largest predictable recurring task. Jenkins picks a new LTS baseline every 12 weeks and ships three LTS releases per baseline in four-week cycles, so a team that wants to stay on supported releases plans for a steady upgrade rhythm. The LTS 2.580.1 release, dated September 30, 2026, stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins, so administrators must install them through the plugin manager or pipelines relying on them will break. Java support is a second clock: the Jenkins Java support policy lists Java 21 with a planned end of support in September 2027 and Java 25 with a planned end of support in September 2029. Confirm with your own change board how much regression testing each cycle requires.
Backups are the recurring control that is easiest to underfund. The Jenkins scaling guide states that all configuration, plugins and secrets live in $JENKINS_HOME on the controller, so a backup of that directory is the recovery point for the whole instance. Define backup frequency, encryption of stored credentials, restore tests and retention in writing, and confirm them with your security and compliance owners. Plugin maintenance adds to this: each installed plugin has its own release stream, and vulnerability advisories for plugins need someone assigned to triage them. Ask any implementation partner to quote these as recurring retainer items, separate from the one-time migration work.
Questions buyers ask before they compare TeamCity and Jenkins costs
Is Jenkins free to run?
Jenkins is free to download and run because it is distributed under the MIT License, which allows use, modification and redistribution without a license fee. The cost of running it is the infrastructure for the controller and build agents, the engineering time to operate and upgrade it, the plugins your teams depend on and any support contract you choose to buy. The license is free, but the operating work is not, so compare the recurring staff and infrastructure costs against your current TeamCity Enterprise and agent licensing rather than against zero.
How long does a TeamCity to Jenkins migration take, and what drives it?
No duration is fixed by the product, so the timeline depends on the scope you agree in writing. The main drivers are the number of build configurations and build chains, how many use templates or shared logic, how many agents and platforms must be matched with Jenkins labels, how many secrets must be re-entered by hand, and how much build history you need to keep. Teams with versioned settings in Kotlin DSL or XML usually have a clearer inventory to start from. Ask any provider, including DeployOpen, to break the timeline into inventory, conversion, testing and cutover phases.
What does the migration require from our own engineering team?
Your team needs to supply knowledge of which builds are business critical, access to the TeamCity server and version control, owners who can approve the cutover of each project, and people who can confirm that test results and deployments match the old pipelines. Expect time from release engineers for reviewing converted pipelines, and from security staff for agreeing how credentials and agent access are handled. Name these owners in the scope before work starts, because most delays come from waiting for decisions rather than from the technical conversion.
Can our team migrate from TeamCity to Jenkins in-house?
Yes, a team with Jenkins and Groovy experience can do it in-house, and many do. The questions to answer honestly are whether anyone already operates Jenkins in production, whether you have capacity to run the migration alongside normal delivery work, and who will maintain the controller, plugins and agents afterward. If those gaps exist, a fixed-scope engagement can cover the parts you do not want to staff. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, and ongoing support is available as a retainer.
What should a quote for this work include?
A useful quote follows from a written scope and should list the inventory of projects and build configurations in scope, the agent platforms to be supported, the Jenkins controller and agent architecture, plugin selection and maintenance, secrets handling, build history export, migration and parallel run testing, cutover, documentation and handover. It should also state what is excluded, such as application code changes or support after handover. DeployOpen does not publish a price list. A quote follows the written scope, so ask every provider to show how each deliverable maps to a line item.
How do we handle secrets and build history when we leave TeamCity?
Plan for both to be re-created or exported rather than copied across. Secret values generally cannot be read back from hosted CI platforms, and similar restrictions apply to some other vendors, so you should expect to re-enter credentials into Jenkins credentials storage after rotating them where practical. Build history and artifacts should be exported and archived before the old server is retired, because history kept in TeamCity does not automatically move to Jenkins. Confirm with your security team where Jenkins secrets will live, who can read them, and how rotation will be audited.
What recurring costs should we budget for after a Jenkins migration?
The recurring costs are controller and agent infrastructure, storage for $JENKINS_HOME and build logs, time for upgrades (Jenkins publishes a new LTS baseline every 12 weeks, with three LTS releases per baseline), plugin maintenance and security updates, and Java runtime upgrades. Jenkins documents the planned end of support for Java 21 in September 2027 and for Java 25 in September 2029, so include Java upgrades in the operating plan. Any optional support contract is an additional recurring line. Ask for these costs to be listed separately from the one-time migration work.
What the one-time migration costs
The one-time cost of moving from TeamCity to Jenkins sits in five work items, and the migration inventory decides how large each one is. Start by mapping every build configuration and build chain to a Jenkinsfile stage, and decide which TeamCity templates become shared libraries and which agent requirements become Jenkins labels. Each snapshot dependency needs an explicit owner in the new pipeline, because Jenkins does not carry TeamCity's chain semantics across automatically. Whoever performs this mapping pays the cost once, and the count of configurations, templates and chains in your versioned settings drives it directly.
Secured values need separate handling because they cannot be read back out of TeamCity for copying. Plan to re-enter each deployment credential, token and signing key into Jenkins credentials, then rotate the ones that were shared widely or that sit in old projects. Build history and artifacts are a second item: TeamCity keeps them in its own storage, so decide which runs, logs and artifacts must be archived for audit and which can be dropped. Confirm the retention needs for each with your compliance owner before the export starts. Training for the engineers who will maintain Jenkinsfiles and the controller is a recurring investment in the first year, not a single event.
TeamCity Professional limits and the migration inventory also set scope. Professional stops at 100 build configurations, 10 pipelines and 3 agents, so a team that has outgrown those limits is migrating a larger estate than its current license suggests. Run the old and new pipelines in parallel for a defined set of projects, comparing outputs, test results and deployment effects before cutover. Ask any implementation partner for a fixed-scope written plan that lists each inventory item, the validation criteria and the sign-off owner, since that document is what turns these cost components into a quote.
How DeployOpen scopes a fixed-price Jenkins implementation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Jenkins. For a TeamCity cost vs self-hosted Jenkins decision, we start by writing down what the current TeamCity estate contains and what the replacement must cover, so the quote follows from an agreed written scope.
How we scope
- Inventory of TeamCity projects, build configurations, agents and licensed capacity before any cost comparison
- Written list of which pipelines move to Jenkins, which stay on TeamCity and which are retired
- Agreed deliverables, timeline and responsibilities in writing before work starts, since most engagements are fixed-scope
How we build
- Controller and build agent layout planned around Jenkins guidance on dedicated agents and backing up $JENKINS_HOME
- Pipelines written as Jenkinsfiles in source control, with shared libraries and agent labels for TeamCity templates and requirements
- Plugin selection kept to what the migrated pipelines need, with plugin versions pinned and tested before rollout
How we hand over
- Runbooks covering installation, backup and restore, plugin updates and agent provisioning in your environment
- Side-by-side run records comparing TeamCity and Jenkins results for agreed pipelines before cutover
- Documented controls and evidence prepared for your compliance team, with assessment left to independent auditors
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build
- Upgrade planning that follows the Jenkins LTS release line and Java support schedule for your environment
- Ask us to confirm response expectations, upgrade windows and coverage in the written retainer scope
