HN Explorer

Ask HN: Are you leaving Heroku?

88 points by seancoleman ↗ HN
It seems like Heroku has been dying on a vine. The platform is still incredible and unmatched in Developer Experience, but recent security incidents (along with a severely prolonged resolution), downtime, and (just yesterday) a DNS-related issue is making me reconsider and quite possibly will move some mission-critical apps to AWS.

Are you migrating away from Heroku? If so, which cloud provider are you using (AWS, Google Cloud, Azure, etc)? What's your stack and what service are you migrating to (ECS, Elastic Beanstalk, etc)?

113 comments

[ 3.1 ms ] story [ 198 ms ] thread
verdverm
You might also note there has been little to no feature development for Heroku in some time
bastawhiz
Not just that, trivial bugs aren't getting fixed. The charts showing response times, for instance, sometimes go crazy when you change the settings for time window or interval.
countspongebob
Any other seemingly trivial bugs that are frustrating you? Would love to get your list.
verdverm
Forget little bugs... the big picture is far more important. I cannot recommend anyone use this product given recent (years) inattention.

Since you work for Heroku / Salesforce, letting your users know if this is a dead product or not would be a good first step. If not dead, explain why there have been no updates and what is to be expected moving forward.

countspongebob
Heroku is very much alive. On your comment about what is to be expected.... stay tuned.

Given that, I also don't want to forget the little bugs, I believe they are important to a great user experience. I think this is true for any product, but especially true for Heroku.

verdverm
keeping your runtimes up to date, especially with security patches, is a good place to start
verdverm
https://news.ycombinator.com/item?id=32594533

Doesn't look well received, Heroku is a dead product for devs.

verdverm
@countspongebob, I hope you take HN's reaction back to your team & management. Not doing so, not replying, that will probably be the nail in the coffin from the HN crowd, which is highly influential in the industry.
bastawhiz
My dude, I spent many thousands of dollars on Heroku over many years. I've reported bugs to customer support and nothing changed or improved, for years. I appreciate you're reaching out, but that bridge is burnt. The trust is gone. I ran into a bit of trouble getting set up with Render and one of their PMs reached out directly to learn more. Heroku replied to virtually all of my customer support issues with messages gaslighting me that the problems were my fault or "Try debugging your application with New Relic".
appliku
3 years ago, I tried Heroku and was quite impressed by it. Although the price is prohibitive for a hobby project that needed resources but wasn't generating any revenue, I had to start seeking other options.

Ended up developing my own Heroku but focused on Django deployments.

Three years later, it works like a charm and has many happy folks who thank me for making it.

Meet Appliku: https://appliku.com

itake
My main issue is the free redis and cheap postgres instances they provide for my low-traffic app.
appliku
You can get built databases deployed with Appliku as well. No reason to go broke on a small side project
itake
on the same server? Heroku basically gives you 2 free vCPUs to run redis and postgres. If you run pg or redis on the same instance as the app server, then you're still down 2 vCPUs.
aethrae
redis and postgres sounds like you could just use render
itake
render pricing looks much more competitive. Thanks for the tip!
itake
After Heroku's outage, they decided to kill all of their free dynos, redis, and pg! ugh
Macha
I may have some bad news for you...

(Heroku are removing their free tier of everything)

eddof13
All of the companies I've worked for in the last few years who were Rails stack on Heroku have or were migrating to k8s deployments on the big three (AWS/GCP/Azure). For personal apps I'm looking at consolidating my stuff to Digital Ocean.
jokethrowaway
I've done that and now I kinda regret it, as there are cheaper alternatives and DO doesn't really offer much more than a VPS. I'm trying to switch to hetzner (but the 40$ per month on DO won't ruin me economically, so I keep postponing it)
HermanMartinus
I was pretty unhappy with the outage last night. All the user blogs for https://bearblog.dev went down for about an hour and a half (and I had so many emails to respond to this morning).

I'm looking to move Bear over to either a Digital Ocean droplet (I have the staging server running on one with SQlite and Litestream running, and believe it could actually scale well), or to Fly.io (to be seen).

