5 ms·

Are folks still using Heroku in prod? Curious what the experience is like these days, and if it's as limiting as it used to be.

elsurudo 4y ago
I've been using it in prod for almost 10 years now, almost without issues. Personally I'm still a very happy customer. FWIW, it's a low-traffic app, so cost isn't an issue. I'm happy to pay Heroku a bit more for the developer ergonomics over running my own server – it has saved me a ton of time. Luckily I was not affected by the recent "issues", since I'm not using the Github integration.
bkovacev 4y ago
We do - the monthly bill was about 30k when I joined and I was able to drop it down to 15k in a month by refactoring the majority of the infra (mainly backend workers). DB is the biggest limiting factor - pricing is absolute rubbish. You can't have backups after your data size goes above 20gb. Replicas have to be on the same tier, as otherwise lag occurs daily. Connection limits are awful, but luckily you can setup a pooler in front of the DB. Also, we had workers being stuck in a limbo state, where they aren't crashed, but they aren't working either - but this mainly happens with Celery workers, to be fair. Some add-ons are also cheaper directly on their respective website, rather than through heroku. If someone was to use heroku I'd advise to at minimum: - move the DB elsewhere. - not setup external services through heroku auth (sentry, logtail, newrelic etc) With all of that said - I do have my startup and some pet projects there as it does in fact abstract the devops aspect away.
- your_username 4y ago
  I'm actually in the process of moving a large monolith from EC2 to Heroku and this is exactly what the plan is: our DB (> 10TB) is on RDS; ES, Redis also are from AWS. Third-party services aren't provisioned through the marketplace, instead straight through the vendor. Right now this is Datadog and a bug reporter. We're extremely overprovisioned on EC2 as it is (peaking at 54GB consumed RAM over the last 12 months, and we have 386GB available) so management is welcoming the change to a bunch of Performance L dynos! We're moving to Heroku for a variety of reasons — least of which is their recent fiasco — primarily dev exp and Pipelines/review apps (still supported!). Both will give our developers a vastly superior experience to what they had: nothing (we desperately need it).
  - flatiron 4y ago
    Nobody ever got fired for hiring IBM but I think people may get fired now a days for moving to heroku! Good luck! I would love to hear an update in 12 months if you are still there / heroku is still running.
- scraplab 4y ago
  Our database is north of 20GB and backups work fine. They made improvements to this in Jan 21, which might have improved this? https://blog.heroku.com/faster-postgres-backups https://blog.heroku.com/faster-postgres-backups
  - vdfs 4y ago
    Ours is 170Gb and backups work, but it have continues protection which is always available no matter the size of the DB, but i think OP mean dumps that he can download and store offsite
    - bkovacev 4y ago
      You're right, my bad! Regarding continuous protection that works flawlessly as it has saved us 2-3 times already!
  - bkovacev 4y ago
    We have a: - ~500gb one fails to backup - ~1tb one fails to backup - ~100gb one succesfuly backups The link where I got that number is here - https://devcenter.heroku.com/articles/heroku-postgres-backups https://devcenter.heroku.com/articles/heroku-postgres-backup...
- cpursley 4y ago
  Why haven't y'all moved to Render.com already? It's awesome; It's like as if Heroku never stopped innovating and much cheaper.
  - yoran 4y ago
    What does Render.com do that Heroku doesn't? (seriously asking)
    - cpursley 4y ago
      Free static sites, no daily restarts, easy docker and handles distributed Elixir which is huge for us. I haven't had to touch our infrastructure for a year.
    - crcastle 4y ago
      In addition to what cpursley said in a sibling comment: - http/3 (and 2) - DDoS protection - Mount a disk if you need persistent storage across deploys - Secrets files (not just env vars) - Private networking and DNS-based service discovery between your account's deployed services Disclosure: I'm a Render Dev Advocate
      - w-ll 4y ago
        I've seen Render.com pop up a lot lately on HN. Even have a pinned tab for the migration from Heroku to Render. I have some work stuff on both Heroku and EC2 (gpu instances) and a lot of side projects between both. That said I have a few questions if you dont mind. First is there anything you think that Heroku is still better at then Render is today? Not including stuff thing might come later, but if I had to use todays stack. I see some locations/regions but would like to know more about where the datacenters are, and how close to AWS networks they are. What tuning options do I have for Postgres and Redis. Thanks!
        jvergeldedios 4y ago
        I really like the pipelines feature in Heroku. Being able to automatically deploy to a staging environment from main and then be able to promote that exact slug to production is pretty cool. I’ve yet to find a tool that has replicated that experience or something like it without getting in the weeds with Docker. As far as I know it’s not possible to have separate environments where you’re guaranteed a bit-for-bit match going from staging to production in Render. You have to build for each environment, which if your builds are deterministic should be fine, but I’ve definitely seen that go haywire where you find out your build is in fact not deterministic in some subtle way.
