[seanwilson]

> Heroku doesn't maintain database state. Your dyne can essentially be erased and restarted with an empty database. That's not usable for production systems.

Almost, dynos don't persist filesystem changes but for databases you're suppose to host the data elsewhere (e.g. Heroku Postgresq, AWS RDS, AWS S3) and that data will be persisted. This is by design and a very good strategy for production systems as you can then easily scale by adding more stateless dynos later. All configuration for your dynos is stored and versioned in Git and all your important data is stored somewhere robust with proper backups and rollbacks.

If you've advocating storing your state on the server itself by e.g. using AWS EC2 or Digital Ocean, you're going to need your own strategy to make sure you don't lose any data or configuration settings (e.g. packages, config files) when your server box fails and storing state on the server means you can't easily horizontally scale.

When Heroku doesn't let you SSH into active servers, only lets you deploy via Git and doesn't let you store state on servers, it's done intentionally to force you into making good choices that scale.

[valuearb]

Heroku is super easy to use and setup for a newb like me, but never explains this up front. So I was shocked when I figured it out months into using my first dyno. Everything you write makes sense, and hosting my data elsewhere turned out to be easy. But it's definitely an important point to understand, because it adds a layer of cost to hobby projects you want to run full time sites with.