I have a Ruby on Rails app and static site to support my SaaS app both now hosted on Render.com. Good things have been said about Render and now seemed like a good time to compare the cost and health of my app to running on Heroku.
As I dove into hosting there here are some things I noticed right away when coming from Heroku:
- No "App" and no "Dynos". There are "shared environments" and, everything is a "service".
- No
heroku run rails cfrom my terminal. - Sometimes you use
render.yamlI guess. - Dashboard is barebones, but who cares I am barely using it after setup.
- Daily cost breakdown was neat.
- Slack notifications were handy.
- Scale services up, not down.
- Basic metrics per service is good enough for now.
- Use the LogDNA add-on.
- yay http/2 support!
I spent about an hour getting everything running đź’Ż; including external DNS configurations. For the most part I followed Render's docs and went the manual setup direction. I went the manual route so I could see everything stand up on its own.
If I remembered everything, this is how I got it up and running...
1. Static site
Cost: $0/month up until 100GB, then $0.10/GB.
Easy to setup. Here's my setup: I have a separate rails repo for the static site and use Bridgetown to generate it. Setup is easy and I followed step one and two of the Jekyll setup docs. I'm sure you can figure it out for whatever static site generator you are using; they also have docs for a few others. Here's the steps I did to get it running:
- Link to its GitHub repository.
- Build command is
yarn deploy. - Publish directory was
./output - Point my DNS to it.
Speed? Here's my unscientific thoughts on speed: It's now quite a bit faster than my free Netlify site was.
Neat to have them all on platform too.
2. health-check gem
I used the health-check rubygem to ensure the Rails app and its services were up and running correctly. It was handy to me and will be a good uptime / health check later in the future.
This ruby gem is not a requirement by any means. Maybe you already know about it or have something setup. Another bonus, the Rails app service on Render can have a "Health Check" endpoint. Neat.
3. Redis
Cost: $7/month Starter Plan 512MB with a shared CPU.
I used the “Deploy to Render” option here; pretty straight forward.
Cool that redis isolated to your environment and not publicly available. The redis service has basic metrics on RAM, CPU usage in the dashboard. Hopefully this is enough redis for my needs. I know I can always run another server as well.
Keep the redis URL handy for your Rails app. It'll be something like: redis://redis-whateverthenameis:10000
FYI: They have plans on the roadmap for a managed Redis more like Heroku I guess..
4. Create Database
Cost: Standard $20/month (1GB RAM, 1 CPU, 16GB SSD)
I went with the next up database plan for my app. There is a perfectly fine $7/month plan that I could have used and upgraded from, but I wanted to start here.
PostgreSQL was also “Click to Deploy”. Just pick the size of server. Remember you can size up, but no downsizing on Render. The basic db needs are covered: Nightly backups and basic metrics.
What you name the Database Service is what the database will be created under and the prefix of the username will be.
They are Postgresql version 11 and I noticed their roadmap indicates version 12 coming soon. This isn't a problem for me.
NOTE: The DATABASE_URL was automagically setup when I created the rails app in step 6. I did move that to a shared environment so the worker could access it; which I setup next.
5. Create your Environment Group
Perhaps doing this before my Redis step is smart. However, I didn't do this until after the database setup and I'm just walking through the steps I did best I can remember.
A environment group allows you to share environment variables and secret files across your Rails app and its workers. I have DATABASE_URL, RAILS_MASTER_KEY, SECRET_KEY_BASE, REDIS_URL etc in there. I only have one shared environment and its called “production”.
You don't need an Environment Group. It is handy to share the environment variables between the worker and web service though.
6. Rails Application
Plan: Starter+ $15/month
The Deploy Rails documentation was full of stuff for creating an app. Skip past all that to the "Go Production Ready".
I did all the app changes from the doc. I now have a render.yml and a bin/build-render.sh and the changes to puma.rb in my project and all of that was from the docs.
The deployment failed a few times until I had all my environment variables setup. I forgot a few, oops.
Be sure to linked to your configured Shared Environment if you have it.
Once it deployed, I set configured the custom domain to it. When you do that and the DNS is verified it'll create and manage your SSL certificate.
7. Background worker service (Sidekiq)
Plan: Starter+ $15/month
In Heroku you'd have a "Worker Dyno". Here you have a Worker Service. I over simplify a worker service to be a “web service” that is not publicly available. Its linked to the same repo, deploys at the same time but no public address and the start command is different. I set the start command to bundle exec sidekiq -e production; from the old Procfile.
Be sure to linked to your configured Shared Environment if you have it..
8. 🤞🏻
Now when I look at the dashboard I have a database, a web service, a static site, a redis service and a worker service.
Hopefully I didn't forget anything and this was helpful for anyone with a Rails app wanting to get up and running on Render.
If you are looking for a Render vs Heroku comparison there are a ton available. Here is Render's Render vs Heroku comparison. However, it was hard for me to not compare the cost savings from Heroku. Before I was on a pretty typical “SaaS starter package” at $150/monthly. There are obvious differences with Render, but I'm pretty pumped that I'm now just roughly $57/month. Where Render lacks in bells and whistles, it makes up in cost savings, a great platform and the team hustle (all very active on Twitter especially the founder and elsewhere on the internet and in their forums).
Heroku might be expensive but its very truth worthy. I'm hoping Render earns the same trust over time. They sure seem to be earning many others. While they host host my app and static site, I'm hoping they'll earn mine.
Latest comments (4)
Heroku is awesome, but costs are too high when the app grows. I'll probably give a try to render. Did you tested speed of static site on github pages VS render? Just curious about results (not opinions).
I was not using GitHub pages at the time to do that comparison. I am still pleased with the speed of the static site hosted on Render.
Thank you for the detailed review. I'm glad we're able to save you some money, and you'll see more bells and whistles soon!
This comment is a reason why I will try render. Having admins active on this kind of social media is what we need: humans for humans, and humans for machines - I am tired of stupid bots 'how can I help you'