Heroku’s attempt to scare away users and its impact on my Heroku-Fanboy position

Anyone who may have read my past posts on this blog or knows my personal-IT life is most certainly aware of my preference to host personal and pre-MVP projects on Heroku – a formerly great choice for hosting your projects for free.

With Heroku’s most recent decision to drastically change their support for small projects, this has also drastically changed, leaving me disappointed and even in a condition near to mad.

In this article, I will explain what I love so much with Heroku, why it is was my platform of choice for most of my personal projects, what has changed on November 28, 2022, what are my thoughts about this, and what it means for my existing and future projects.

The past – what is it that made Heroku a great choice for projects and teams of every size

I signed up for a personal account with Heroku in April 2018. That does not really make me an old stager with the service (which launched commercially with support for Ruby in April 2009 and evolved to support all its current features like Add-ons, PostgreSQL, and Python in September 2011) but during those 6 years and 5 months, I really started to read into the concepts and feature palette very carefully and wasted no time to start hosting my first personal projects with the platform.

I even started to motivate others to embrace the service, like in my (unfinished) series about “Create your own Telegram Bot with Django on Heroku“, which contains large parts (and even one full article about how to achieve the steps with Heroku, explicitly) about how to best use Herokus features to achieve what we need for the project.

Here’s what I liked about Heroku so much:

