Free Tier Apps and Web Application Platform Alternatives

It’s the end of an era in the cloud. Heroku, the cloud Platform as a Service launched in 2007, has announced it’s ending its free tier of applications by November. The decision leaves only a few months for users to transition their apps (or add a credit card) before their projects are shut down. Some folks complain that doesn’t leave much time to find a new home. But if you pushed your great app to Heroku during its golden age 10 years ago … what was stopping you from making it permanent?

What is Heroku?

If you’re unfamiliar, Heroku put itself on the map when it introduced a new type of web application platform, using virtual containers called dynos to run applications. At first, Heroku supported only Ruby, helping to propel the usage of Ruby and the Rails framework in many developer circles. Later, they added support for other runtimes, including Node, PHP, Python and others. Heroku and its notion of “dynos” emerged well before the era of containers and Docker, which came in 2013.

The arrival of Heroku introduced some intriguing new patterns — and lingo — in web development. Apps ran on virtual containers called “dynos”, using one of a few server architecture options. Each app was configured via a buildpack for a specific programming languages, which could include downloading dependencies and running other set-up tasks. The end result was a slug — something akin to a container image — that could be deployed to a server, scaled up, or turned off entirely.

Much of this remains the same today, even as Heroku has expanded its offering in the past decade. The company was acquired by Salesforce in 2010, prompting concern from some about whether it’s become stagnant as other cloud platforms have come on the scene.

So What’s Next?

Heroku isn’t going away — just its free tier. If it works well for you, you should continue using it. And start paying for it!

A wide variety of other platforms have emerged in recent years to host applications like this. The big platforms like Azure, GCP and AWS offer a variety of serverless options that may serve the needs of web apps like this. Other providers, like Render.com, Fly.io and Digital Ocean also are competing for the small- to mid-size market, with tools similar to Heroku.

The big division between these platforms is how applications are built: via build script or via container image. For portability, the best choice is a container image, as it can be run easily on local machines or hosted providers. The buildpack model has gained popularity, thanks to Heroku and others, and some of this effort has been spun off into Cloud Native Buildpacks. You can certainly grab tools to experiment with creating OCI images like these, but in my experience, this is less common than doing the same with Docker.

Another difference is how the application is built. With a Docker-style image, you control the build process, using tools on a local machine or a separate CI/CD pipeline, like Github actions. The PaaS will deploy your image without running or re-running that build process. On the other hand, applications using buildpacks will always require a build step on the PaaS after making a code update, for example.

How long does a build or deploy really take? Well, that depends on the platform. Obviously, a build that requires pulling a lot of dependencies over the internet will take some time. You often don’t have firm guarantees about networking speed on a PaaS. But you may have more control — or at least visibility — if you manage that process yourself. In any case, PaaS solutions will have their own tradeoffs in the build and deploy process. Some may build slower, or deploy quickly.

Choices

Let’s review a few contenders in the free-tier space. A totally incomplete list, yes! But this is a good snapshot of what’s out there.

• Render.com
• Fly.io
• Cloud Run on Google Cloud Platform

Some things to focus on:

• cold starts
• how is billing calculated (uptime in minutes or seconds, network traffic, cpu)

Render.com

The most obvious substitute for Heroku may be Render. They have used much of their marketing and technology comparison documentation to present the platform as a more modern version of Heroku. Similar to Heroku, Render runs apps using either a build manifest or a container image.

Render’s free tier is similar to Heroku as well. An app is “spun down” after 15 minutes of activity, and any new request can see a “delay of up to 30 seconds” when trying to re-activate the app. Each account is allowed to host multiple free apps at once. But Render will shut them off if you run up to 750 hours in a month, across all free services.

• cold starts? yes
• billing? time based

Fly.io

Another vendor biting at the heels of Heroku is Fly.io, whose documentation makes reference to transitioning away from Heroku. Firecracker VMs are the backbone of their web services. And as a developer, you can supply an app with a specified buildpack, or use a container image.

(Since the Heroku announcement, Fly.io has removed the “trial plan” from its pricing page, likely in an effort to emphasize that its pricing is permanent and not offered for a short-time to new accounts.)

Billing isn’t based on compute time as with Heroku and Render. When an app is deployed, it’s available 24/7. No cold starts. But there is a limit on cpu count and a cap of 160GB on outbound data transfer. For some apps, managing that network ceiling may be difficult.

• cold starts? no
• billing? outbound network and cpu-count

Cloud Run on Google Cloud Platform

Another option is to fully embrace the serverless pattern and use Cloud Run. As with other platforms, Cloud Run accepts both Docker image manifests and OCI image formats to run its apps.

Under the hood, GCP is running something like Knative, which is a project for managing and running Kubernetes. That won’t mean much to the average application, but the serverless architecture will make a difference.

Pricing is based on compute per millisecond (before rounding to whole seconds), and total requests. For any account, “free tier usage” operates more like a threshold for all account activity before billing is triggered.

The free tier usage is aggregated across projects by billing account and resets every month; you are billed only for usage past the free tier. The free tier is applied as a spending based discount using Tier 1 pricing.

• cold starts? yes
• billing? number of requests and cpu-per-second

Other Considerations

One thing I don’t address here is build and deployment time on each platform. I think it’s safe to assume they are all really fast, well under 30 seconds. If you have to deploy a lot and keep your services running, that’s something to evaluate.

Each of these platforms (and others) offer other benefits and tradeoffs, for sure:

• database offerings
• TLS certificates
• logging and debugging tools
• integration with third-party services

Going Beyond Free

One vendor I didn’t include above is Digital Ocean. That’s where I host my personal projects these days. I really like their app platform, virtual machines and static-site hosting. I find the console really easy to use, their Terraform provider is solid, and the billing makes sense to me.

What they don’t have is a free tier. Instead, the platform offers credits to new accounts (similar to AWS, GCP and Azure) which expire after a certain time.

And what’s wrong with that? If you have a personal or hobby project that is worth sticking around for more than a couple months, shouldn’t you expect to pay for it?

It’s a safe bet that Heroku’s decision to end free apps will result in a number of old projects going offline for good. The effort to migrate will be too much, or … the login credentials are nowhere to be found.

For some, it will be sad to say goodbye and lose those relics of history. But time moves forward, and nowhere is the pace of change more relentless than in technology. Looking ahead, we may have to get more accustomed to the idea that servers in the cloud aren’t free.