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)?
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.
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).
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.
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.
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.
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).
https://github.com/mtlynch/picoshare/blob/b246751d5036fdb332... https://github.com/mtlynch/picoshare/blob/b246751d5036fdb332... https://github.com/mtlynch/picoshare/blob/b246751d5036fdb332...
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...)
Also, please read all the feedback on the communication style in the blogpost.
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.
These days I run it everywhere, for anything between a headless scraper worker pool to a full blown site.
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.
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.
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.
(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)
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
(I develop a pretty small-scale app for a non-profit)
So, no, not yet. But I am worried I may regret it.
Multiple apps can be deployed to a single server without incurring more costs.
Hatchbox does all of the provisioning.
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.
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.
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.
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.
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.
Very easy to use and cheaper than heroku.
* push to deploy
* auto-restart
* managed db
* easy scaling
* s3 object storage
* don‘t spend time on updates
* web ui (monitoring, basic logging, configuration, ..)
130 apps to get off Heroku is going to a massive pain to get through but it’s looking more and more likely…
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
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.
I use Heroku at work, and DigitalOcean for my personal stuff, and I can tell you that Heroku’s DX has fallen behind.
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 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.
Notes here: https://gist.github.com/ianchesal/5c96c566ab99b60c2c557711fa...
We'll probably end up going with AWS though I might take a serious look at Azure.
still on heroku for now though. it's really aged but held up very well for popular use cases at a not obnoxious price.
* 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.
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
https://news.ycombinator.com/newsguidelines.html
https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
