Thread by @nicalpi

I've spent the weekend trying out possible Heroku replacements for two different Rails use case

- Amba production app where we would be looking to scale and offer web servers and database connections closer to our US and UK customers.

- Looking at deploying a small pet app

🧵

HEROKU

First, let me get out of the way that I'm perfectly happy with Heroku for now. Yes their Dynos could be upgraded and recent outages are annoying but, overall, their ease of deployment and robustness is still second to none.

Less than 5 minutes to deploy the pet app.

I don't think we would be able to achieve multi region to Heroku tho, but, for our use case, it's not inconceivable to have a us.domain.com as a separate app.

Render @render

Was the next one I tried. Their doc is ok, but I spent too much time fighting with the render.yaml.

Price point is a lot more flexible than Heroku.

The service is working great (reminder a pet app with no traffic)

The things that caught me when coming from Heroku

You're deploying infrastructure not app. So it's essential to start with group env vars so web and worker can share them.

Since you're dealing with contained servers, it's easy to deploy (with manual deploys) you latest change on the web and forget to update the workers. Should not be a problem when using auto deploy.

There's been a few instances where changing env vars didn't trigger a deploy tho

Finally, if you want to have a staging app and a production app, you can only use one render.yaml file. I find working with infrastructure as code a bit annoying but you shouldn't need to touch it often tho.

Docs are great, and, once you understand the concepts, I think you can get up and running quite quickly. For your first deploy, expect to mess around for a good hour or two tho.

Multi region: same issue as Heroku and would have to result on a region based app probably for now.

Next on the list was Fly @flydotio

Obviously here the the multi region is their bread and butter.

But for the pet app, the deployment was a bit of a frustrating experience.

I followed their getting started Rails guide, and, got stuck on a random jemalloc error.

Turns out the ruby version on the build was set with ~>3.1 and it needed to be an actual version like 3.1.2.

I also got stuck on a build error because my Gemfile referenced a gem in the ./lib path.

The solution was to, in the dockercontainer, initiate the copy of the code before the actual build.

Overall the Fly cli was quite good to deal with and the fly deploy command would deploy things on all servers (workers and web)

The one thing that I was concerned about was the "community support". For my issues I checked the forums, and found people with messages left unanswered.

Next on the list was Railway app @Railway

This one requires a complete rethink on how you view deployments. Their pricing is based on usage and should essentially adapt to use/traffic.

I didn't deploy anything there, but, form their doc, it seemed the simplest of all.

Last but not least was Hatchbox V2 @hatchboxio

I used Hatchbox before for some client project and I'm not against bare metal. Their V2 is really nice and their price point is great for tiny apps or large apps.

For medium size apps (2 web, 1 worker, 1 db, 1 redis) it can quickly lead to similar(ish) cost than Heroku but with bigger servers.

The deployments of the pet app was quite simple and I was up and running in maybe 20 minutes max.

I think Hatchbox should really be taken in considerations for everyone looking to move away their small free dynos from Heroku as you can get away with a lot one a single mid range server.

A couple of things to note tho:

1. These are not managed servers, you will be in charge of them.

2. I could swear that V1 had an option to run an "update servers" script that has disappeared on V2 (maybe I can write my own script tho).

3. You can (and should?) use managed databased from different providers (DO, RDS, Linode).

4. Unlike others, it will be difficult to achieve a zero downtime (at least 0 slow down) deployment since the rails app has to be restarted on the server.

A very similar option that I used in the past is Cloud66 @cloud66. I haven't done a test for my pet app, but I remember using them in the past and the experience was a little bit more frustrating than Hatchbox, price point higher, but the overall result was the same.

For my multi region requirements, I think they could be achieved with

1 cluster europe (lb web, worker)
1 cluster us (lb, web, worker)

Db/Redis + replicas in regions

And use Cloudfront LB or Route53 to direct the queries to the right server or sub load balancer.

Overall, my observations would be

Heroku is still at the top of their game when it comes to easy of deployment. And when you have issues, it's easy to find a solution somewhere.

Render, Fly, Railway are very interesting solutions but I, I thing, I would get cold feet when it comes to production applications. Currently those services are doing well, but they lack the support size of a player like Heroku.

Overall I'm wondering how they will respond/behave when the "shit hits the fan" and 80 of their user base is down.

Future will tell, and, based on the team and brains behind those I'm sure they will be absolutely fine, but

let's remember that using services like those (Heroku included) all our eggs are in the same basket.

These days, while I would still like to use a managed DB, I think I would be perfectly happy for my pet project to use Hatchbox.

In fact, even for bigger production apps, having had Rails apps on random Rails servers for donkey years, I realise that they actually never go down (a lot less than Heroku for sure). When they it's a bit more tricky to figure out, but it's the price to pay I guess.

The one think I was surprised about with @hatchboxio is the fact that they moved from Nginx to Caddy.

While Caddy offers simpler configurations and management, I'm wondering what the performance is like under big loads.

@hatchboxio But remember:

1. If you hit those limits, it will still be cheaper to add more servers to the problem.

2. You're on bare metal, there's nothing stopping you to replace Caddy for Nginx with deploy and setup scripts.