CI/CD platforms offer concurrency controls to limit the number of simultaneous jobs that can be running. This is useful for feature branches; when an engineer pushes a new commit, if a build was running on a previous commit, it can be cancelled. It's also useful for continuous deployment to make sure only one deployment happens at a time. Effectively, concurrency controls provide a lock around the deployment process.
Although locking is an effective solution to ensure that only one deployment is happening at a time, it can also create a backlog. If multiple engineers merge pull requests at the same time, deploying them all sequentially may take a while. If an engineering team is big enough, there is potential to create a very large backlog.
We considered these use cases when designing concurrency pools in RWX and added some options that most other CI/CD platforms do not have.
#Cancel Waiting
In the Continuous Deployment use case when multiple commits are merged in rapid succession, rather than creating a backlog of deployments, a reasonable solution is to skip deploying the earlier commits and only deploy the most recent one.
You can easily do this in RWX by configuring the on-overflow behavior to cancel-waiting
1 2 3 4 5 6 7 8 9on: github: push: if: ${{ event.git.branch == 'main' }} concurrency-pools: - id: your-org/your-repo:main capacity: 1 on-overflow: cancel-waiting
#Cancel Running
For CI builds on feature branches, it's more common to cancel any in progress runs.
You can do this in RWX by configuring the on-overflow behavior to cancel-running
1 2 3 4 5 6 7 8 9 10 11on: github: push: if: ${{ event.git.branch != 'main' }} init: branch: ${{ event.git.branch }} concurrency-pools: - id: your-org/your-repo:branch-${{ init.branch }} capacity: 1 on-overflow: cancel-running
#Queue
Although it's not used as commonly, RWX also offers another configuration option for when you do want to run everything sequentially without canceling any in progress or waiting runs.
In this scenario, you can configure the on-overflow behavior to queue
1 2 3 4 5 6 7 8 9on: github: push: if: ${{ event.git.branch == 'main' }} concurrency-pools: - id: your-org/your-repo:main capacity: 1 on-overflow: queue
#More Flexibility
We've designed RWX to be as flexible as possible to accommodate a wide variety of use cases. A few additional configuration options are available that most other CI/CD platforms do not provide.
You can configure the capacity on the pool to allow more than 1 concurrent run.
concurrency-pools accepts an array, so you can have more than one pool apply.
You can configure an if condition on the pool to determine whether it should apply for the run.
For more details, see the documentation on concurrency pools.
#Follow Along
We write a lot about software engineering best practices and CI/CD pipelines. Follow along on X at @rwx_research, LinkedIn, or our email newsletter
Related posts

RWX November 2025 Recap: container image builds, git patching runs, OTEL, and more
At RWX, we use our own product to rapidly prototype, develop, and ship features all the time. Here's what we've built recently...

We deleted our Dockerfiles: a better, faster way to build container images
Two weeks ago, we deleted the Dockerfile for our application, and we deleted the step in our CI pipelines that previously ran docker build.

