I'm not really sure why this is preferrable over CircleCI? Could someone explain? Especially since CirleCI is free for the first container. This costs $10, and I don't understand the additional benefits of $10 here.
In my opinion CircleCI's configuration UX is actually really poor—compared to what it could be, and what Heroku provides.
In 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. Then you have to try to figure out how they've configured the services, and what it will take to use Postgres 9.5.3 instead of 9.6.1—big hassle.
Then there's the little UX things—in CircleCI you can't read the config vars you've set previously from the interface, which means you have to go through the super tedious process running a new build, SSH'ing into it, and then reading them from there, just to remember what user your Postgres connection URI uses.
On top of that CircleCI's documentation is much worse than Heroku's, so re-learning how to do all the random configuration things you need to do each time is more difficult than it could be.
I think anything that reduces time spent messing with CI servers is a big plus, because that work is usually the most frustrating work there is. $10/mo is nothing compared to wasting a day dealing with CI configuration every once in a while.
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) 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/) 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