• The service is extremely well documented at https://devcenter.heroku.com/
• It supports a very wide range of development languages in very up-to-date versions.
• You can completely control everything using the great commandline client without ever have the need to login to the website (create projects, activate add-ons, publicate- and rollback versions, add/get/change/remove environment variables, create databases for it, …
• Very clear and fair pricing policy. You can always see which project consumes how many active dyno-hours (A dyno = a container executing code).
• Projects can start very basic and can scale to full blown and complex hosting – environments, without having to hire cloud architects doing it for you.
• With just a single commandline, you can start a so called “one-off dyno” and connect to it using SSH, which has the same environment started as all your active dynos to host the application, which allowed you to do maintenance tasks like running Django commands or doing filesystem analysis.
• What was introduced as a limitation to save costs and spare resources (and to encourage users to switch to paid resources too, most certainly), Heroku “pauses” free dynos which haven’t had any web traffic in a 30-minute period. They can still be reached fine, since a socket is kept open to receive any request which may come in while the dyno is sleeping, but it will be kept in queue for those few seconds (usually below 8 seconds) it takes to awake the service and handle the request. In reality, this had absolutely no negative impacts other than that the first request after a 30-minute period of inactivity took a few seconds longer to process. Subsequent requests were as fast as usual.
  Sleeping dynos were not even counted towards your free-dyno hours, which enabled me to host 3 active-yet-unfrequently used projects with under 30 active hours on average (~ 3 % the amount granted by Heroku’s free dyno hours of 1,000 hours per month).

For many of my personal projects, this sleeping-mechanism was pure gold – not only because it goes easy on my available free-dyno usage and did not cost any money, but also from an ecological perspective: Applications, which do not cause any computing activity, don’t consume power and thus, allow to lower power consumtion. If we had this concept more often in today’s IT, I bet global power consumption can be cut quite much. Not all applications require 24/7 below 100ms response rates …

What changed on August 25, 2022?

Heroku introduced it’s “Next Chapter” in form of a global mailing, Blog entry and FAQ, which basically informs the public, that starting November 28, 2022, Heroku will retire “free Heroku Dynos, free Heroku Postgres and free Heroku Data for Redis®” (in other words: Any free option they offer):

A typical Salesforce – move, in my opinion …
Since Salesforce aquired Heroku back in December 2010 already with not too many bad changes towards monetarization-first, I had high hopes they recognize the value the service has to many small-budged projects and developers and focus on earning money with continuing to provide a great experience for mature hostings on their platform based on the great reputation they generated from those small-budged projects and individual developers, but once more, Salesforce failed this opportunity by falling back to uninspired, shortsighted free tier cancellation instead of just become a better experience for paying enterprise scaled applications.

My opinion on the backgrounds

This decision really hit me hard, to be honest.
I mean: It is not about that I am desperately searching for a “completely free yet professionally supported” platform without spending any dime or if I could not afford spending any money on hosting. The opposite is the case: I am spending close to 3 digit numbers of money every month on multiple hostings for everything between self-managed root servers, cloud resources and so on; even some Euros for Heroku’s services.
But at the same time, it is an important factor for many of my projects to have a place where I can have them to be available with a fixed and proven-to-be-working deployment chain at no costs, so I can work on them when I have time for them or when they turn more important for representation or demo-reasons towards a colleague or even customer without either investing hours to provide a working MVP – Hosting and deployment or paying months over months during inactive times for resources I don’t need.

A formerly completely free hosting with only one dyno, PostgreSQL as Database and Redis now is about to be charged with $31/month!! I don’t know either what kind of insane people do use free services for production loads or what rip-off provider small personal projects and private developers usually use to host their personal projects, but for $31 you can afford at least 3 small dedicated root servers or a whole cluster of many, many virtual servers running 24/7 and capable of running hundreds of low-footprint applications. How is that “… continue to provide low-cost solutions for compute and data resources …” Mr. Bob Wise?? In which world are you living to consider that being “low-cost”?
You guys at Salesforce must be breathing very strange air to consider a price of $31 per month for a single application in the lowest available tier “low-cost” …

All this now has been cancelled by Heroku – with a very short migration period of round about 3 months even. This is enough for me, personally, but luckily I’m also neither between two jobs, sick or on vacation. Also, only a very limited amount of my personal projects is affected.
And for what reason? This point triggers me the most, honestly. In the blog post it reads:

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

What is “fraud” and how can the service be “abused”?
Me as an individual: How could I possibly fraudulently missuse the service to Heroku’s drawback?

I could setup a phishing site with Heroku. Or I could use Heroku to host some kind of Botnet-Proxy-node written in any of the available languages. This, in the first place, is not any issue of Heroku, since Heroku’s resources are not negatively affected. In the worst case, they will receive an abuse notification and be asked to take down the fraud resource and provide account details to the feds.
This is neither more nor less a problem for Heroku than it is for any other hosting service compareable nor do I understand, why it should be such an immense burden for Heroku more than it is for other compareable services such as the 1-year-trial with AWS and 30-day-trials for Azure and most other cloud services nowadays.

Based on their say, Heroku employs “300+” people for the service, plus more than 36,000 as of 2018 over at Salesforce. But they still can’t organize this standard procedure of shuting down or prevent fraudolent subscriptions in the first place.
The guys over at Anaconda Inc. seem to have round about 260 employees as of August 2022 and yet they seem to not struggle too much from fraudolent accounts management at their aquired service PythonAnywhere – see their recent Heroku free services shutdown inspired blog post on the topic.
Yes, I know that PythonAnywhere is by far smaller than Heroku is, but I guess the Head-Count-Efforts to operate a service and deal with fraudolent subscriptions will be equal if not higher on PythonAnywhere side. Their blog post also points out how little impacting they limit the features of the free subscriptions and how and why they implement a “still alive” – Ping mechanism to have users tell them that their accounts are still active, regularly. It’s really worth reading in my opinion.

And – how could someone “abuse” a free service? If the offer is “do and host whatever you want for up to 1,000 computing/dyno hours for free” – how to “abuse” that if there is no additional limitation? Even if someone would write a management engine, which registers thousands of free accounts and link them together to some big super-cluster to use more resources for free than granted that way: Why is “shut the whole offer down for everyone” the best technical answer a company can come up with in 2022? If this really is a valid thing that is happening, how poor must the Salesforce staff’s skills be to not finding a better solution to this than to shutdown the service for everyone?

My personal outcome with all this

For me, Heroku always came with special commitments required. To really make good use of Heroku, you had to invest some time on adopting the unique tools and workflows, adopt some of their design decisions and had to invest some time learning clients and techniques, you could utilize nowhere else. Learning the Heroku cli and deployment cycles always was a one-way-road, since it was clear from the start that if you (or your company) will ever switch the hosting, you can forget everything you learned for Heroku.
The other way round, you could utilize nearly none of the common enterprise standard tools like Ansible, Terraform, Chef, K8s, … to integrate that into Heroku.
That way, the commitment to learn this and use Heroku always was a risky one: You risked to invest your time on something that becomes obsolete from one day on the other.

So far, this was not too bad: You got a lot back from Herokus straight integrations and well designed platform. Even if your company’s decision to drop Heroku was made, you still could use the free tier for your own personal projects, which, if you were lucky, grew successfull enough, to just upgrade your Heroku accounts and you had your back covered.

In my opinion, Heroku brought all this down to obscurity by removing the support for free tiers, especially by the way they did it and by their rationale for the decision, since they now expect that new adopters invest $31/month just to be allowed to learn a service, which seems overpriced and can nowehere else be put to some use. “Vendor Lock-in as a Service” …

As a personal result, I will migrate all my projects away from Heroku in the next couple of days (free and paid ones!) and after that, cancel my account with Heroku. This decision marks the end of my personal Heroku hosting area for me and I will look for hosting solutions that offer more user-faced solutions than what Salesforce seems to be capable of.