I recently gave Render a go as a Heroku alternative. My initial results have been positive.

In this post, I outline what, as a designer, I’m looking for in a hosting service, and I step through how I deployed a python and node project to Render.

tl;dr

Render seems like a good bet.

Meets my prototyping needs.

Enough free tier features.

Deploys from GitHub repos.

Deploying a python AND node prototype was easy – all environments come with node, so you don’t need to worry about multi-build packs or anything like that.

Repeatable process: the steps I followed and the build command you need.

Heroku has been home to my prototypes for as long as I can remember. But that all changed with their recent announcement.

I do a lot of prototyping, and I need to get these prototypes in front of people. That means I need to put them online somewhere. I need to be able to send people URLs so that they can see and interact with them.

I’m not technically savvy enough to manage this all myself. I can’t manage a server of my own. I don’t know how to do that.

So I need “simple hosting” as a service.

Heroku has been the answer to that but what now?

Pay for Heroku

One answer is to pay for Heroku. 

That is an option. However, the prototypes I make are usually short-lived, temporary things intended to test ideas quickly. They don’t warrant a full-blown hosting offering, and I often make them in the early stages of projects before we’ve got sign-off from the organisation for hosting. In this situation, having to pause stops the momentum, therefore using a free service is a sensible stop-gap whilst we wait for sign-off.

Plus, when sign-off arrives, that usually means buying some paid-for Heroku. Over the years that has been to the tune of £1000s. This is why I struggle to understand Heroku’s decision-making. The free tier looked like a sensible business strategy, it was the on-ramp for customers. Get them to use the service; then they’ll convert to paying customers.

So, I’d argue there is still space for a free hosting offering. It is part of the mental model makers of digital products and services have – thanks to Heroku!

I’d also argue getting sign-off is easier when there is a prototype to point at. Let us do that, and I’m confident it’ll lead to more paying customers.

What to use instead of Heroku?

Answering this feels a touch beyond my designer-who-can-code-a-bit skills, but the 28th of November is fast approaching.

Thankfully, there are a lot of services positioning themselves as the Heroku replacement. 

For example, if you search for “Heroku alternatives” you might get this list of 5 alternatives.

Or, if you search for “free web hosting” you might get this bigger list of free web hosting services for developers.

And, if you search for “hosting for your python prototypes” you might get this list of hosting services that cater to python users.

So the good news is there are a lot of options.

But, if I’m being honest, most of what they offer goes straight over my head.

As a designer, it is scary picking a new hosting platform after all this time. Knowing what to look for and how to assess the options is hard.

I’d love someone to tell me where I should put my prototypes. And give me step-by-step instructions explaining how I do that. 

I had that with Heroku.

“Are you building a website? Ok, here is how you put it on Heroku.”

“Completed this tutorial? Great, now it’s time to put it on Heroku.”

All that has changed now.

Start with what you need

I started with a list of what I need. Or at least, what I think I need.

  • A place to host prototypes – I build things I want users to see and use.
  • There needs to be a server-side element – I build prototypes with some server-side functionality, I need more than a host for static-sites.
  • The platform needs to handle python projects – I create a lot of prototypes in python and flask but hosting for python doesn’t seem to be as common as I’d expect.
  • Easy deployment – a single command or 2 would be fine, but auto-deploying from Github would be better.
  • Multi-language projects. Quite often the application part of a prototype is written in python and the frontend assets in Node (so that sass and js is ‘compiled’). So, I need a platform where a project environment can have both. Heroku allows multiple buildpacks so I need whatever the equivalent to that is.
  • Environment variables – I regularly used them on Heroku to add things like basic auth to a prototype.
  • Storage or a database – this is more of a nice to have, but I will probably need it at some point

Trying out Render

I decided to give Render a go.

Why? It was listed on most of the lists of Heroku alternatives (including the 3 above), I saw lots of people mentioning it on Twitter, and a quick scan of the docs made it look easy enough to get going. It felt like a good place to start.

And, they have a Heroku to Render migration tool. That feels like it will be key!

Oh, and they have a free tier I think I can understand.

