3 ms·
Heroku is expensive because of their markup, but more so because their platform forces everything to be separate managed, modular instances whose costs add up f
by ProblemFactory 12y ago
Heroku is expensive because of their markup, but more so because their platform forces everything to be separate managed, modular instances whose costs add up fast.
* Want a web server instance that doesn't get shut down between requests? Then get at least 2 web dynos at $35/month each.
* Want to run background jobs that are longer than 30 seconds? Then get a separate worker dyno at $35/month.
* Want a database with more than 10K (!) rows? That's at least $10/month.
* Want a memcache? That's $15+/month.
And so on. For a small to medium popularity site, all of these could be combined into one VPS on traditional cloud hosting. Heroku would make sense for a startup that has plenty of cash and limited developer resources (-> buy fully-managed-everything), and knows it will need to scale to tens or hundreds of servers to handle traffic very soon. But for most hobby webapps, a single VPS somewhere else will be 10x cheaper and good enough for a long, long while.
- mattgibson 12y agoIf you enable the free New Relic add on and turn on availability checking, then the pings it sends every 60 seconds keep the dynos from ever being shut down. Also, if you're using Rails, switching to Unicorn as the server allows 3-5 concurrent requests, so you can get quite a bit out of the one free dyno if you don't use the standard config.
- rajivm 12y ago* minor correction to the above -- the first dyno is "free", so you only need to pay for one $35/month dyno to get 2 web dynos that don't get shut down
- tempestn 12y agoEven beyond medium popularity (depending on the type of site of course), you can move from a VPS to a dedicated server and handle quite a bit of traffic before you would need to use multiple boxes. (At least with some basic sysadmin skills, like using nginx instead of apache, or at least switching apache to the worker or event mpm and configuring it appropriately.) The next step from there could be moving the database to a separate server. You can get quite a ways without even worrying about load balancing/proxying/mirroring/etc.