What belongs on a TeamCity server hardening checklist?

A TeamCity hardening checklist covers the server, the people, the agents and the integrations. Patch on release, run in a trusted network behind HTTPS, assign least-privilege roles, use clean disposable agents, and be careful with public pull requests, plugins and settings stored in source repositories.

Why does a CI server need its own checklist?

A build server holds repository access, deploy credentials and the power to run code. JetBrains' own notes state the recommended setup is to deploy TeamCity in a trusted environment with no possibility of access by malicious users, and to upgrade as soon as new versions come out.

Server and data

• Update regularly. TeamCity can download critical security updates automatically, but an administrator still approves installation.
• Restrict the data directory. Anyone who can read it can read every setting, including configured passwords.
• Serve the web interface over HTTPS through a reverse proxy, and make sure it is not reachable over plain HTTP.
• Add DoS protection at the proxy. The notes say TeamCity has no built-in protection against a high request rate.
• Use a dedicated database account with strong credentials.
• Set the installation completed property so a server started with an empty database does not grant access to the first visitor.
• Disable super user access if logs are published anywhere, because the token sits in the server log.

People and permissions

• Use external authentication such as LDAP or a code host, and consider disabling built-in authentication.
• Start from predefined roles and grant the lowest one that works. Create a new role for extra permissions instead of making someone Project Administrator.
• Use per-project authorization so developers reach the compile stage while a smaller group reaches deployment.
• Leave guest login off on internet-exposed servers.
• Give REST scripts their own limited user with expiring tokens.
• Know the consequence of letting someone change build code: the notes say such users can do whatever the agent's OS user can do.

Build agents

• Enforce clean checkout for production builds.
• Prefer disposable, one-off agents with inbound network access blocked.
• Use agent pools per project, and keep the Default pool empty.
• Run one agent per machine where isolation matters, under an OS account with only the permissions it needs.
• Connect agents only to a trusted server, since an administrator of the server can force code to run on a connected agent.
• Deployment chains should disallow personal builds and run on a clean pool.

Integrations

• Do not build pull requests from unknown users on shared agents. Disallow them or use isolated throw-away agents.
• Install only plugins from trusted sources with available source code, since plugins can access everything on the server.
• Keep storage for artifacts private and free of credentials.
• Keep build history for critical deployments and do not grant remove build permission to developers, so you can trace activity later.

A concrete scenario

Constructed example: a public repo builds pull requests on the same agents as the release pipeline. A fork's pull request changes the test script to read the agent's home directory. Splitting the pools, forcing clean checkout and requiring approval for outside contributors removes the path.

What to do

1. Check your TeamCity version against the current release and read the JetBrains security bulletin for it.
2. Walk each checklist section and record yes, no or not applicable.
3. Fix server exposure first, then permissions, then agents.
4. Subscribe to JetBrains security notifications.
5. Scan the repositories your builds use for vulnerable dependencies and committed secrets. Safeguard's CLI and policy gates can add that check to the pipeline.

How often should you review it?

Revisit the list after each major upgrade, after any permission model change, and at least yearly. Review who holds administrator roles each quarter, since access tends to accumulate. Keep the completed checklist with its date, so you can show what changed and why when someone asks.

Quick check

Sources

• Security Notes, TeamCity On-Premises documentation

Last reviewed: 18 October 2026.