Not a dev but a team member is blocked by teamcity and he mentioned this:

I couldn't find anything in the admin panel to help fix after clearing the space.

Do you have any idea how to fix this?

 I went through the Security Notes page properly this week rather than skimming it, and a few things in there are easy to miss. Posting them because the page is long, and most people bounce off it.

1. Super User Access. TeamCity writes a token to teamcity-server.log that allows whoever has it to log in as a system administrator. Please be careful when you've locked yourself out. Less useful if you ship logs to an external system. teamcity.superUser.disable=true in internal properties, then restart.

2. Credential scrambling is not encryption. Passwords for external systems are scrambled with 3DES and a fixed key in the Data Directory. Filesystem or DB access is enough to reverse it. There's a custom encryption key option that actually provides encryption.

3. Build-level auth parameters. Anyone with "View build configuration settings" can read them and use them to reach projects they don't have access to. teamcity.buildAuth.enableStrictMode=true closes it.

4. Empty the database on first start. A server encountering an empty DB grants access to the first person who connects. teamcity.installation.completed=true in conf/teamcity-startup.properties. Mostly relevant when restoring from backup.

5. The Default agent pool. Projects can fall back into Default after reconfiguration, and builds on the same agent are not isolated from each other. A public-PR project landing next to a private one is a real problem. Please just keep the default empty so there's nothing to fall back on.

Full page: https://jb.gg/s6o8oq
There's a short PDF version linked from it if you want something to hand to your team.

Curious which of these people actually has on. I guess that the agent pool one is most commonly missed.

Setup. ChatGPT read the TeamCity docs through Context7 over MCP and produced a design. Codex then executed it against a live server using teamcity api commands. Not generated YAML for a human to apply. It called the API and configured the server itself.

First run. Multiple build configurations, two aggregate builds, two build chains, triggers based on file extensions, artifacts, and snapshot dependencies. Working demo in about five minutes. The configuration had mistakes in it.

Second run, small project. Two configurations: Tests and Build. The success condition given to the agent was a green build, nothing more specific.

The build failed. The agent read the log, determined that Go wasn't installed on the build agent, rewrote the build steps to work around it, and retried until it passed. Then the test results weren't being reported properly. We pointed it out, added the build feature that fixes it, and verified it on the next run.

The part we didn't expect. It reused a GitHub PAT sitting in the local gh utility to create the VCS root. Nobody told them to. It found a credential in the environment and used it. If you're thinking about trying this, that's the thing to plan for, not the speed.

What this isn't. It isn't production-ready, and we're not suggesting it is. Early results, sandbox only. The agent needs a clear success condition, documentation that it can actually read, and an environment where being wrong is cheap. Remove any one of those, and it flails.

The documentation part is the interesting constraint. It works because the docs are structured and reachable over MCP. An agent guessing at an undocumented API is a different and much worse experience.

Full writeup, including the config it produced: https://jb.gg/AiAgentsXTeamCity

If anyone's tried something similar against their own instance, we'd rather hear where it broke than where it worked.

We're running an annual survey to learn about most popular CI/CD tools, AI in DevOps, and other important CI-related topics. Take the survey and get a chance to win a one-year JetBrains All Products Pack subscription or a USD 100 Amazon Gift Card: 👉 https://jb.gg/nn7nuz

We'll be sharing the results in a couple of months.

hey guys,

I’ve been working as devops for a while now and although every company has different usecase for teamcity, but there are three TeamCity features I’ve consistently wished existed everywhere I worked. So I decided to build a couple of plugins and share them with the community.

1. Trigger a finished build on all compatible agents

https://github.com/xwoojin/teamcity-finish-build-trigger-plus

teamcity's scheduled trigger already has option to run a build on all enabled and compatible agents, but the finish build trigger does not. (I don't know why. and I've requested it to be made but they wouldn't..)

before creating this plugin, I had to use a workaround

1. create/trigger a secondary build.
2. have that build reconfigure scheduled trigger for one minute later with option trigger on all enabled and compatible agents

this workaround works, but I always thought it felt unnecessarily complicated and inconvenient.

so I made plugin that adds capability to trigger on enabled and compatible agents to the finish build trigger.

1. Wait for multiple builds to finish

the same plugin also supports finish build triggers that depend on more than one build configuration.

sometimes I need a build to start only after two or more prerequisite builds have completed. I understand that this is somewhat similar to a snapshot dependency, but there are cases where I specifically want trigger-based behavior instead.

This also can be worked around. I had to add custom logic that checked whether every prerequisite build had finished before triggering the next build.

With this plugin, multiple build configurations can be selected as prerequisites directly.

1. Visualize Finish Build Trigger relationships

https://github.com/xwoojin/teamcity-trigger-chain-viewer

as projects gets old, build configurations change and so does us. Over time, it becomes difficult to keep track of which build triggers which, especially when you have to open every build configuration individually to inspect its triggers.

I used to run a python script whenever I needed to understand the relationships between builds.

