>I found this annoying at first along with not being able to save files to the server. However, Heroku is forcing you to automate server setup so servers can be restarted, destroyed and created without losing data or functionality. If you allow SSHing in to install software and storing files on the server, you're probably going to get some nasty surprises when you need to recreate the server or add more servers for example.

The point the author was making was that automating the installation of custom software on Heroku sucks and that you can't SSH in to debug issues that only occur in the Heroku environment and can't be reproduced locally. Nowhere did the author say they were SSHing in with the intention of installing custom software.

The author is using Docker to create images that contain the OS, the custom software, and the app itself. These images are then loaded onto EC2 instances by Chef and the application is run. There's no manual installation.

Even if the author didn't use Docker, there are a lot of ways to automate server setup with AWS. Anyone seriously using AWS for production software is automating server setup. This isn't some kind of Heroku specific concept.

As skwirl pointed out, yes SSHing is more for debugging production server issues than for setting up the servers.

The transition itself took one month. So far it's been several months and it's been very stable with pretty minimal maintenance. We did end up writing a number of Python scripts to help make the deploy process easy for developers (i.e. replicating most of the common Heroku features we used to use)

While you cannot ssh directly, you can get a bash shell on a heroku dyno quite easily by running:

heroku run bash

This can be very handy for debugging.

That said, heroku will spin up a new dyno instance to run the bash shell. You cannot (as far as I know) get a shell on a specific dyno of your choice.