Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Are you leaving Heroku?
88 points by seancoleman on Aug 24, 2022 | hide | past | favorite | 111 comments
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)?



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.


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?


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).


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


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.


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.


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.


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.


Can I know what projects you build?


sent you a mail.


Today I went to restore a backup from three weeks ago on a new test instance and I saw it broke. I was getting some utterly weird messages about the pgcrypto extension not being available anymore (problem since I use UUIDs as my ids).

After HOURS of messing around I found this https://devcenter.heroku.com/changelog-items/2446. None of which was communicated to anyone, and it completely breaks all old backups. There's no mitigation listed on the page, and from what I can tell no one can figure out the proper way to do this without manually dumping, manually changing all references, pushing it back up and hoping to god nothing breaks.

I find it absolutely, utterly, unacceptable to do something like this with no migration path documented. Most people (including myself) use Heroku because we're willing to pay more over being a sysadmin. I can run my own infrastructure on bare metal machines, but it's something I deeply, deeply, don't want to do. Much less manually editing 15gb SQL files.

So yes, I'm considering leaving if this isn't mitigated quickly.


Yep. I am getting pretty good support communications on this issue in heroku support tickets (you are not?), but the fact that they haven't actually made a public announcement about it is pretty unforgiveable.

Last I heard from support, they thought the issue you are running into with backup restores would be solved maybe in the next week or two... but there is no public place to look for status or resolution, I just need to keep asking support, apparently. There are workarounds, that is there are ways to restore from those backups if you really need to... but it's confusing. Some more info here:

https://www.reddit.com/r/Heroku/comments/wgkjdf/heroku_ext_c...

Anyway, still being in the middle of dealing with this when the DNS issue happened... my opinion of heroku is definitely dropping fast... but it started out so high it's gonna take it a while to hit the ground and smash into pieces.


Heroku support answered my support ticket within a few hours (so good on them) with a canned response that pointed me to the article I had already referenced to them (not so good) and some hand waving "we're working on it." How they deploy this without figuring out a migration path first is beyond me. Someone... must have brought this up internally and been shot down I guess?

The issue they say this was to mitigate is this CVE https://www.postgresql.org/about/news/postgresql-145-138-121... which seems extraordinarily difficult to exploit (oh, and they don't address in already active databases... so....).

Very much throwing the baby out with the bathwater.

Plus the "we're shutting down all your stuff" message today makes me scrambling for another service.


> Plus the "we're shutting down all your stuff" message today makes me scrambling for another service.

Wait, what? i didn't get that one! I don't think....


Log in and look at the notice at the top. All free services go away in November (the day after Thanksgiving weekend none-the-less, so have fun there). Upgrade your Postgres and Redis or you're screwed.


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).


I've got several SQLite + Litestream projects running on Fly, and I've been happy with the service. Here's my config if you'd like a reference:

https://github.com/mtlynch/picoshare/blob/b246751d5036fdb332... https://github.com/mtlynch/picoshare/blob/b246751d5036fdb332... https://github.com/mtlynch/picoshare/blob/b246751d5036fdb332...


Thanks :)


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.


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.


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...)


Good thing we (Fly.io) are a cloud provider you can just use directly. :)


Hi all... I'm the new-ish Heroku/DX GM for Salesforce, and in prior job was the Kubernetes GM for AWS. I always read these threads with great interest. Very much appreciate the unvarnished feedback about Heroku we get here.


In the main thread on Hacker News, you still haven't addressed any of the issues raised by developers on closing down the free tier. What alternatives did you consider? What stats? What about folks who have both free and paid dynos?

Also, please read all the feedback on the communication style in the blogpost.


I left Heroku in favor of just a hand-configured DigitalOcean droplet. I might try Fly.io but honestly, for what I’m doing, the flexibility of a full Ubuntu box is just too good, even in 2022.


Try Debian if you want everything almost the same as Ubuntu but without the bloat. Everything is faster. What it lacks in branding/marketing, it makes up for it in the speed. Also recommend FreeBSD.


What's faster? There's not really any bloat impacting server performance on ubuntu vs debian


Reposting this because fuck Heroku:

A former employer was mad at me for daring to leave my job and made a malicious DMCA claim against my website. Heroku took it down with zero notice and treated me like a criminal when I called them to quit their bullshit.

They said I was not allowed to ever host the falsely claimed content on Heroku ever again. They said that I should pursue external avenues for disputing the claim. I took my site off Heroku and kept it offline because of the implicit threats of lawsuits from my previous employer. The site was my online portfolio of work and experience I was using for job hunting. However, my Heroku account was also used to host my profit-generating website/business, and instead of taking down only my portfolio site, they took down every site on my account. My account was completely disabled and I wasn't able to even remove the specific site and put my other ones back online, which is why I had to call them to re-enable it, but only after they treated me like shit and like I was murdering babies even though I told them the DMCA claim was malicious.


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


Neat, but "my own servers" is not what I think of as the "heroku lifestyle" at all!


Have you by any chance tried Dokku? How does it compare with Piku?


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.