rozenmd
Do you have a status page? (I'm biased as the founder, but) our customers at https://onlineornot.com report getting fewer support tickets during incidents as their users know to check status.example.com before asking support what happened.
ninjaa
gonna migrate to vercel and serverless infra like planetscale db

still on heroku for now though. it's really aged but held up very well for popular use cases at a not obnoxious price.

buf
Short answer: no.

Every year I try out new things (fly, render), but stick with heroku because I'd rather focus on building products and not devops.

I'm a solo dev making $700k a year on my projects. I'm happy to pay the extra cost for things to just work.

If there is a catastrophic issue though, I do have backups elsewhere that I will use.

nicoburns
Are the things you feel are missing from fly/render, or is it just a case of it not being worth switching an already set up project?
buf
I wish I could give you a concrete answer but it's been about 7 or 8 months since I last looked at alternatives. IIRC, it was something to do with Postgres restore support not being as good.
melony
Fly.io doesn't track Heroku buildpacks nor does it recommend buildpacks as a first class workflow. Buildpacks are very underdocumented. The official tutorial and guides pushes Docker as the "preferred" workflow. Docker is nice for environments like Rust/Go/when you have additional dependencies. For Ruby/Python/Node buildpacks are a lot easier. Your typical Heroku tutorial says "use cedar-XYZ pack for Python Z and everything will just work". The version of Heroku buildpacks tracked by fly is many years out of date (Heroku 18, https://fly.io/docs/reference/builders/). People use Heroku because they don't want to deal with DevOps or the differences between Ubuntu vs Debian vs Fedora for server side deployments. Docker is great for complex use cases but 80% of the time you just need to install dependencies and expose a port. Fly.io claims to have automated detection of environments but this isn't well documented at all. The docs doesn't explain when to use the automated detection and when it will fail.

In the entire fly.io documentation, there are only two mentions of buildpacks: https://fly.io/docs/reference/builders/ https://fly.io/blog/topic/buildpacks/

Fly.io hides behind clever engineering blog posts while pushing tremendous complexity on to the developer. While I appreciate the transparency and clever engineering hacks used in building Fly, the lack of a true managed database with a proper GUI and point in time backup and recovery makes it hard to consider Fly as a true Heroku alternative (the official Fly.io recommendation is to go to Crunchy Data for managed databases).

tptacek
I mean, you're mostly right. Not about the "hiding behind blog posts" thing (we just like to write). But the rest of it, sure? We're not telling you to stop using Heroku. We love Heroku. Heroku is a big part of why we got into this.

Our primary benefit over Heroku isn't "the simplest possible DX". Heroku has that nailed! It's running apps close to users, easily scaling them up and out over the globe. I like us a lot (but then I would) for simple apps that will never need global scaling, but nobody at Fly.io is telling you that we've somehow obsoleted Heroku!

I'm confident that we'll get to parity with Heroku on DX; it's a thing we're serious about. But Heroku has had a long, long time to get these details right, and we're working on other things too. Give us a bit. :P

melony
I want to use Fly, not Heroku. But Fly just doesn't seem to live up to my expectations right now :(

I understand that you believe your competitive advantages stem from the edge server deployments. Sure that may be true for certain serverless and HTML-over-the-wire workloads like Phoenix, but if you actually talk to your customers, a significant number of us want a Heroku replacement, not just fancy docker-at-edge.

tptacek
It seems reasonable that we wouldn't be living up to your expectations; there's no single best place to host things, and Heroku is a great platform. We're Fly.io, not Fleroku.
slimebot80
I like this reply. Not a user of either system currently, but have done projects on both. The use-case for fly.io is strong, but everyone needs to focus on where they want to spend their time vs pay off.
saasxyz
Can I know what projects you build?
r_singh
I was happy with Heroku for a while but had to leave it because of request timeouts being limited to 60 seconds (my app is a scraping api and sometimes requests take more time).

I switched to Appliku and never looked back. Setting up CI/CD pipeline for EC2 can be complicated and with AppLiku I get the Heroku experience without the limitations.

jrochkind1
Not yet. Feel like I should, but the pain isn't quite enough yet to make me do it. I like heroku a lot when it's working, nothing else I've compared has the DX features I want (although render is getting close. I wish it had better command line tooling, and ability to run tasks on one-off 'run' machines).

(I develop a pretty small-scale app for a non-profit)

So, no, not yet. But I am worried I may regret it.

petercooper
Yes. No new projects there (using Fly.io instead as it provides a similar, simple DX but even better and cheaper too unless you are heavily Elements dependent) but am being somewhat slow to actually move things off.. The stack deprecations will probably push me to do it before long though.
mr90210
Are you Peter Cooper from CooperPress?
petercooper
Yes.
mr90210
Well, thank you for your work and dedication.

I’ve been a subscriber for years.

samwillis
We plan to, but not quite yet. The only thing keeping us on Heroku is the "point in time restore" for Postgres, once another platform (such as Render) has that we will probably make the switch.

Having had to use the point in time restore feature before, it's indispensable.

Just taken a look at Appliku as others have mentioned it (we are a Django app), that on DigitalOcean with their managed Postgres could be a strong option.

gday2020
Maybe Scalingo? They do have PITR. Very similar to Heroku. I plan to move to them in the near future (also Django app with Postgres).
mrkurt
Heroku's Postgres is still very good.

If I were looking for "very good Postgres", I would go straight to Crunchy Bridge. I don't think a PaaS is going to get anywhere near that level soon (and I work on Fly.io, so I know we're not).