- petercooper 4y ago
  If someone was to use heroku I'd advise to at minimum: - move the DB elsewhere. We've had a lot of success with this. Heroku Postgres didn't make much sense for something we were doing so we spun up a RDS instance in the same region since Heroku uses AWS anyway and the latency was next to nothing but with easier management, better price, better performance, etc.
johnbellone 4y ago
I've had to recently approve a surprisingly large bill for Heroku. For small teams/products/services it totally makes sense. After a certain point, especially in a large organization that understands the value in infrastructure/operations investment, most applications/services can be streamlined and deployed. At that point, no, it is much much cheaper to go elsewhere.
- glenngillen 4y ago
  I obviously can’t speak to your specific bill. When I used to have visibility into such things the vast majority of people who said “my Heroku bill is huge!” we’re actually giving very little of it to Heroku. Most of it was add-ons for metrics, logging, error tracking, etc. If you’ve not already gone through the line items I’d recommend it. You might find that replatforming isn’t as cheap as you’d expect, unless that also included ditching the multitude of other SaaS products the team has accumulated.
vdfs 4y ago
The fact that minor change like this made it to front page mean it's still used, there no better altrenative. From a happy ~7 years customer
wbobeirne 4y ago
Was on it until late last year, switched off recently. The cost for the performance and reliability of their Redis and Postgres instances was pretty bad, and it didn't seem like the dynos were well co-located with the db. A few of the issues we had: 1. Redis was wildly unreliable, would go down for 2-5 minutes every few days with no explanation from support 2. We had to pay for a much beefier instance of Redis just to increase our connection count. We weren't using more than 2-3% of the available memory, we just needed the connections, but you can't pick and choose. 3. Their limits on websocket connections were also a killer, I think each dyno could have a max of like 1,000 sockets so we had to add more dynos just for more sockets. 4. Switching over to AWS reduced the RTT (just networking, not actual query runnig time) on Postgres queries from ~8ms to ~1ms. Seems like the dynos and db weren't closely co-located. However, the amount of time spent and code we have to maintain our infrastructure is waaay more than it used to be on Heroku. No free lunch for sure.
bvirb 4y ago
We're happily using Heroku in prod. One nice thing for us is that we also use Heroku CI so our tests run on the same infrastructure as prod, and the pricing for Heroku CI is just based on usage with no concurrency limits so everyone can have their CI runs across all their branches happening at the same time. We tried Github Actions when Heroku CI was ahem "down" and it was slower & more expensive + the concurrency limits meant we had to wait in line to get a CI run though. Nobody else seems to use or even talk about it though, so either we have a crazy CI setup or Heroku just never marketed it. We occasionally do the math to see if Heroku is still a good deal and the answer is always that the amount of time we estimate we're saving on devops more than pays for itself in extra time spent on app development. There's a break-even where that will no longer be the case, but as engineering & devops get more and more expensive Heroku seems like a better and better deal. The scariest part isn't really the product itself but all the recent talk about how it's a ghost town and nobody works there anymore. It's a great product but I do hope they start innovating again.
- deleted 4y ago
  [deleted]
the__alchemist 4y ago
Yep! Using it to run a scheduling webapp for a number of fighter squadrons.
yoran 4y ago
For sure. As the only developer in the team, it saves me a bunch of devops time that I can instead dedicate on the business, while we're trying to get product-market fit. I'm sure that there are limitations for larger teams or if you have specific requirements. But I think it's a great choice if you're a small team and/or your application is more or less run-of-the-mill from a technical point of view.
aabhay 4y ago
We had ~10 apps on heroku until last month. We have been migrating to Cloud Run and Cloudflare Pages recently and love it.
EToS 4y ago
Switched to GCP Cloud Run.. but do miss the Heroku CLI sometimes
- petercooper 4y ago
  For anyone who really digged Heroku's CLI experience, fly.io is particularly strong in this area, I find. The ability to just deploy in a single command from any directory was a huge draw for me (even Render requires you deploy from a git repo - a best practice, sure, but I like the option).
  - nxss 4y ago
    Got too much fighting time with .yml configs on Fly, deploy from git is must have nowadays.
    - petercooper 4y ago
      Yeah, I see it from both sides. I lean towards being an independent developer doing a lot of prototyping so I like Fly's tolerance of quicker, less strict practices in this regard. Not had any problems with fly.toml so far, but my apps are relatively simple.