We left Heroku last spring with a project consuming around 5k$/mo worth of Heroku services.

Main reason for the move was pretty simple, we just needed more control over our own infrastructure and Heroku wasn't able to offer that. Things like HTTP2 support, access to load balancer configurations, timeout settings, different auto-scaling options and better monitoring are first things that come to mind.

We are now using AWS directly (EKS, RDS, Lambda etc) and even though the move itself did cost a bit, I wouldn't say monthly costs went up too much (but it's bit hard to compare as we're using more services at AWS and scaled up right after migration).

Basically, we just grew out of Heroku.

And personally I wouldn't choose them again even if opportunity appeared.


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.


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.


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)


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...).


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


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).


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


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.


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)


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.


Honestly you should checkout open source + self-host alternatives like porter (https://github.com/porter-dev/porter). I tried it in a project before and the developer experience was surprisingly good.


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.


Are you Peter Cooper from CooperPress?


Yes.


Well, thank you for your work and dedication.

I’ve been a subscriber for years.


Ah thank you very much! :)


The new Hatchbox v2 ( https://hatchbox.io/ ) coupled with a low cost instance from Linode has been a dream for me.

Multiple apps can be deployed to a single server without incurring more costs.

Hatchbox does all of the provisioning.


You might also note there has been little to no feature development for Heroku in some time


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.


Any other seemingly trivial bugs that are frustrating you? Would love to get your list.


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".


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.


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.


https://news.ycombinator.com/item?id=32594533

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


@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.


keeping your runtimes up to date, especially with security patches, is a good place to start


I moved to https://render.com, and it works pretty well so far


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.


Why did you choose go over rust?


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.


Left it awhile ago - we've gone all in on Render. Aside from these weird intermittent DNS issues Sentry has been flagging, it's been smooth. Our engs love it.


We are building a cheaper and better alternative over at https://app.build.io ; you can start importing your Heroku apps to our platform or create new apps on it, it automatically builds apps with continuous delivery from your GitHub repository. When you import your app from Heroku we get your buildpacks (or detect them if you didn't manually set them) and sync your environment variables with Heroku, so you can keep your addons running on Heroku but save money with our cheaper and faster "dynos" (we call them instances).


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.


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.


What leads you to believe indy or smaller clouds are less prone to outages?


> 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)?

I see only two real Heroku competitors: Render and Fly.io.

It seems that Render is currently better at developer experience, and Fly.io – at geographical availability.


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.


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

Very easy to use and cheaper than heroku.


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


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, ..)


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.


really just for my own infra-management education, not any functional reason


Oh. So there was a DNS issue yesterday? A custom of mine was complaining that my apps weee down and blamed CloudFlare. They didn’t inform me of this issue, I had to find out via HN/customers.

130 apps to get off Heroku is going to a massive pain to get through but it’s looking more and more likely…


Related: I wrote about Heroku a few months ago and there was some good disucssion[1] here.

[1]: https://news.ycombinator.com/item?id=31559270


I am not very familiar with any of these, but here is the short list of things I've compiled from past HN threads, that might be alternatives to heroku that provide similar affordances to heroku.

Most of them I have done no more than look at the website and determine that, yeah, it was similar to heroku for my personal criteria of what makes something similar to heroku. (Some things suggested in past threads did not meet them and I didn't keep on my list).

render.com

fly.io

platform.sh

railway.app


Some hands on experience with all of these, September 2022:

Render.com - we use this for production at Grilla. Great experience, great platform. I wish I could pay them money to have my builds go faster but everything I want out of the box in places where you would think to look for them first. Fantastic dev ux. Never said, fuck I wish I had this and couldn't find it.

Fly.io - still extremely rough around the edges and militant about things that most companies don't really care about. For example, you create your database, and you see the credentials once and only once. You didn't save them? Tough luck, delete your database and create a new one. Just a lot of sharp corners. Same with ENV vars, you can only set them not see them. Which is ridiculous. Hey my payment processor isn't working, the webhooks aren't coming in, let's debug check the webhook env var, what you can't see it? Ugh.... They are most likely working very hard on the fundamentals of the hosting platform, but they need a lot of work on the dev ux.

Railway.app - Sexy as fuck, will potentially tear me away from Render on my next endeavor. These guys are taking everything that's shitty about hosting apps and making it simple. One thing I did miss was being able to ssh into a running container to run an elixir console into the running process. But for everything else, they are right on the money and gaining quick.


If you felt like saying more about what you liked about railway.app, it's advantages in comparison to heroku and render specifically, I would find it interesting!


I can only speak about render.com which I've seen recommended several times. I was thoroughly unimpressed. Heroku is my go to when I want to spend no more than 5 minutes getting a microservice deployed. Otherwise I would use DO. Render seemed to be the longer and clunkier experience of DO without the benefits of DO.


(Render founder) Any chance we could connect about the issues you saw with Render? Email in profile. Lots of former Heroku customers spending thousands of dollars every month have successfully made the switch to Render and are quite happy (as you can see elsewhere on HN). I'd appreciate a chance to address your pain points with us.


Probably not, but generation focus is pretty good at connecting companies with specific subsets of users. I know they already maintain a list of current heroku devs.


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.


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).


