Cut your CI build time to a few minutes,
no matter the size of your test suite

Semaphore Boosters analyze your test files and automatically parallelize your CI builds.

Book a personal demo
 Test faster  Get quicker feedback  Deliver more features  Save time and money

3 steps to a parallel CI build

1 Let Semaphore run a sample build on a branch.
2 Select the optimal number of parallel jobs for your project.
3 Done! Your test suite runs in a fraction of time and life is awesome again.

What happens under the hood?

Boosters automatically distribute your tests into parallel jobs. Over time, Semaphore tracks your build to ensure that the duration of your CI build is no longer than that of your slowest test file.

Let Semaphore collect your test metrics with just one click, and after the first successful parallel build, simply select the optimal number of jobs. You'll have test and deploy cycles that are 10+ times faster without having to make any changes in your source code.

Thomas Winkler

CTO at SimpliFlow

“We were able to reduce the time of our test suite from 1 hour and 30 minutes to 10 minutes!”

Bryce Senz

CIO at Credda

“Our productivity has increased tremendously, almost doubling our output in terms of tickets we close each week.”

Supported Ruby testing frameworks

Logo cucumber
Logo rspec
Support for more languages coming soon

Book a personal demo

We're excited about the benefits that Boosters bring to developers and would love to personally meet every team that needs them. Fill out the form below to schedule a 30-minute demo session. One of the core engineers will walk you through the feature and answer any questions you may have.

Boosters FAQ

How are Boosters different from configuring parallel jobs in a CI service?

You can already manually configure parallel CI jobs using Semaphore, and this feature has been around since 2012. However, writing down build steps for every parallel job leads to suboptimal workload distribution. Simply put, if one job takes 10 minutes to run and another one takes 14 minutes, with manual configuration your total build time would be 14 minutes. Tweaking that further, e.g. by subfolders, is prone to introducing errors and skipping new tests as they get added.

The manual approach is also very difficult to scale horizontally. Automatic parallelization with Boosters can bring even the longest test suite down to a few minutes just by moving a slider.

How do Boosters differ from open source libraries that parallelize tests, such as Knapsack for Ruby?

A recent Boosters user has reported a faster CI build compared to what they had with Knapsack with half the resources.

The key reason is that Semaphore Boosters automatically parallelize tests with a perfectly even distribution of workload across CI boxes. With Knapsack, developers are required to maintain and update a configuration file with test durations, so in practice parallelization is usually based on outdated information and suboptimal.

There are also tools such as parallel_test for Ruby, which distributes test files across multiple CPU cores. This is additionally less effective in a hosted CI environment, where each job has access to only one CPU.

Do Boosters require changing my test configuration to produce a specific output?

No. Boosters just work, without any change in your source code or CI configuration.

Do I need to pay anything extra to use Boosters?

No. Boosters are available free of charge to Semaphore users. The capacity Boosters can use for parallelism depends on the size of your plan.

Can I see how exactly Boosters run my tests?

Yes! The tool that’s responsible for test file distribution is open source, and we invite you to take a look and contribute. The backend for recording test file duration is proprietary.

What are the limitations of Boosters?

If your test suite contains flaky tests, you may see unexpected build failures as parallel execution tends to expose them. We shared some ideas on dealing with flaky tests here and here.

Also, if you have a test file that takes 5 minutes to run, your build cannot be parallelized to run below 5 minutes. This situation can be solved by splitting long-running test groups into multiple files.


Human-frequency product and article updates. Unsubscribe at any time.

© 2009-2019 Rendered Text. All rights reserved. Fine print: Terms of Service, Privacy policy, Security.

Just arrived:
Semaphore 2.0

  • Implement any CI/CD pipeline
  • Configure everything in code
  • Never wait with autoscaling
  • Pay only for what you use
Learn more