- holografix 4y ago
  What CLI…? Just set up continuous deploy from GitHub from the Cloud Run UX itself. It’ll create a Cloud Build trigger for you and deploy every time you push to your desired branch.
ab-dm 4y ago
Yep, still running my saas product on it, have been for over 5 years. Never had any issues really, and we deploy through a CI/CD so we don’t have GitHub connected. Still more expensive than I’d like, and the lack of an AU option sucks, but it’s been great so far, I choose it because I didn’t want to worry about devops, and that’s pretty much been the experience. I have had a look at render, but didn’t find it as easy as Heroku, It’s probably due to me being more familiar with Heroku.
SL61 4y ago
We have a couple production websites on Heroku. One is a decade-old Rails app and the other is a Rails backend for a ~3-year-old site whose frontend is hosted on Vercel. The decade-old app is still running great. We make extensive use of the Heroku CLI and some of the addons for databases and logging. The newer one isn't so heavily integrated into Heroku's features aside from the database. It was set up by a senior dev who's given largely free rein over his projects, but otherwise the company switched to DigitalOcean for new projects several years ago. So my job is ~75% working with DO droplets and ~25% Heroku dynos. I didn't care either way, really, because at the end of the day my priority is the actual program. But the recent blowup with Heroku's GitHub integration was really painful, especially for our old app whose deployment process was deeply integrated with our GitHub repo. Once the outage had dragged out for a couple weeks, I started advocating to my lead for a move to DigitalOcean. The only reason we haven't done it yet is that we're a consultancy so we'd need to sell our very non-technical customer on a migration. My points are 1) I think a lot of Heroku's business in 2022 comes from large, old projects that, for various reasons, are complicated to move elsewhere, and 2) Heroku is pretty much fine for those projects, aside from the recent issues that were thankfully resolved.
danjac 4y ago
I used to use it for side projects (not sure if you would count that as "production") but now go with Dokku on top of Hetzner or Digital Ocean. It's similar in experience to Heroku (at least the CLI) but much cheaper, and as it's my own VM if I hit a limitation in Dokku I can access the VM itself or just throw away Dokku entirely and use something else instead. The major limitation is that it doesn't really do multi-server setups well, but for the wheelhouse of low-traffic simple applications it's great.

elsurudo 4y ago

I've been using it in prod for almost 10 years now, almost without issues. Personally I'm still a very happy customer. FWIW, it's a low-traffic app, so cost isn't an issue. I'm happy to pay Heroku a bit more for the developer ergonomics over running my own server – it has saved me a ton of time. Luckily I was not affected by the recent "issues", since I'm not using the Github integration.

bkovacev 4y ago

We do - the monthly bill was about 30k when I joined and I was able to drop it down to 15k in a month by refactoring the majority of the infra (mainly backend workers). DB is the biggest limiting factor - pricing is absolute rubbish. You can't have backups after your data size goes above 20gb. Replicas have to be on the same tier, as otherwise lag occurs daily. Connection limits are awful, but luckily you can setup a pooler in front of the DB. Also, we had workers being stuck in a limbo state, where they aren't crashed, but they aren't working either - but this mainly happens with Celery workers, to be fair. Some add-ons are also cheaper directly on their respective website, rather than through heroku. If someone was to use heroku I'd advise to at minimum: - move the DB elsewhere. - not setup external services through heroku auth (sentry, logtail, newrelic etc) With all of that said - I do have my startup and some pet projects there as it does in fact abstract the devops aspect away.

your_username 4y ago
I'm actually in the process of moving a large monolith from EC2 to Heroku and this is exactly what the plan is: our DB (> 10TB) is on RDS; ES, Redis also are from AWS. Third-party services aren't provisioned through the marketplace, instead straight through the vendor. Right now this is Datadog and a bug reporter. We're extremely overprovisioned on EC2 as it is (peaking at 54GB consumed RAM over the last 12 months, and we have 386GB available) so management is welcoming the change to a bunch of Performance L dynos! We're moving to Heroku for a variety of reasons — least of which is their recent fiasco — primarily dev exp and Pipelines/review apps (still supported!). Both will give our developers a vastly superior experience to what they had: nothing (we desperately need it).
- flatiron 4y ago
  Nobody ever got fired for hiring IBM but I think people may get fired now a days for moving to heroku! Good luck! I would love to hear an update in 12 months if you are still there / heroku is still running.
