TeamCity pricing in 2026
./teamcity --professional --enterprise --cloud
TeamCity is JetBrains's CI/CD platform and the default CI choice for many JVM-heavy organisations. The pricing model is unusual for modern CI: TeamCity Professional is free with a generous-for-small-teams 3 build agents and 100 build configurations, and Enterprise pricing is a one-time-per-year licence fee rather than a per-user subscription. TeamCity Cloud (SaaS) is more conventional, billed per active user with included build credits. This page works through what each option costs in 2026 and where TeamCity fits in the CI/CD landscape.
Pricing here is sourced from the public TeamCity buy page, verified May 2026.
The three flavours of TeamCity
| Edition | Cost | Build agents | Build configs |
|---|---|---|---|
| Professional | $0 | 3 included | 100 max |
| Server (Enterprise) | $1,999 / yr base | 3 included, +$299/agent/yr | Unlimited |
| Cloud (SaaS) | $45 / user / mo | Hosted by JetBrains | Unlimited |
# Server edition users get unlimited users at no per-seat cost; only build agents and the base server licence cost money.
What the free Professional tier actually covers
TeamCity Professional is free for any usage, commercial or otherwise. The limits are 3 build agents (so 3 concurrent jobs) and 100 build configurations (so 100 distinct pipelines). For a small team that means roughly 30-60 builds per day comfortably, depending on average build duration. The build-config limit catches larger teams faster than the agent limit: each branch-aware pipeline tends to count as a config, so a team with 25 microservices and a release pipeline per service hits the 100 cap quickly.
Beyond the limits, you upgrade to Server (also called Enterprise in some JetBrains documents). The Server upgrade removes the configuration limit and adds priority support, custom plugins and additional plugins-marketplace access. The base Server licence is $1,999 per year for the unlimited-configurations server, plus $299 per additional build agent per year. The cumulative price is much lower than per-user SaaS at scale: a JVM shop running 10 build agents pays $1,999 + 7 x $299 = $4,092 annually total, regardless of seat count.
Open-source projects get free Server licences via JetBrains's open-source programme. The application process is straightforward and the licence is comparable to JetBrains's IDE OSS programme.
TeamCity Cloud, in detail
TeamCity Cloud is the SaaS variant, hosted by JetBrains. Pricing starts at $45 per active user per month and includes 24,000 build credits per user. A build credit is roughly equivalent to one minute on a standard Linux runner. The credit model is similar to CircleCI's approach: bigger machines (4-core, 8-core) consume more credits per minute, smaller machines fewer. Unused credits roll over for two months.
For a 10-developer JVM team that runs 100 builds per day at 8 minutes each, monthly usage is 800 daily minutes times 21 working days = 16,800 minutes. That fits comfortably inside the 240,000 included credits (10 users x 24,000) at the standard machine size. Total monthly cost = 10 x $45 = $450. Compared to GitHub Actions Team for the same workload, TeamCity Cloud is roughly competitive at this scale and meaningfully cheaper at higher scale because the per-user credit allowance is generous.
Cloud handles the operational responsibility for the server and the build agents. You write pipelines (in YAML or in the Kotlin DSL that TeamCity has historically championed) and TeamCity executes them. The trade-off vs Server is the per-user pricing model; for teams above 20 users, the annual cost on Server with 8 agents is often less than the same team on Cloud with 24-month-rolling credits.
JVM-shop economics
TeamCity is over-represented in JVM shops for two reasons. First, JetBrains is the dominant JVM tooling vendor and the IntelliJ-TeamCity integration is genuinely tight: build configurations can be opened directly in IntelliJ, pipeline-level annotations show up in the IDE, and the developer workflow feels uniform across IDE and CI. Second, TeamCity's first-class support for Gradle and Maven, including detailed dependency analysis and parallel build distribution, is a noticeable productivity benefit for Gradle-heavy codebases.
For a 50-developer Java or Kotlin shop already paying for IntelliJ IDEA Ultimate licences, the marginal cost of TeamCity Server is small compared to the integration benefit. The same shop trying to adopt GitHub Actions or GitLab CI runs into Gradle cache warmth issues and slower JVM warmup penalties because the platforms are designed around stateless ephemeral runners rather than the persistent agent model TeamCity uses by default.
Outside JVM, the case for TeamCity is weaker. It supports Node, Python, Go and .NET adequately but the ecosystem advantage that matters in JVM (deep Gradle integration, JetBrains tooling parity) does not transfer. A Node-only team picking CI/CD on greenfield in 2026 would land on GitHub Actions or GitLab CI almost always; the JetBrains gravity that pulls JVM shops to TeamCity is absent.
Operational footprint
A self-hosted TeamCity Server runs comfortably on a single VM with 4 GB of RAM for the server, plus separate agents for the build workload. The agents can be VMs or Kubernetes pods using JetBrains's official agent Docker images. Most production deployments use a Postgres backend (the default in-memory HSQL is fine for evaluation but not production), which adds the cost of a small RDS or self-hosted Postgres instance.
Operator overhead lands at 2-6 hours per month for a typical mid-size deployment: occasional plugin upgrades, agent scaling adjustments, database vacuum operations, and the every-six-months major-version upgrade. The upgrades are largely undramatic; JetBrains is conservative with breaking changes and most version-to-version upgrades work without configuration changes.
Related deep dives
Frequently Asked Questions
# click any question to expand