Heroku 22 Stack(devcenter.heroku.com)
devcenter.heroku.com
Heroku 22 Stack
https://devcenter.heroku.com/articles/heroku-22-stack
50 comments
It would be great if you could let everyone know (here, or as a later Tell HN) which alternatives you're considering. People have chimed in with suggestions before (Fly, Render, etc.) but it always helps to have additional thoughts on this, especially from someone running a high traffic'ed site. Thanks!
We've been tracking these threads lately and there are so many interesting companies in the space like those mentioned above. I'm the cofounder of a new company called Coherence, that we think creates a new direction and offers a better platform for the next leap forward. Unlike the modern PaaS solutions we're closing the loop from dev to prod offering cloud IDE's, dev environments, branch previews, and deployments — all in one integrated dashboard. Check us out at withcoherence.com
Will do. Currently building up a doc and comparison matrix along with test deploys.
Platform.sh looks promising. Render was a breeze to setup, loading our ENVs was the longest task.
Platform.sh looks promising. Render was a breeze to setup, loading our ENVs was the longest task.
Lu with Massdriver (YC W22) here. Our public launch is June 29th but we'd love to get some feedback from the community before then. If you sign up at massdriver.cloud we can push you through so you can set up a POC.
We are in pre-planning for our exit as well. We will be on AWS EKS(perhaps with lambda/ECS mix) by the time our contract is up next March.
Too many issues both discussed here and undiscussed. Also, their upsell approach is stale:
* Public runtime has a 20 min cooldown after 3 app crashes
* Hobby pro dynos don't report container mem limits due to ancient cgroup setups(gotta upgrade to performance M)
* No Dyno sizes between 2.GB and 14GB ?!
Bunch of BS trying to push you towards Enterprise accounts, more expensive dynos, and private spaces(which cost more Dyno units).
Too many issues both discussed here and undiscussed. Also, their upsell approach is stale:
* Public runtime has a 20 min cooldown after 3 app crashes
* Hobby pro dynos don't report container mem limits due to ancient cgroup setups(gotta upgrade to performance M)
* No Dyno sizes between 2.GB and 14GB ?!
Bunch of BS trying to push you towards Enterprise accounts, more expensive dynos, and private spaces(which cost more Dyno units).
We tried[0] to find Heroku alternative a couple of weeks ago. In short Render.com feels solid and Railway.app very promising, hope they will do more progress soon.
[0] https://nixsanctuary.com/best-paas-backend-hosting-heroku-vs...
[0] https://nixsanctuary.com/best-paas-backend-hosting-heroku-vs...
I migrated a static site and a few apis off heroku onto render.com a few months ago and the experience has been really great. Fills the niche of Heroku perfectly for my use cases.
We are looking at a number of alternatives as well. A number of the common ones mentioned don't have feature parity with Heroku for larger apps (log drains to external logging services, CLIs, etc). Aptible looked pretty mature (they are trying to be Heroku, but for apps that need more security/compliance), and Platform.sh is intriguing as well.
It's also the lack of communication and dealing with support is not great.
Funnily enough, it's down right now :(
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.
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.
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]
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.
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.
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
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-backup...
- ~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-backup...
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
You're right, my bad! Regarding continuous protection that works flawlessly as it has saved us 2-3 times already!
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.
What does Render.com do that Heroku doesn't? (seriously asking)
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
- 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
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!
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!
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
Luckily I was not affected by the recent "issues", since I'm not using the Github integration.
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
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.
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.
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.
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.
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.
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.
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.
We had ~10 apps on heroku until last month. We have been migrating to Cloud Run and Cloudflare Pages recently and love it.
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.
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.
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.
Switched to GCP Cloud Run.. but do miss the Heroku CLI sometimes
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).
Got too much fighting time with .yml configs on Fly, deploy from git is must have nowadays.
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.
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.
Yep! Using it to run a scheduling webapp for a number of fighter squadrons.
We use it for mini supportive apps, but have the core of our product on AWS directly.
Been using it for 8 years and going strong
Heroku had been my go to for many years for any initial project but their response to their recent incident has made me decide to try and use anything else for my latest project.
If I'm starting a new ktor project, who offers the least friction in trying things out and learning the frame work?
If I'm starting a new ktor project, who offers the least friction in trying things out and learning the frame work?
[deleted]
After the latest 6 week credential loss / security breach we are actively looking for our replacement and expect to be gone by the end of the year if not the summer