foo::bar

Blogs and RSS are cooler than ever

Two alternatives to Heroku free hosting tier

Starting November 28, 2022, we plan to stop offering free product plans and plan to start shutting down free dynos and data services.

Obviously running a free tier brings customer, but also requires a lot of effort without immediate financial compensation.

Our product, engineering, and security teams are spending an extraordinary amount of effort to manage fraud and abuse of the Heroku free product plans.

As an IT professional, the obvious choice is to stay on Heroku and opt for a paid plan, even for a hobby project or a proof of concept. At $7/mo, the yearly hosting costs about 2 hours of your time in Western countries (even if you don’t earn that much, you probably cost that much to your employer). 2 hours is not a lot of time to evaluate and roll out your application to another platform. Plus you get always-on instance (the free one sleeps after 30 minutes), custom domain and I assume some customer support for the price.

But free (as in free beverage) is always enticing. We can’t help but taking a price change as an invitation to evaluate alternatives to a product. It is healthy. And once the exercise is performed, and the test application is deployed, the bulk of the job is done so you might as well make the switch to another free hosting service if it is deemed satisfactory.

So let’s try to find a new home for a FastAPI (Python 3.10) application with server-side rendering. No database, no Redis.

A woman whispers Heroku to a man’s ear

AWS or GCP

This is not the abstraction level I am looking for. These are fantastic platforms to tweak and make a Kubernetes cluster happy, but at the cost of serious involvement. Maybe you routinely administer one or several clusters, and have all tools ready, including recipes for infrastructure as a service. In that case, why not. Me, I am looking for something more simple, with as little administration as possible.

AWS and GCP may not even be (much) cheaper than a paid Heroku plan. Unless I turn my app into Functions / Lambdas…​ sacrificing convenience.

render.com

What went well ✔

  • Sign up and GitHub connection

What went wrong 𐄂

  • Announces startup times up to 30 seconds

  • Slow build time

  • Inconsistent app status

  • Failure to deploy without error in log

  • A few annoying UI pitfalls

I understand, you don’t want to commit to a strict SLA, specially for a free plan. But 30 seconds boot time is scary, even for a pet project. I would assume this is a worst case scenario, and that startup time is typically much shorter. But you put the bar too low. Now all I have in mind is a slow startup time, be it 30 seconds or less. Piece of advise: in that case, better not to mention anything at all rather than rock-bottom figures.

The build process was slow, way more than one minute for 4 endpoints. The resulting application status was inconsistent with the logs: deploying altough the server was up and running according to the logs. Then failed deployment with no error…​ Not much I can do at this stage.

Since the very same application deploys to heroku, I assume the error is with render.com 🤷

Oh, minor gripe, the web UI is not polished, and I managed to miss an unexpected save button twice, leaving me with unsaved settings.

railway.app

What went well ✔

  • Sign up and GitHub connection

  • Fast build time

  • Reasonably fast startup time (better than Heroku)

  • Multiple environments supported (e.g. testing, production…​)

  • Custom domain name!

What went wrong 𐄂

  • Server-side scheme incorrect with url_for

Simple, efficient. Not as polished as Heroku but nothing wrong in the UX. The url_for template directive incorrectly lead to http instead of https:

<link href="{{ url_for('static', path='/style.css') }}" rel="stylesheet">

yielded an error

Blocked loading mixed active content "http://web-production-***.up.railway.app/static/style.css"

That was working fine on Heroku. I made sure X-FORWARD-PROTO was set to https but no joy. Looks like a railway.app configuration issue. Not big deal, I simply stopped using url_for.

Bonus

EDIT — Not tested

  • cyclic.sh — By "full stack app", they mean "JS app" but fail to mention it on their homepage 🙄

  • fly.io — Looks very comprehensive and well documented. Supports Elixir. Via @xavierdefrang

And the winner is

The hobby private app now happily lives on railway.app.

Happy hacking