First off, let’s just say: Heroku is awesome. There are all kinds of great reasons to use it, and I would never, never claim that Heroku is wrong for all deployments.

But it’s also not right for all deployments. Let’s talk about when it’s wrong and when it’s right.

Heroku’s big advantages are:

• really easy to deploy
• really easy to scale
• mostly everything just works

Those are big advantages. Sometimes they’re the most important thing for your project. When they are, you should absolutely use Heroku.

But why might you not?

It’s Expensive

First, the elephant in the room: the cost. Heroku gives you limited free hours per month, and after that it’s expensive. Background threads or processes also cost extra.

A single minimum-power dyno runs you $36 per month (note: pricing is out of date), assuming you need barely any space in Postgres. Heroku is basically going to cost you at least twice what a VPS would cost (e.g. Linode or Digital Ocean) and give you much less power. If you process many simultaneous requests or run many background threads, it will be at least three or four times as expensive for the same power.

For a powerful server you’re actually using, it’s easy to pay $250/mo for what Amazon might have delivered for $100/mo or Digital Ocean for $80/mo.

Third-party services like MySQL (vs Postgres), Cassandra, Redis or MemCacheD will also cost more if you use them.

Third-Party Services

Speaking of third-party services, they’re not always available. Somebody has to have written a specific Heroku plugin for them, and you’d better hope the version available matches your needs.

For off-the-shelf services, that’s no problem. Redis or MemCacheD, for instance, are pretty easy to use.

But if you want Ventrilo or Akka or a specific version or a specific background process of your own that you’d have to compile… Nope. Heroku’s not the right service in that case, even if you’re willing to pay a lot.

Customization

In general, Heroku limits your ability to customize. You can have the Ruby versions and third-party libraries (e.g. libxml, node.js, libuv) that they specifically provide. Need something weird or a specific version? Sorry, not on Heroku.

Compatibility with app servers is also spotty. They provide Thin for EventMachine, but there are slightly odd limits as a result of the Heroku architecture, and it generally won’t work quite right. Which isn’t a problem if you use Unicorn (now Puma), of course. Heroku is great if you want pre-chosen off-the-shelf components. Which often you do, and occasionally you don’t.

Similarly, the Ruby evented support (e.g. EventMachine) isn’t amazing. That’s not a problem for you… Unless it is.

Architecture

The Heroku architecture is great if you’re building a hosting service, and a little weird if you’re being hosted on it.

Your app needs to be prepared to be killed and put onto a new server at any time, instantly. That means you can’t write to local disk (no log files, no file-based Rails cache), nor assume that things like global variables will last from request to request.

You can do some Heroku-specific logging, but you have to do it all in a very specific style.

Your app serves its own static content, which can be slow – especially in Rails. It also means Heroku silently inserts gem(s) (e.g. railsservestatic_assets) to make your app behave the way they want. And it can cause problems. The reason they changed from Unicorn to Puma was because Unicorn has significant denial-of-service problems without a reverse proxy, for instance.

It also means that a lot of your existing operations knowledge doesn’t work. You can’t log into the machine and poke around, and you certainly can’t modify machine settings or have your application save local state or logs.

Is that a problem? Well, sometimes.

Et Al

Heroku is also hard to use for non-web services that don’t use HTTP. It’s not really set up for them.

It gets your data, which may or may not be a problem. It’s like other cloud vendors, but may not be okay for you.

And Heroku’s scaling of dynos — regular, 2x everything or huge CPU and RAM for 16x the cost — may not be for you. Or it may be fine, depending.

Do I Use Heroku? The Short Version

You’ve read (or skimmed or scrolled) through the long version.

What’s the short version?

The short version is that when you have an installation where you don’t need to customize much, and you don’t need a lot of servers, Heroku is great.

Or when you want utter simplicity and being expensive is fine, Heroku is awesome. Especially if somebody else pays the server bill!