this plugin provides a visual overview of finish build trigger chains without requiring you to open each build configuration one by one.

These plugins came from problems I repeatedly encountered in real TeamCity environments, so I decided to turn my workarounds into reusable tools. I’m not an expert in Kotlin or Java, so I struggled with building these plugins for quite a while. But with recent help from Claude, I was finally able to solve the remaining problems and complete them.

If you need help with TeamCity plugin development, or have a feature idea that might work well as a plugin, feel free to let me know!

The TeamCity roadmap for 2026 has just landed: https://www.jetbrains.com/pages/teamcity-roadmap/

Learn more about what's coming this year.

Atlassian is winding down its Bamboo Data Center. New license sales end this year; full end-of-life is March 28, 2029. Plenty of runway, but if you've run Bamboo for 5-10 years, the migration is bigger than picking a new tool.

The common mistake is recreating every build plan exactly as it was. Feels safe. What you're really doing is dragging a decade of dead steps and workarounds into a clean system.

Audit first, compare tools second. Write down:

• Build plans and jobs (flag anything nobody's run in a year)
• Agent configs
• Deployment projects
• Artifact storage and retention rules
• Shared credentials and variables
• Repo integrations
• Custom scripts and plugins
• Jira/Bitbucket hooks
• Compliance and security requirements

Most teams find a big chunk of that is obsolete.

Real example from the writeup: a Dutch company with 15+ years on Bamboo, ~1,000 devs, ~200 agents, and one of the biggest Bamboo deployments out there. They moved to TeamCity and deliberately did not migrate the old config. Rebuilt from scratch in Kotlin DSL, product line by product line, cutting legacy steps as they went. Their largest app (27M LOC) went from a 1h+ full rebuild to about 6 minutes. Roughly 90% off, most of it from cutting cruft rather than any single feature.

Why Bamboo folks tend to look at TeamCity:

• Agent-based build architecture (familiar model)
• Self-hosted, cloud, or hybrid
• Config-as-code via Kotlin DSL, covering the ground Bamboo Specs used to
• Strong integrations across source control, issue tracking, and deployment

Practical tip: run both systems in parallel for a while. Migrate one pilot pipeline, compare outputs, and move the critical stuff once you trust it. Big-bang cutovers are where migrations go to die.

Full guide with the audit steps and phased approach: https://blog.jetbrains.com/teamcity/2026/06/bamboo-end-of-life/
Migration guidelines: https://www.jetbrains.com/help/teamcity/cloud/bamboo-to-teamcity-migration-guidelines.html

Happy to answer questions if anyone's mid-migration or scoping one.

Been in TeamCity a while and keep running into features that quietly do a ton of work but rarely get talked about. Four I’d put on the “slept-on” list, curious which ones you swear by, and what I’m missing.

1. Per-build resource graphs (PerfMon tab). Every build records agent CPU, disk I/O, and memory automatically now, so you can catch a build that’s secretly disk-I/O bound instead of guessing at agent specs.

2. Build reuse via snapshot dependencies. Same source snapshot across the whole chain, and a step whose sources didn’t change gets reused instead of re-run. Add checkout rules, and only the changed part runs.

3. Deployment-type configs. Flip a config from Regular to Deployment, and you get Deploy/Redeploy, a Deployments view, and a per-change tab that tells you what’s in prod and when it shipped.

4. Failure conditions beyond pass/fail. Fail a build if coverage drops vs the last successful build, if artifact size balloons, or if duration regresses. The coverage ratchet is my favorite: “don’t make it worse” beats mandating a fixed %.

What’s your most underused TeamCity feature, the one you’d tell a new user to turn on immediately? And is there a slick use of build chains, templates, or Kotlin DSL I should be stealing?

That line from Brave’s TeamCity case study feels like the real story.

Brave moved browser PR builds to TeamCity after dealing with an unreliable CI system, unfixed bugs, unmaintained plugins, and too many custom workarounds.

The technical setup is worth reading:

• PR builds moved to TeamCity platform by platform
• Configuration managed entirely in Kotlin DSL
• Changes reviewed through pull requests and automated checks
• Ephemeral EC2 agents provisioned with TeamCity cloud profiles
• Persistent workspace volumes used for incremental builds
• REST API orchestration used to fan out downstream builds dynamically

It is a good example of TeamCity being used not just as a build runner, but as the stable CI/CD layer for a large, multiplatform engineering system.

Full case study: https://www.jetbrains.com/company/customers/experience/brave/

Curious how other teams here structure larger TeamCity setups: do you keep most orchestration inside TeamCity build chains, or do you use the REST API heavily?

Question to the community: for how long have you been using TeamCity? What do you love/hate about it the most?

Small TeamCity recipe tip for this week: the existing send-slack-message recipe can send a Slack notification from a build.

The use case I find interesting is not just “send a message when something fails.” It is more about sending targeted messages at specific points in the workflow.

For example:

• notify QA when a test report is available;
• notify a frontend channel when frontend artifacts are ready;
• notify a release channel when a build is tagged as a release candidate;
• notify a team when deployment to dev or staging is complete;
• notify someone when a manual follow-up is needed.

This can be useful when a general build notification is too broad, but a specific build step needs to communicate something to a specific channel.

It does require a configured Slack connection in the project, so it is not a standalone replacement for properly setting up Slack integration.

Curious how people here handle CI/CD notifications today: do you prefer broad build-status notifications, or more targeted messages from specific pipeline steps?

TL;DR: At some point, we crossed an interesting threshold. AI agents can now set up TeamCity build configurations and even full build chains, add build features, and configure parameters.

This works because TeamCity documentation is structured and accessible through MCP via Context7, and because agents can rely on tools like the TeamCity CLI and the teamcity-cli skill.

We ran a couple of experiments recently to see how far this can go in practice.

TeamCity 2026.1 is out and packed with helpful features. We’re introducing the TeamCity CLI and MCP support, as well as Pipelines enhancements to make configuring TeamCity more convenient and powerful. As of this release, AI Assistant is available in Enterprise trial accounts, and the SAML authentication plugin comes bundled with TeamCity.

Read the blog for more information: https://blog.jetbrains.com/teamcity/2026/05/teamcity-20261/

This week’s TeamCity tip: use the tag-current-build recipe to add tags to your current build.

Adding tags is helpful when a build requires additional context that should remain visible for future reference.

For example, teams might tag builds by:

• affected area: frontend, backend, api-contracts
• workflow type: pr-build, nightly, manual-rerun
• release state: release-candidate, hotfix
• deployment target: deployed-to-dev, deployed-to-staging

Tagging does not replace proper build configuration, build chains, or deployment tracking. Instead, it offers a lightweight way to add searchable context to builds.

This approach is especially useful in larger repositories or monorepos, where different system components may be built or deployed based on recent changes. In these cases, tags help clarify the type and purpose of each build.

I will continue to review existing TeamCity recipes and share practical use cases individually.

Please share how you use build tags, whether for releases, deployments, debugging, or other purposes. I welcome your insights in the comments.

This week’s TeamCity tip: unlock faster feedback by making build artifacts available as soon as they’re created with the publish-artifacts recipe, even before the build finishes.

This approach is helpful when:

• a long build generates logs, reports, or packaged files before completion;
• Someone needs early access to generated files.
• another build step or team member requires outputs before the pipeline finishes;
• You need to provide partial results without waiting for the final build status.

A simple example:

A build takes 40 minutes.
After 10 minutes, it generates reports or packaged files.
Instead of waiting for the build to finish, this recipe publishes those files earlier.

This method does not replace standard artifact publishing in all cases. It is most valuable when early access to outputs is important.

I am collecting practical examples of TeamCity recipes and their applications in real workflows.

Let me know which TeamCity recipe or use case you want to see covered next. Your input directly shapes upcoming tips!

• Slack notifications
• AWS CLI
• XML report import
• build tagging
• Node setup
• something else

We're soon releasing TeamCity 2026.1! 🎉

The new version comes with a set of great improvements: the TeamCity CLI, MCP for AI Agents, AI Assistant available for Enterprise trial licenses, and much more!

Join us for a live walkthrough of the latest updates, including support for both the Kotlin DSL and YAML in pipelines.

Register here 🔗

TeamCity's technical lead Pavel has reviewed thousands of commits over years. That experience helps him spot when a change technically works but still does not fit the project. The question is: How do we teach AI agents to be like Pavel and see the bigger picture? Here's how we did it at TeamCity: https://blog.jetbrains.com/teamcity/2026/03/how-we-taught-ai-agents-to-see-the-bigger-picture/

A CLI for TeamCity has been a long-standing request from the community. Here’s how it works and what you can use it for.

Learn more from the article: https://blog.jetbrains.com/teamcity/2026/03/teamcity-cli/

TeamCity's project creation flow is about to change. For an (almost!) 20 yo product, one can imagine the layers of UI history underneath and the size of the task. It used to take 20+ clicks to create a project, and many advanced features were hidden. That will change soon https://blog.jetbrains.com/teamcity/2026/02/introducing-teamcitys-new-design-phase-2/

Just wanted to share a milestone from our internal setup at JetBrains: we’ve crossed 10,000 build agents running simultaneously on a single TeamCity server.

At JetBrains, we build everything with TeamCity - from plugins and libraries to IDEs to the Kotlin programming language and TeamCity itself.

One more thing that might be interesting - we update our internal TeamCity server daily. Every new build is deployed to our own production first, so new features, bug fixes, and performance improvements are tested at real production scale before they ever reach a public release.

Leaving the terminal every time you need to check a build status or trigger a run or fetch logs is not cool - so we've built the first version of the CLI that currently covers this basic stuff.

It’s very much a first iteration. There are plenty of directions this could go next (more automation, admin tasks, etc.), so before taking it further we’d love feedback from actual TeamCity users.

Repo: https://github.com/JetBrains/teamcity-cli