While writing your own deployment script may only take a few minutes, it would take more time in the future to upgrade the host system. With Heroku, you get automatic upgraded systems, and databases to prevent system rot. For example, when you deploy to amazon AWS, you are responsible for upgrading the system. I think my personal web app on AWS is still using ubuntu 12.10, from 2012. Now obviously upgrading one app is easy, but if I had 100 apps on different systems, it would take far longer to upgrade and test.
The 12 factor app, Heroku’s manifesto of how apps should be deployed onto its system, is actually a good practice to follow anywhere. Its third rule, of storing configs in environmental variables, is the simplest method to deploy, but hardest to setup in your local development environment. I actually used to store configurations inside the code itself, which is easy to develop but harder to deploy. In python, I’ve learned to use sandboxed environmental variables in my virtual-environment bin/postactive script.
Each app has all its dependencies declared using the language’s package manager. However when using multiple languages such as python and node, you can use multiple build packs, https://devcenter.heroku.com/articles/using-multiple-buildpacks-for-an-app.
There are many good features about Heroku. The command line tool, heroku toolbelt, is very intuitive. It reminds me of the best features of most essential tools like git and ionic. To run custom scripts, just run heroku run –app APPNAME command. The time it takes to deploy a new version production is in minutes.
Obviously the worst part is the price, but if you follow best practices, it shouldn’t be hard to switch to another provider. Docker is similar to heroku, so you can actually use docker on heroku, https://devcenter.heroku.com/articles/docker.