scraplab 4y ago
Our database is north of 20GB and backups work fine. They made improvements to this in Jan 21, which might have improved this? https://blog.heroku.com/faster-postgres-backups https://blog.heroku.com/faster-postgres-backups
- vdfs 4y ago
  Ours is 170Gb and backups work, but it have continues protection which is always available no matter the size of the DB, but i think OP mean dumps that he can download and store offsite
  - bkovacev 4y ago
    You're right, my bad! Regarding continuous protection that works flawlessly as it has saved us 2-3 times already!
- bkovacev 4y ago
  We have a: - ~500gb one fails to backup - ~1tb one fails to backup - ~100gb one succesfuly backups The link where I got that number is here - https://devcenter.heroku.com/articles/heroku-postgres-backups https://devcenter.heroku.com/articles/heroku-postgres-backup...
cpursley 4y ago
Why haven't y'all moved to Render.com already? It's awesome; It's like as if Heroku never stopped innovating and much cheaper.
- yoran 4y ago
  What does Render.com do that Heroku doesn't? (seriously asking)
  - cpursley 4y ago
    Free static sites, no daily restarts, easy docker and handles distributed Elixir which is huge for us. I haven't had to touch our infrastructure for a year.
  - crcastle 4y ago
    In addition to what cpursley said in a sibling comment: - http/3 (and 2) - DDoS protection - Mount a disk if you need persistent storage across deploys - Secrets files (not just env vars) - Private networking and DNS-based service discovery between your account's deployed services Disclosure: I'm a Render Dev Advocate
    - w-ll 4y ago
      I've seen Render.com pop up a lot lately on HN. Even have a pinned tab for the migration from Heroku to Render. I have some work stuff on both Heroku and EC2 (gpu instances) and a lot of side projects between both. That said I have a few questions if you dont mind. First is there anything you think that Heroku is still better at then Render is today? Not including stuff thing might come later, but if I had to use todays stack. I see some locations/regions but would like to know more about where the datacenters are, and how close to AWS networks they are. What tuning options do I have for Postgres and Redis. Thanks!
      - jvergeldedios 4y ago
        I really like the pipelines feature in Heroku. Being able to automatically deploy to a staging environment from main and then be able to promote that exact slug to production is pretty cool. I’ve yet to find a tool that has replicated that experience or something like it without getting in the weeds with Docker. As far as I know it’s not possible to have separate environments where you’re guaranteed a bit-for-bit match going from staging to production in Render. You have to build for each environment, which if your builds are deterministic should be fine, but I’ve definitely seen that go haywire where you find out your build is in fact not deterministic in some subtle way.
petercooper 4y ago
If someone was to use heroku I'd advise to at minimum: - move the DB elsewhere. We've had a lot of success with this. Heroku Postgres didn't make much sense for something we were doing so we spun up a RDS instance in the same region since Heroku uses AWS anyway and the latency was next to nothing but with easier management, better price, better performance, etc.

johnbellone 4y ago

I've had to recently approve a surprisingly large bill for Heroku. For small teams/products/services it totally makes sense. After a certain point, especially in a large organization that understands the value in infrastructure/operations investment, most applications/services can be streamlined and deployed. At that point, no, it is much much cheaper to go elsewhere.

glenngillen 4y ago
I obviously can’t speak to your specific bill. When I used to have visibility into such things the vast majority of people who said “my Heroku bill is huge!” we’re actually giving very little of it to Heroku. Most of it was add-ons for metrics, logging, error tracking, etc. If you’ve not already gone through the line items I’d recommend it. You might find that replatforming isn’t as cheap as you’d expect, unless that also included ditching the multitude of other SaaS products the team has accumulated.

vdfs 4y ago

The fact that minor change like this made it to front page mean it's still used, there no better altrenative. From a happy ~7 years customer

wbobeirne 4y ago

Was on it until late last year, switched off recently. The cost for the performance and reliability of their Redis and Postgres instances was pretty bad, and it didn't seem like the dynos were well co-located with the db. A few of the issues we had: 1. Redis was wildly unreliable, would go down for 2-5 minutes every few days with no explanation from support 2. We had to pay for a much beefier instance of Redis just to increase our connection count. We weren't using more than 2-3% of the available memory, we just needed the connections, but you can't pick and choose. 3. Their limits on websocket connections were also a killer, I think each dyno could have a max of like 1,000 sockets so we had to add more dynos just for more sockets. 4. Switching over to AWS reduced the RTT (just networking, not actual query runnig time) on Postgres queries from ~8ms to ~1ms. Seems like the dynos and db weren't closely co-located. However, the amount of time spent and code we have to maintain our infrastructure is waaay more than it used to be on Heroku. No free lunch for sure.