To be honest, no service is either too big or too small to run their own DNS. Any company with DNS issues that can't be temporarily fixed by reverting to a pre-issues config until they can address things is doing things quite poorly.

I don't use Heroku, but this trend of people and businesses taking no direct responsibility for critical services is a bad one, and I'd skip any business I could that does this.


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.


We needed a tool that gave us the same experience as Heroku but on AWS, so we went with Nullstone (https://nullstone.io). Everything is nicely managed in a style you'll be familiar with and takes advantage of open source Terraform modules they publish.


Moved my T1D stuff off Heroku a few months back. Moved it to Render. Very happy with the cost and it's been stable.

Notes here: https://gist.github.com/ianchesal/5c96c566ab99b60c2c557711fa...


I'm using Appliku for https://app.ankihub.net/. So far so good! I'm really hoping it continues to grow and succeed.


Yes, have been planning on it for awhile but yesterday's outage was last straw for us. Probably moving to Fly.io (https://fly.io).


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.


I'm using Appliku for https://app.ankihub.net/ right now. So far so good!


I moved one of my smaller projects from Heroku to AppEngine in the spring. Took me about a day to set up the infra and move the DNS. Hosting went from $30 to $1 a month.


This seems like it would make a good poll. Could you convert it? My answer is the same as someone else before, and I'd love to get some numbers back on this.


How is it compared to Digitalocean app platform?


Given the update to eliminate the free tier today, this thread hits differently.


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.


nope, still other alternatives requires some invest in integration and onboarding


I've not found the time to write up the entirety of my experience unfortunately, but I did move a bunch of stuff off Heroku over the past couple of years and directly onto AWS. It was a very piecemeal approach which had the double benefit of being low/no impact to end users while also letting me do it at my leisure. My general approach was:

* Import my current Heroku config into Terraform resources so I can co-ordinate changes across multiple platforms as a single atomic change. * Embrace a strangler pattern (https://www.redhat.com/architect/pros-and-cons-strangler-arc...). I used Cloudfront, but you could put any CDN in front.

* My databases + workers were a large part of my Heroku bill, and I had a very spikey usage profile (potentially days with near zero usage, with brief peaks), so I used it as an opportunity to refactor towards a serverless infrastructure (https://www.redhat.com/architect/pros-and-cons-strangler-arc...). This was entirely superfluous to the migration though. If I'd not taken that approach the alternate would have been to provision and RDS Postgres instance, add the required IAM profiles to my Heroku app. Work out how/when to schedule a window to cutover to RDS being the primary DB. Update the DATABASE_URL accordingly. Again, doing all of this via Terraform to make it happen. But doing it in small incremental steps where possible (i.e., adding the IAM profiles to the app first). Once cut-over, take a final snapshot of the Heroku Postgres database and then shut it down.

* Updating the code on my workers to be idempotent.

* Make sure config vars are imported to Terraform and are sync'd to the various places they need to be (probably just the Heroku app for now).

* Have the workers run inside containers on AWS (doing them just one worker at a time), exposing the required config vars for them to work. Let the Heroku + AWS workers both process the work for a period of time, hence the need for being idempotent. Once I'm confident the AWS ones work as intended, shut down the Heroku workers.

* Picking off individual paths/API endpoints to serve from AWS. In my case I also migrated all of this to API gateway + lambda. An ALB with EC2/ECS would have also been an alternative. Add a new path based route to your CDN (e.g., /v2/the-existing-path) and have it's origin point to your non-Heroku service. Test it. Once it works, update the existing path that users are using to now go to the new origin. It means if you discover some issue you can quickly update the routing to have Heroku resume serving that route. Once you're confident, rinse and repeat the next path. Continue through until all traffic is ultimately served by the new host.

* If there's nothing left then scale down the remaining processes on Heroku.

I've gone an all-in AWS approach, but the same general principle could apply to whatever platform you want to run on. I think the biggest thing people I've spoken to in the past about this overlook is that you don't have to make some big wholesale switch. There's ways to derisk it and take an incremental approach to migrating. Which also drastically reduces the cost of making the wrong decision. If you can run just one route through AWS/Fly/DigitialOcean/whatever then you can get a sense for whether it will _actually_ work for your needs, and quickly roll back if you change your mind.


Yes.


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


My main issue is the free redis and cheap postgres instances they provide for my low-traffic app.


redis and postgres sounds like you could just use render


After Heroku's outage, they decided to kill all of their free dynos, redis, and pg! ugh


render pricing looks much more competitive. Thanks for the tip!


You can get built databases deployed with Appliku as well. No reason to go broke on a small side project


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.


I may have some bad news for you...

(Heroku are removing their free tier of everything)


Lots of astroturfing in this thread. Suggest everyone do their own research before making any moves.


"Please don't post insinuations about astroturfing, shilling, bots, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data."

https://news.ycombinator.com/newsguidelines.html

https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: