> What products are impacted by the removal of free plans?
>
> `free` dynos, `hobby-dev` Heroku Postgres, and `hobby-dev` Heroku Data for Redis plans.
>
> What happens if I take no action on my free apps or databases or do not upgrade to a paid plan?
>
> If you take no action by November 28, 2022:
>
> - `free` dynos will be converted to `eco` dynos scaled down to 0. You must subscribe to the Eco dyno hours plan or upgrade to another paid plan before you can scale them up again. Any Scheduler jobs that used free dynos will fail until they are reconfigured to use another dyno type.
> - For non-Enterprise users, `hobby-dev` databases will be deleted in accordance with the Heroku Documentation starting November 28, 2022.
> - For Enterprise users, `hobby-dev` databases that belong to an Enterprise Account or Team will be converted to `mini`. There will be no immediate change in cost to your Heroku Enterprise invoices if an app is upgraded from a free tier resource to a paid tier resource. Any changes to Heroku Enterprise pricing would require a contract update to take effect. If you have any concerns about your contract pricing, contact your account executive.
> - `hobby-dev` databases that belong to personal accounts will be deleted, and `free dynos` will be converted to `eco` dynos scaled down to 0, even if that user also belongs to an Enterprise Team. These users must upgrade to paid resources before November 28, 2022.
ref: https://help.heroku.com/RSBRUH58/removal-of-heroku-free-product-plans-faq
I'm personally moving my projects to a self-hosted dokku cluster, but I've heard good things about fly and render too.
So the fun fact is this: they were running entirely on free Heroku dynos. This year they successfully transferred to AWS, but they got to a fairly big scale while running entirely on free Heroku dynos. I'm still kind of amazed by that.
I’ve read so many of these stories now that I understand why Heroku is phasing out the free tier.
It’s kind of fascinating to see how some engineers see free tier limits as an optimization target. I wonder how many engineering hours across the industry went into arbitrarily keeping services small enough to fit in the free tier.
Why is that wrong? If everyone optimized their services and applications like it used to be in the past, will substantially bring down compute and memory requirements and reduce overall bloat.
To me, those stories seem like good arguments for reducing the usage limits of the free tier, but not getting rid of it entirely.
Heroku could have gone back to that i suppose, instead of getting rid of free dynos entirely, but they didn't.
Still... I think you could basically only run one free dyno per account 24/7. I am curious if they somehow fit their entire production in one free dyno, or were somehow splitting things between multiple accounts, or what.
I am using Coolify (https://coolify.io), an open source self-hosted PaaS which is a relatively newer kid on the block compared to Dokku and CapRover. I tried both of these and I just didn't like how they were, always had some problem or another.
In contrast, Coolify has a great GUI that abstracts away the most common things about PaaS hosting, like connecting to GitHub automatically for git push deploys, SSL certificates, reverse proxying and custom domain support, and best of all, having support for Heroku style buildpacks as well as Dockerfiles. I've been quite happy with it, the creator has a Discord and responds to issues very quickly.
With regards to non-self-hosted options, I did try out Render, Fly.io and Railway but I found that their free servers were too anemic. I was compiling a Rust backend and it simply could not compile on their free servers. On Hetzner, for 5 bucks I could get a 2 AMD vCPU and 2 GB RAM machine that was sufficient to compile my Rust apps in a way that the non-self-hosted ones were not. I have a JS frontend app that works fine though but I wanted to keep everything under the same VPS, plus I can run other types of self-hosted services on it too, like Plausible analytics and a Ghost blog. I'm not sure if those are allowed on non-self-hosted options.
All in all, it costs me 5 bucks a month, and I never have to worry about sudden upcharges for traffic à la AWS as in the very worst, my VPS goes down for a while. I'm now running about 20 different services on this 5 dollar box including databases and applications as well as other services, works just fine.
I'm fearing folks could abuse Fly and they could start to let it go..
Fly takes your credit card info up front so if you abuse it they can just charge you. Also people who give their credit card upfront are less likely to abuse their plans.
By the way, one hack to not upgrading your app? Move your DBs to a single shared instance on Amazon, and then point Heroku apps to that one instance. Meanwhile, in Heroku just remove the Postgres addon. As long as it doesn't see a free instance, it doesn't complain.
https://www.bleepingcomputer.com/news/security/massive-crypt...
If you don't want your project to sleep, you probably want a Basic dyno ($7/month) instead of an Eco dyno.
Am I missing something?
Edit: I meant to add a link to the pricing page.
https://devcenter.heroku.com/articles/upgrading-heroku-postg...
It seems like data migration should've been at least a prompt when you upgrade an add-on, but it isn't, at least not for me.
AFAIK sadly Heroku does not provide some other _free_ permanent redirect option for their *.herokuapp.com sub-domains without actually running a dyno there.
They are fraudulently trying to trick people in paying ~170 euro without any clear statement on what is their claim. Dont fall for it.
We're Charlie Brown running towards the football repeatedly. We need to learn a lesson here. "We're the good platform devs" branding doesn't mean a company will do the kind thing by their true believer users (post-acquisition, post-cash-flow-belt-tightening, post-IPO, etc)
There ought to be a platform on which new coders can build a free simple web app in a playground, and know it will be accessible in 20 years. If a company wants to use "free easy backends" as bait for capturing growing companies' future costs, devs should hold them to long-term persistence and at least an off-platform future migration path. See also Parse, Geocities, etc
Use some % of the money and put it in to an OSS migration path or a fund to pay their own future AWS bills, c'mon.
There is almost zero overlap with their main CRM product and PaaS, totally different stakeholders. Whats worse is that they served different segments. Enterprise buyers spending 6 digits on Salesforce are not going to host on Heroku. Hobbyists/indie projects are not going to have sales teams that even need a cheap CRM let alone SFDC. There's almost no cross sell potential.
Heroku probably turned into a black hole on their balance sheet. Post M&A Integration wise there are many accounts of Heroku first employees resisting the corporatisation of the organization, I believe all the founders eventually left a few years after.
It was ultimately probably a value destructive acquisition, left alone imagine what Heroku could have been. Thinking about this is pretty sad. The product is still after all these year almost like 'magic' vis a vis upcoming competitors (Render/Fly). Beyond its products, Heroku was THE gateway for students and learners to spin up an app almost immediately, helping them become professional developers
But maybe not? Maybe the customer base has been shrinking, especially major spend enterprises?
For whatever reason, it seems like salesforce decided to stop treating it as a growth business, and start treating it private equity-style, figure out how to minimize expenses to increase profit, period. But it is I think conceivable they'd try to do that with a profitable business? The end result will probably be shrinking and eventual dying of the business either way... but maybe they don't mind if they wring out maximum profit with minimum investment for 5-10 years (which began some years ago already) first.
I would be very interested to see a balance sheet, like how much revenue and how much profit for heroku specifically, over time. But that's known to nobody outside of salesforce so far as I know. Neither is how their staffing may or may not have changed over time.
We have seen heroku kind of stagnating, and maybe having more technical problems, which they handle without the professional polish we had previously expected, and now get rid of free tier -- and there have been a few pieces kind of saying this, but what I'm interested in is... why? What's happened?
I have seen various people speculate, including that it may have been doing quite fine well in the black as an independent unit, but salesforce has always wanted it to be more "synergistic" with their other business than it has been, and just wasn't interested in investing in it. But maybe it hasn't been that profitable? not sure anyone publicly really knows?
Heroku's warning emails are how I found out two things:
- That I'm still the administrative contact for a former employer's production environment.
- That my former employer is using a free tier for its public-facing web site.
Ethically, I should let the company know is web site is about to go offline. But it's a start-up run like a fiefdom and the founder tells all departing employees that if they contact anyone at the company, he'll sic the (imaginary) lawyers on them.
Heroku account: deleted.
For small scale projects Heroku seemed thousands of times easier to work with than GCP. I sometimes get lost in all the GCP menus and settings. It’s a lot.
I doubt Salesforce is struggling with cash not to let these projects stay online on a “read only” mode.
That way all of the people who missed the news about Heroku and first heard about it when sites they were using stopped working would have a fighting chance to recover their data before it vanished.
Even better: Salesforce could have actually invested resources in Heroku (instead of effectively feature-freezing it a few years ago) such that the thing where the free tier acts as a major funnel for attracting paying customers continued to work, as it had for most of the lifetime of the service.
heroku git:clone --a <app name>
The UX behind managing instances is delightfully pleasant where new instances are available faster than any other cloud provider we've used, within seconds of creating an instance you can immediately login with your configured SSH keys. Another nice feature is being able to "rescale" your instance to higher specs after a restart [3], so you can confidentially start with a small instance that just meets your current workload knowing that you can easily scale up your instances as your workload increases.
AWS RDS was the only critical service keeping us on AWS, a service we no longer need in our new Apps which we're building with SQLite thanks to the effortless replication in Litestream [4] that we're using to replicate to Cloudflare R2 - another great value alternative S3 alternative with $0 egress fees [5] where you can get even greater value & performance when hosting behind their free CDN.
[1] https://www.hetzner.com/cloud
[2] https://servicestack.net/blog/finding-best-us-value-cloud-pr...
[3] https://bizanosa.com/how-to-upgrade-resize-hetzner-cloud-ser...
If you want services like Redis on a semi-managed provider like Hetzner but don't want to write the bash scripts/Terraform/etc or hook up networking/TLS and run it yourself, Nimbus is for you.
[0]: https://nimbusws.com
A good example is Adobe products. Pre-cloud I would freely use PS/Lightroom off a CD, then got into the monthly plan for students, which turned into a full price plan after I graduated, and which sucked me into a year long contract for a certain plan.
Now I did this all willingly of course, and after 5 years I looked back and thought 'where did all that money go?' But to some degree it undermines my trust in my ability to gauge the actual value of subscription based services.
Serverless and edge functions: Deno, Vercel, Netlify, Cloudflare.
Databases: Planetscale, Supabase, Cockroach, Fauna, Upstash.
Services: Fly, Railway, Render.
https://mobile.twitter.com/Ak_Mittal/status/1567175784229650...
You can sign up to be on the waitlist for access here: https://fl0.com/contact?utm_campaign=hn
(Disclaimer: I work at Fl0.)
I kid.
Thanks for everything, Heroku.
In recent years, there was a significant amount of startups/bootstraped companies that tried to make application deployment easier, similar to Heroku. A lot of them were trying to get as much users as possible using a very generous offering. A lot of the times, this use-growth was fueled by a VC money, and the only metric that mattered was user/customer growth.
But then came the "cooling" at the private markets. VCs are looking not only at the user-growth, but also at the cash flow. A lot of the very generous offerings that were possible only thanks to the VC funding will eventually disappear.
I believe that what's currently happening with Heroku will happen to a lot of other Paas/BaaS startups. They will need to transform to a cash-flow positive business. Similarly to what Heroku is transforming to (a "cash cow": https://en.wikipedia.org/wiki/Cash_cow).
A lot of other PaaS providers will need to increase their prices to stay cash-flow positive. A portion of them will need to cancel or reduce the generousity of their free offereings.
The margin of these companies is usually possible thanks to 2 things: - the infrastructure resources they provide is slightly (10-100%) more expensive than the underlying infrastructure they run you workloads on - they use more cost efficient hardware (e.g. databases running on 3rd gen SSD disks) to run your workloads.
Since these companies are renting raw hardware, on which they run your workloads (and are not using cloud-provider-native services, such as RDS), they need to hire experienced operators able to run and manage those workloads in production. This (for obvious reasons) is not exactly easy, and requires a lot of experienced talent with operational experience.
Hiring those people is very hard, as these experts are not usually available on the market.
This leaves us with with the obvious problem:
Are the operators of the given PaaS provider really able to run your production workloads? Are they able to to withstand all the issues that may arise?
Don't get me wrong. There definitely are companies (the most succesful) able to hire very capable talent (such as https://supabase.io), but this definitely isn't the case for all of those PaaS providers.
And I believe that these companies will need to increase their prices (and be less lucrative for their customers) or changes their business model.
This is something that we at stacktape.com built our business case on. We took a different path. We just wanted to make the existing (AWS) offerings 2 orders of magnitue easier to use, so that any developer (withou Cloud or DevOps experience) can use them productively.
We're not running your workloads for you. We are just making AWS services (run by experienced operators) significantly easier to consume (97% less difficult, so that any developer can do the job). For that, we're charging 30%->20% of the AWS infrastructure costs managed by us premium. This also means that you are not restricted to our platform, but can easily extend your infrastructure by any AWS service (using AWS CloufFormation or AWS CDK).
AWS offers areasonably generous free tier, and Stacktape won't charge you for any resources withing the free tier.
We're launching our v2 soon (~1-2 weeks), and if the offering we have sounds interesting, we'll be very happy to hear your thoughts.