Building a good PaaS and building an amazing managed database service are two problems that overlap less than you think. The moment we can get Crunchy Bridge or someone at a similar level to run their DBs on our infrastructure is the moment we start using them for customer Postgres.

No one knows this yet, but we have managed Redis soft launched in our CLI. Fly + Upstash is a pretty good combo.

jrochkind1
Kind of becoming a sidebar, but I'm curious if Amazon RDS Postgres counts as "managed postgres"; or, more to the point, what something like Crunchy Bridge gets you over Amazon RDS.

(I have used neither Crunchy Bridge nor Amazon RDS, so this is an actual question, not a challenge! I have used Heroku postgres as well as self-hosted postgres)

craigkerstiens
Craig here from Crunchy. RDS is definitely in the spectrum of more managed, but I'd still say it's more of a spectrum. For instance to my knowledge AWS doesn't fully monitor your individual database for availability, much of their monitoring is more on a fleet/control plane level. There are cases I've heard of where your database is down and AWS simply doesn't know about it because it's not doing health checks against postgres itself. Not implying those cases are a common occurrence, but in a spectrum of how managed it is we definitely aim to be at the far end of how much we do for you on Crunchy Bridge.

Another big area is tooling we're building in to help app developers. Things like health reports for your database, built-in audit logs, simple SSO integration are just a few things that you now don't really have to think but can benefit heavily from. Overall we're a pretty big parallel to Heroku Postgres, with more to come (I wrote about some of that vision here - https://www.craigkerstiens.com/2022/05/18/unfinished-busines...).

appliku
Hey!

There is a heroku config vars sync, so you can keep using Heroku Postgres, but moving the app itself out of there.

Your vars will be in sync, so when heroku rotates credentials they will be quickly applied to your app deployed with Appliku

[dead] e9
mr90210
I don’t know about the unmatched part of your statement.

I use Heroku at work, and DigitalOcean for my personal stuff, and I can tell you that Heroku’s DX has fallen behind.

zbettenbuk
All these "big clouds" are a risk when it comes to global outages. Heroku, Cloudflare, AWS... etc. Using indy or smaller developer focussed clouds can mitigate this problem, but those come with other risks for sure. I think every tech decision makers (CTOs, architects, lead engineers...) need to know at least some of these tools and give them a try to keep a list of plan-Bs at hand.
bombcar
In general for business-class stuff, you're better off going with the biggest names (AWS, Cloudflare) and trying to have your own backups for when those fail.

That way, if the backup works, yay (maybe even covers you shotgunning your own foot now and then), if it fails, eh, everyone is offline because AWS is down so the blame game won't be that harsh.

glenngillen
What leads you to believe indy or smaller clouds are less prone to outages?
rychco
Had a hobby project on heroku that I've moved to render.com pretty painlessly. It's a simple rust (actix + sqlite) project. I now have a go (gin + sqlite) project that is intended to replace the rust project that I also plan to set up on render. Overall it's been incredibly pleasant & I've had no issues.

To be clear though, these are very small/cheap projects between friends so I haven't needed to evaluate costs (beyond a few bucks a month) and I don't have any complex requirements beyond avoiding docker as much as possible.

kgc
Why did you choose go over rust?
rychco
I have more experience with Go + interact with it more regularly at work, whereas choosing Rust was mostly for fun/exploration. I realized I don't have the bandwidth currently to learn/debug a new language I'm unfamiliar with, especially when I don't have strong requirements for memory-safety or performance. This is just a hobby project for me, so I'm moving to a standard network stack that I'm comfortable with in Go.

I'm not completely abandoning Rust, however, as I am still using it for some other personal projects. I am having a good time writing CLI tools + cargo package management/build system is incredible.