bvirb 4y ago

We're happily using Heroku in prod. One nice thing for us is that we also use Heroku CI so our tests run on the same infrastructure as prod, and the pricing for Heroku CI is just based on usage with no concurrency limits so everyone can have their CI runs across all their branches happening at the same time. We tried Github Actions when Heroku CI was ahem "down" and it was slower & more expensive + the concurrency limits meant we had to wait in line to get a CI run though. Nobody else seems to use or even talk about it though, so either we have a crazy CI setup or Heroku just never marketed it. We occasionally do the math to see if Heroku is still a good deal and the answer is always that the amount of time we estimate we're saving on devops more than pays for itself in extra time spent on app development. There's a break-even where that will no longer be the case, but as engineering & devops get more and more expensive Heroku seems like a better and better deal. The scariest part isn't really the product itself but all the recent talk about how it's a ghost town and nobody works there anymore. It's a great product but I do hope they start innovating again.

deleted 4y ago
[deleted]

the__alchemist 4y ago

Yep! Using it to run a scheduling webapp for a number of fighter squadrons.

yoran 4y ago

For sure. As the only developer in the team, it saves me a bunch of devops time that I can instead dedicate on the business, while we're trying to get product-market fit. I'm sure that there are limitations for larger teams or if you have specific requirements. But I think it's a great choice if you're a small team and/or your application is more or less run-of-the-mill from a technical point of view.

aabhay 4y ago

We had ~10 apps on heroku until last month. We have been migrating to Cloud Run and Cloudflare Pages recently and love it.

EToS 4y ago

Switched to GCP Cloud Run.. but do miss the Heroku CLI sometimes

petercooper 4y ago
For anyone who really digged Heroku's CLI experience, fly.io is particularly strong in this area, I find. The ability to just deploy in a single command from any directory was a huge draw for me (even Render requires you deploy from a git repo - a best practice, sure, but I like the option).
- nxss 4y ago
  Got too much fighting time with .yml configs on Fly, deploy from git is must have nowadays.
  - petercooper 4y ago
    Yeah, I see it from both sides. I lean towards being an independent developer doing a lot of prototyping so I like Fly's tolerance of quicker, less strict practices in this regard. Not had any problems with fly.toml so far, but my apps are relatively simple.
holografix 4y ago
What CLI…? Just set up continuous deploy from GitHub from the Cloud Run UX itself. It’ll create a Cloud Build trigger for you and deploy every time you push to your desired branch.

ab-dm 4y ago

Yep, still running my saas product on it, have been for over 5 years. Never had any issues really, and we deploy through a CI/CD so we don’t have GitHub connected. Still more expensive than I’d like, and the lack of an AU option sucks, but it’s been great so far, I choose it because I didn’t want to worry about devops, and that’s pretty much been the experience. I have had a look at render, but didn’t find it as easy as Heroku, It’s probably due to me being more familiar with Heroku.

SL61 4y ago

We have a couple production websites on Heroku. One is a decade-old Rails app and the other is a Rails backend for a ~3-year-old site whose frontend is hosted on Vercel. The decade-old app is still running great. We make extensive use of the Heroku CLI and some of the addons for databases and logging. The newer one isn't so heavily integrated into Heroku's features aside from the database. It was set up by a senior dev who's given largely free rein over his projects, but otherwise the company switched to DigitalOcean for new projects several years ago. So my job is ~75% working with DO droplets and ~25% Heroku dynos. I didn't care either way, really, because at the end of the day my priority is the actual program. But the recent blowup with Heroku's GitHub integration was really painful, especially for our old app whose deployment process was deeply integrated with our GitHub repo. Once the outage had dragged out for a couple weeks, I started advocating to my lead for a move to DigitalOcean. The only reason we haven't done it yet is that we're a consultancy so we'd need to sell our very non-technical customer on a migration. My points are 1) I think a lot of Heroku's business in 2022 comes from large, old projects that, for various reasons, are complicated to move elsewhere, and 2) Heroku is pretty much fine for those projects, aside from the recent issues that were thankfully resolved.

danjac 4y ago

I used to use it for side projects (not sure if you would count that as "production") but now go with Dokku on top of Hetzner or Digital Ocean. It's similar in experience to Heroku (at least the CLI) but much cheaper, and as it's my own VM if I hit a limitation in Dokku I can access the VM itself or just throw away Dokku entirely and use something else instead. The major limitation is that it doesn't really do multi-server setups well, but for the wheelhouse of low-traffic simple applications it's great.