Thoughts on Render.com

Yesterday I tried Render.com on a brother’s recommendation. It blew my mind. I’ll share a few thoughts as a day-old user, and give the context later.

What I love about Render.com

No CLI needed. While in conversation with him about my experience, I joked that “no service deserved to take up extra resources on my laptop just so I could try it out”. That sort of illustrates the point: the barrier to first-use is shockingly low. Coming from Firebase Hosting, it felt like a breath of fresh air: just show us where the code is and we’ll host your site.

Figuring out how to host a Jekyll site just illustrates how great this approach is. Again, show us where the code is, tell us your build command and where the built site will be, and we’ll host it. No CLI needed.

The simplicity is breath-taking after spending a week dealing with the opacity of Firebase Hosting, and coming from a life-time of Heroku use and advocacy.

Hosting a static site, and linking it to a custom domain should be easy. I get comfort knowing that the folks at Render.com gave a lot of thought to this use-case. Getting a single webpage publicly hosted should be as hassle-free as it possibly can, and I love how their product is intentional about this.

Just as GitHub Pages is attractive for hosting project sites (and that is a feature I greatly applauded and have used a lot since it launched), an app host will win folks like me over with this hook. It’s the lowest of low hanging fruit, and generous terms on static site hosting is one hell of a gateway drug.

There is an openness to Render.com that makes them attractive to the hobbyist developer. Their dashboard doesn’t look as polished as their major competition. This unintentional aesthetic sits at the foundation of the intimacy of the product: Render.com feels like a bunch of people who get you, and want to build a service that’s great for you; not in a corporate-speak sort of way, where “you” is one row in a large matrix of intersecting datapoints computed from massive datasets about what an ideal customer looks like. The folks at Render.com know who they’re building for. At least that’s what it looks like, and maybe that’s what matters.

This will doubtless change as it matures, raises, and runs the lifecycle of many successful businesses, but right now Render.com feels like home.

The company, it seems, understands this. Since Heroku, there’s been a space on the Internet for a service that means what Heroku meant to thousands of developers a decade ago. They have taken up that space in my point of view, and I expect this reputation to last a while.

This definitely means success in the short term, and I’m rooting for them. It also means treading the same waters as Heroku did, and (I hope) looking for different answers; answers that will keep their service profitable and popular at an even larger scale.

I don’t think it’ll be easy, and I’m ready for the bumps ahead, but while it lasts, you can guess who I’ll be shilling for.

Back Story

A bit of background if you haven’t copy-pasted the URL already; Render is an app hosting service, like Heroku, but newer, cheaper, easier and, you get the idea: generally better.

I first heard of it on HackerNews in the wake of Heroku’s announcement that is was done with freeloaders. That announcement (may have) ruined Heroku for paying users who also benefitted from its generous free-tier. I don’t know if (or how much) the company has walked back on the initial decision as published, so the aftermath of the demise of all that goodness is left for your further research.

My decision to use Render.com to host a static site came after I had been left in Firebase Hosting limbo for nearly seven days. Firebase is a great service when it works as documented. I think of it as a happy-path-optimised service. It’s great when your problem has been engineered-for; it sucks when your situation is a little more nuanced.

I had previously linked my domain name to my hosting site, and everything worked as expected. Happy path. A few days later, seven days before the horror show, I transferred that domain name from its original host to my Namecheap account. After the transfer was completed, I changed my A records on Namecheap to reflect what Firebase expected. This is where everything went south.

I noticed after a few days that my site was no longer available at my domain name, and my custom domain settings “needed set up”. However, the setup wizard was broken, and it wouldn’t give me TXT records to update on Namecheap so it can verify my ownership.

I did a little stupid fudging around and ended up in a worse place with Firebase, when my domain name could no longer be added to my site because “it may be in use by another Firebase project”. As far as I can tell, Firebase still thinks that domain name is still in use.

Enter Render.com. I (finally) created an account to try it out, since I was going to use it anyway for a simple web service I’ve been planning for a few weeks now. I created an account, Googled “how to host a static site on Render.com”, and saw what it entailed:

Create a new “Static Site” on the Render.com dashboard, give it permission to access your repo, and…that’s it. Oh. My. God.

If you enjoyed this, let me know.