Reasons To Use CircleCI

CircleCI is a continuous integration platform similar to Travis CI. You can run your tests on it, save artifacts, deploy software, etc. I’ve found that it offers a number of advantages over Travis:

  • Faster builds
  • Custom Docker image support
  • Local build support
  • Less magic

Faster Builds


CircleCI builds boot nearly instantly, which I don’t usually get from Travis. The actual speed of the build is roughly the same from what I can tell, but the quick startup is really valuable to me.

Custom Docker Image Support


This is CircleCI’s killer feature to me. I recently tried to set up an OCaml project on Travis and realized that it wasn’t supported. To work around this, a set of templates that handle manual setup is maintained. However, I’m not a fan of pasting big scripts into my codebase when I don’t really know what they’re doing, so I tried CircleCI instead. Using the plain ocaml/opam2 image, I had my build running in no time, and best of all, I understood how it worked. For less common languages, this is huge. Of course, it’s not that hard to install the needed software manually and use caching to speed up the process, but Docker provides a method that’s so much cleaner.

Local Build Support


Since CircleCI runs on Docker, builds can run identically on both your laptop and CircleCI’s servers. And thanks to the CircleCI CLI, kicking off a local build is trivial. I’ve pushed more tiny Fix CI? commits for Travis than I care to admit, because I can’t test my build setup without pushing my code. With circleci local execute, I usually have a pretty strong guarantee that my badge is going to stay green before I push.

Less Magic


For the languages that it supports, Travis has default install and build steps that can be overridden to run custom scripts. While it’s often convenient to echo 'language: elixir' > .travis.yml and be done, things get trickier when something goes wrong and you have to debug these invisible steps. CircleCI has no equivalent to Travis' before_install, after_script, etc. Instead, your build steps simply go in a list. To me, this is a lot clearer.



While everything above is true, there are a few downsides. CircleCI has a free usage limit of 1000 minutes per month, which won’t be enough for some people. Additionally, there is a limit of a single concurrent build. So if your configuration has a bunch of separate builds or you’re somehow working on a bunch of projects at the same time, you might get backed up. As someone who only maintains a moderate number of small projects, I have never come close to these limits and CircleCI is more than enough.

Don’t get me wrong, I love Travis CI and I continue to use it for a number of projects. But when I want full control over my builds, I usually go with CircleCI these days.