// Solutions

Let TeamCity build. Let Jaws Deploy ship.

TeamCity is one of the best CI servers ever shipped. It is not a deployment automation platform, even when teams try very hard to make it act like one. Jaws Deploy is the deployment half of that pair - environment-aware, release-centric, and built to start where TeamCity finishes.

Start free Contact us

The pattern that just works

If you've been on TeamCity for a few years and your deployments live inside TeamCity build configurations, you've probably noticed the tension: build configurations are great at producing artifacts, and they are fine at deploying them, until they aren't. Then you have a build configuration with thirty steps, half of which are deployment-only, and the deployment knowledge is encoded in the order of those steps and the parameters somebody set six months ago.

The healthier shape: TeamCity stays a build server. It compiles, tests, packages, and pushes the artifact. From there, a separate deployment platform - Jaws Deploy - handles the release. Two tools, each one doing its job well, each one staying out of the other's lane.

// The single largest lift from this pattern

Deployment configuration stops living in TeamCity.

When the deployment lives inside a TeamCity build configuration, configuration changes go through the same approval (or non-approval) process as build changes. That tends to be 'whoever has TeamCity admin can change anything'. Splitting the deployment into Jaws Deploy means deployment changes have their own audit trail, their own permissions, and their own review cycle - separate from 'we adjusted the build runner.'

Build changes stay in TeamCity, with the build team.
Deployment changes stay in Jaws Deploy, with whoever owns release.
Audit trails are separated by responsibility, not by accident.

Two ways to wire them together

There are two clean integration patterns. The right one depends on whether you want TeamCity to trigger releases automatically, or whether your release process has its own cadence.

// Pattern A

Auto-release after successful build

The last step in the TeamCity build configuration calls Jaws Deploy to create a release with the just-built artifact, optionally targeting Dev. The release is then promoted from Dev to Staging to Production through Jaws Deploy. This is the common case.

// Pattern B

Manual release from a confirmed build

TeamCity builds and tests, but does not automatically create a release. Engineers create releases in Jaws Deploy when they're ready, pulling from the most recent successful TeamCity build. Used by teams with strict release governance.

The TeamCity plugin

For Pattern A, we ship a TeamCity build runner that handles the integration as a one-step build step. You configure it in the TeamCity UI: which Jaws Deploy server, which project, where the artifact lives. The plugin handles the rest - creating the release with the right version number, attaching the right packages, and optionally deploying to a starting environment.

What the TeamCity plugin does for you

Pushes artifacts From the TeamCity build output to the Jaws Deploy package feed. Handles versioning, retries on transient failures, and respects the workspace's auth model.

Creates the release With the right version (from TeamCity's build number, build counter, or a custom pattern), the right release notes (pulled from VCS commits), and the right package versions.

Optionally deploys Triggers a deployment to a starting environment (usually Dev or an integration env) so the build feedback loop closes immediately.

Streams status back TeamCity build log shows the Jaws Deploy deployment status inline, so the build report tells you whether the release succeeded - not just that it was triggered.

// What this looks like in TeamCity build settings

One build step, conceptually

The plugin's build step in TeamCity has a handful of fields. Most teams set up a template once and reuse it across projects.

# TeamCity Build Step: Jaws Deploy - Create Release

Jaws Deploy Server   : https://app.jawsdeploy.net
Workspace            : default
Project              : %env.PROJECT_NAME%
Version              : %build.number%
Package               : %env.PROJECT_NAME%/%build.number%
Release Notes Source : VCS commits since last build
Deploy To             : Dev    (optional - leave blank for manual)

# After the build succeeds, this step runs.
# After this step runs, your release exists in Jaws Deploy.
# After (optional) deploy: Dev is live with the new build.

When the plugin isn't the right tool

The plugin is the easy path, but it isn't the only path. Some teams have build pipelines that need more control over when, what, and how the release is created. For those cases, the same integration is available through the PowerShell SDK and the REST API - just called from a script step in TeamCity instead of the plugin.

// When to drop down to the SDK or REST API

Plugin is good. Sometimes you need more.

Conditional release creation - 'only create a release if the build was on the main branch and the tag matches a pattern'. The plugin's conditions are limited; the SDK is full PowerShell.
Multi-package releases - if a single release pulls artifacts from multiple TeamCity build configurations, the SDK is much easier to choreograph.
Custom release notes - if you generate release notes from JIRA or a wiki, you'll script that in a build step before the SDK call anyway.
Non-PowerShell environments - if your TeamCity agents are Linux-only, use the REST API from bash. Same underlying calls, no language constraint.

// A common confusion we'll clear up

'TeamCity has deployment features. Why do I need another tool?'

TeamCity has deployment-capable build steps. That is a different thing from a deployment automation platform. Build steps can deploy - they can also brick a production database, and there's no first-class concept of 'release', 'environment', or 'promotion' inside TeamCity. You can fake it with parameters, project hierarchies, and template tricks. Eventually somebody fakes it incorrectly and Production becomes Staging for an hour. A tool built for deployment makes that mistake harder to make.

TeamCity: builds, tests, packages, deploys capable.
Jaws Deploy: releases, environments, promotions, audit trail.
Pairing them is what most healthy teams settle on.

The migration off 'TeamCity deploys everything'

Most teams reading this are already on TeamCity and have grown an unhealthy amount of deployment logic inside it. The migration is gradual on purpose.

// Migration in phases

Don't big-bang this

Phase 1 - install the Jaws Deploy plugin in TeamCity. Pick one project. Have TeamCity create a release in Jaws Deploy after each successful build. Don't change anything else yet.
Phase 2 - move that one project's deployment into Jaws Deploy. TeamCity's deployment steps are now disabled; Jaws Deploy handles Dev, Staging, Production for that project.
Phase 3 - migrate the rest of the projects, one at a time. Each one looks the same as the first.
Phase 4 - clean up. Delete the now-unused TeamCity build configurations or build steps. The build configurations stop being 200 lines long.

// Before

TeamCity does everything

Build → test → package → push artifact → deploy to dev → smoke test → tag → deploy to staging → smoke test → wait for approval → deploy to prod. All in TeamCity. All in build configurations. All tangled.

// After

Two tools, clean handoff

TeamCity: build → test → package → push to Jaws Deploy → create release. Jaws Deploy: dev → staging → prod with proper environment scoping, variables, and a real audit trail. Each tool stays in its lane.

The honest reason this combo works

TeamCity and Jaws Deploy do not compete. We have no interest in being a CI server. JetBrains has no particular interest in being a release platform. The integration is the obvious answer, and the only reason teams haven't been doing it for years is that the deployment-side options were either too expensive or too heavy. We are explicitly the lighter-weight alternative built to pair with what you already have - not to replace it.

If you're on TeamCity and your deployment process has outgrown build configurations - this is the path.