The free tier seems to allow unlimited prototypes (web services) with a usage limit of 750 hours of the prototypes being up and running (run-time hours) and 400 hours of building the prototypes (build-time hours). Unless you have a huge static site, like 1000s of pages, which regularly rebuilds then 400 hours should be plenty.

A basic flask app

I started with a very basic python (flask) app.

Render has an easy-to-follow guide and example repo you can use. However, I wanted to try it out with a project that mirrors the structure of the prototypes I create. I used my FlaskStarter project (if anyone wants to give it a go, feel free to fork and use that repo).

Once you have picked a project follow these steps.

Create a new Web Service

  1. Go to your Render dashboard (you’ll need an account)
  2. Click on New + button
  3. Choose Web Service
  4. Choose a repo from GitHub. The first time you do this, you might want to connect your GitHub account. This will make it easier to pick your repos to deploy. The option to do this is in the sidebar on the right.

Configure it

  1. Give it a name
  2. Ignore root directory
  3. Leave the environment set to Python 3
  4. Pick a region if you want (I used Frankfurt (EU Central))
  5. Set the branch. I left it as ‘main’ – the default branch

Set the Build and Start commands

  1. Leave the build command. This installs all the python packages your project needs.
  2. Set the Start command. For the FlaskStarter project I set it to gunicorn -b 0.0.0.0:$PORT application.wsgi:app – because that’s what I had in the Procfile used by Heroku

Finish up

  1. Leave it on the Free plan 
  2. Click on Create Web Service

That’s it. Now it will deploy.

It will take a few minutes to deploy. The deployment will be quite slow, but you can always pay to speed things up.

Once it has finished, you can visit the prototype.

A link will appear on the dashboard page. It will be 

https:// + the name of your prototype + onrender.com
The dashboard section for a deployed Web Service on Render

The first time I deployed the prototype and visited it I got an error page. It worked after about a minute of hitting refresh. I’m not sure what happened when I first visited the URL, but maybe I was too eager and tried to view it before it was ready. One to keep an eye on.

Success.

A screenshot of a white page with the text "Hello World Colm" on it. It is shown in a browser at the url my-flask.onrender.com
An exciting prototype running on Render

Using the migration script

Next, I wanted to get something more complex working.

I picked one of my existing prototypes which uses both python and node.

I couldn’t find anything in the documentation about projects with multiple languages. So I thought I give the Heroku migration plugin a go.

The instructions in the migration guide are easy to follow – I ignored the ones that didn’t apply to my prototype.

It worked.

The deployment took a lot longer. I’m assuming that’s because it uses docker.

I got the same error page at first but, again, after a minute or so the prototype page took its place.

Using the migration tool was great for moving an existing prototype. But, it didn’t help me understand how to create a new python and node project. I need to do this for new prototypes.

I looked at the 3 files produced by the migration tool, but it didn’t help.

I was hoping I could look in the docker file and see what was going on, but it was completely unfamiliar to me.

It’s great I got my prototype working, but it felt like overkill using docker.

There had to be a simpler way.

Node is everywhere

Finally, I found a forum post that mentioned buildpacks.

Buildpacks = my Heroku reference for saying what languages you need.

The post confirms buildpacks are not a thing in Render. But, it also says “Node is available as part of the build and deploy of all Native Environments.” Jackpot.

To confirm, the Native Environment documentation page includes node on the list of available tools – as well as other useful things like make.

I used the steps I listed above to deploy my existing python and node prototype as a single Web Service.

The build command is the only bit you need to do differently.

The command needs to install python and node packages, instead of only python packages. Luckily it accepts a ; separated list of commands.

You can put

pip install -r requirements.txt; npm install

In the future, I’ll use a single make init command. This will mean I won’t have to worry about updating the Render build command if the install commands change. But for now, this does the trick and installs python and node packages.

And that’s it.

I have a prototype, written in python and node, up and running on Render.com. It only takes a few minutes to set up, and the steps are repeatable. 🔥🔥🔥

There are other Heroku alternatives out there, and I’ll try some eventually, but for now, I can breathe a sigh of relief.

I hope this run-through helps if you’ve been wondering what to use to host your prototypes instead of Heroku.

I’d love to know what you think about Render or other Heroku alternatives. Please let me know in the comments below.