throwaway1777
Lots of astroturfing in this thread. Suggest everyone do their own research before making any moves.
rcarmo
Those of you interested in the Heroku lifestyle and willing to have a quick and painless deployment experience (for simple apps) are welcome to try out Piku, a tiny Heroku-inspired PaaS for your own servers:

https://github.com/piku/piku

jrochkind1
Neat, but "my own servers" is not what I think of as the "heroku lifestyle" at all!
rnmp
Have you by any chance tried Dokku? How does it compare with Piku?
rcarmo
Yes, I developed Piku because I did not want to deal with containers on low end platforms like the Raspberry Pi.

These days I run it everywhere, for anything between a headless scraper worker pool to a full blown site.

CSMastermind
Yes. I will be moving my company off of Heroku. The DNS issue yesterday increased the importance of this in my mind.

We'll probably end up going with AWS though I might take a serious look at Azure.

ceejaytkachenko
I gravitate towards small indy vendors more. They're reliable and have better customer support than all these big players combined. My fav is Appliku. I cannot praise this app enough. It's just all that I need and now I don't have to break my head thinking which provider to choose
nkotov
This thread will be filled with a ton of alternatives suggesting a "heroku-like experience" on top of some other cloud provider. My honest opinion, don't waste your time with these "shortcuts". Just use the cloud providers directly.
mrkurt
Good thing we (Fly.io) are a cloud provider you can just use directly. :)
zoomzoom
Would love to hear more about why you think that is the case. For example Cloud Run on GCP is one of the best developer experiences in the cloud provider world, yet still has some key issues (some are solved by Herkou and some aren't). For example: - long-running workers, crons (they're just fixing this in beta with jobs but still has a lot of limits) - ability to get a shell to run arbitrary commands (e.g. SSH) - having multiple environments, auto-configuration of sql/redis connections for each, secrets for each. - Then if you're doing a "real" production-grade app you have to deal with how you orchestrate multiple cloud run instances behind a load balancer (e.g. frontend/backend) and all the DNS/SSL/VPC configuration here - how you deal with CI/CD across multiple environments (e.g. staging/branch previews) for multiple services, both in terms of configuring CI appropriately and in terms of which services trigger which jobs - matching up deployed envs with dev environments

ECS or App Runner on AWS has many of the same issues. 100% agree that many of the k8s-based environment automation solutions are a mismatch for a Heroku replacement. But I do believe there is room for tools that help solve these problems on top of cloud providers (disclosure, working on one at withcoherence.com...)

major505
I been using Heroku for simple apps for a long time, but recently I started moving them to Azure. Nowdays all my projects contains a Dockerfile so there's no reason to stuck with only one server option.

Azure was kind of a pain to configure the first time, but after I got it all running, I have no trouble moving my projects to there.

JanSt
I‘m on DigitalOcean App Platform and pretty happy with it. They keep getting better.

Very easy to use and cheaper than heroku.

skrtskrt
Seconded, I'm on DigitalOcean App Platform, with further plans to self-manage it more either on individual droplets or a RKE2 cluster built on droplets, but I keep on kicking the can down the road because I don't need any more complexity
JanSt
Why do you want so self manage? Saving a few bucks is probably not worth the hassle. I pretty much spend zero time on infra

* push to deploy

* auto-restart

* managed db

* easy scaling

* s3 object storage

* don‘t spend time on updates

* web ui (monitoring, basic logging, configuration, ..)

skrtskrt
really just for my own infra-management education, not any functional reason
systemvoltage
I go the other way. No docker, just bare metal server with 4 cores and it can handle a shitton of traffic.

- Debian OS, fully locked down (all ports closed except SSH, with limiter).

- SSH + rsync to deploy app. I don't have a risk factor of managing dependencies between dev and prod, so I eliminated docker.

- SQLite db that gets thrown on S3 every hour using a python script. I don't want streaming anything. Just hourly backups is good enough.

- Cloudflare tunnel to connect to outside world and serve requests.

It is fast, cheap and requires not much "infra" knowledge. Of course this is for solo devs and small companies.

rnmp
I had a small project hosted in Heroku. After the whole debacle with security I wanted to get ahead of any more potential disruptions and migrated over to AWS EC2 + RDS + Dokku. Being my first time with AWS, I thought it was more straightforward than I thought. RDS seemed like a nice early optimization too (and also mimics how Heroku handles Databases normally by having a separate server for them off the get-go).