"the annoying configuration pieces involved in getting CI to match production" This could be resolved with proper tooling. Depending on what you're doing, Dock

"the annoying configuration pieces involved in getting CI to match production" This could be resolved with proper tooling. Depending on what you're doing, Docker, Terraform, Make, build scripts, etc can be used to make every environment as identical as possible. "n CircleCI, you're configuring against a moving target installation of binaries, and whenever CircleCI decides to upgrade Postgres or Redis or whatever, your tests start failing and you don't know why." This is a very fair concern and has been voiced in the past. CircleCI 2.0 does not have that issue anymore, as the other commenter pointed out. "in CircleCI you can't read the config vars you've set previously from the interface" This is common in webapps and is for security reasons. If the variable value isn't secret, such as the local DB URI, you can set it in `circle.yml` or `.circleci/config.yml` instead. Fully visible and now versioned. "On top of that CircleCI's documentation is much worse than Heroku's" This I take very personally as docs are important to me and I work on them constantly. Our docs are open-sourced on GitHub (https://github.com/circleci/circleci-docs https://github.com/circleci/circleci-docs) if you'd like to help make them better. If you prefer a conversation, you can always reach out to me on CircleCI Discuss (https://discuss.circleci.com/ https://discuss.circleci.com/) or DM me on Twitter (@FelicianoTech). I would LOVE to improve docs. Your ultimate point of spending less time with CI servers is 100% the goal for SaaS CI. If Heroku, CircleCI, Travis CI, or any others cause you to spend more time in the tool, then they're failing. disclaimer: Developer Evangelist, CircleCI