Heroku has been running a second copy of my scheduler instance
openfolder.shHeroku has been an absolute dumpster fire. Every time their name comes up I can't help but mention that they deleted my account for inactivity, but have still been charging my credit card. No easy way to cancel because... they deleted my account.
Netlify did this to me too!
I have my startup with them and pay them a hefty bill. I had my personal websites on a second account (that should have been a free plan - one deploy every three years, next to zero traffic), and they deleted them and continue to bill me.
I've had multiple customer service interactions asking them to stop billing me and they're nothing short of rude and unhelpful. "We've told you the dozens of steps to take to get us to stop billing you" kind of responses from their top CS head. (Paraphrasing that quote, though I'm sure "we told you" is verbatim).
I think I tripped their janky system up when I started scaling one of my personal projects into a startup. I converted my personal account into my business account and moved my personal websites into a new account. This totally botched their system. The thing that gets me is how unhelpful they've been in dealing with the matter. It's not like any of this is my fault.
As soon as I get bandwidth to take my startup elsewhere, I'm gone and I'm never looking back. It's amateur hour over at Netlify. They're downright unpleasant to deal with.
I'm warning everyone I know to avoid them.
I have been mulling over switching from Netlify to Vercel for a while for my personal site too.
Netlify has weird defaults for everything. It caches almost nothing by default. I had to create a Netlify headers file to tell them that actually yes I would like my CSS, JS, and fonts cached.
Absolutely absurd I had to do that. Even for font files. Because as we all know, the font files change so often that we should never cache them /s
All manner of dumb things like this. Really the only thing keeping me on Netlify is that it has for handling built in. That and fear of changing DNS settings (I use Google domains).
Careful now, if you use Netlify’s _headers to do caching the obvious way, every time you push a new build, some of your users may get a broken site that can only be unfucked by clearing cache. I happened to have written about this problem a few days ago: https://news.ycombinator.com/item?id=35508640
OK so move to vercel and just dont use Netlify fam
> fear of changing DNS settings
Is that really a thing, with HNers of all people? You just use your registrar's/nameserver operator's web tool to point your DNS name to a new IP. Transferring your DNS to a new registrar might be a bit more involved but is guaranteed to be also possible by domain market regulation. Or maybe it is a problem of cache invalidation and/or lack of control over exact timing of DNS switchover? Or, idk, possibly Google-owned TLDs like .dev require Google Domains as registrar? Or does Google Domains (or GoDaddy or other big registrar) make transferring your domain difficult in a dark pattern way? Doubt it though, if even changing pointed to IPs appears difficult, which however shouldn't be something a registrar would have an interest in making difficult.
> Is that really a thing, with HNers of all people?
You want it to be hitless. Unfortunately DNS can take days to fully propagate and you may not see mistakes until it's too late to fix them. This can cause horrifying outages.
HNers should be respectful of DNS changes and plan accordingly.
I always setup a reverse proxy on the old server that tunnel all TCP traffics on port 80 and 443 to the new server whenever I migrated a website for this reason. Some network really take their time updating their DNS cache, even if your domain has low TTL.
You can change your DNS TTL to let say 5 minutes before you move to new IP. You can change it 3 days before the movement(?).
A story from 10 years ago providing services to the education sector:
I did exactly what you suggested, even leaving extra time (a full weekend!) for the DNS changes to propagate. What happened?
Turns out local authorities don't all respect DNS TTL settings and we had a major outage. I had to on-the-fly learn how to configure iptables to act as a proxy for the new server.
The "proxy" was still receiving requests 2 weeks later.
Fewer and fewer places actually respect DNS TTL.
Indeed, not sure what the anger in their comment was for.
Given that Netlify has very specific and unusual steps to setup in the first place, yes, it is a concern.
Render.com is a great replacement for both Netlify and Heroku. Check it out, static sites are even free.
> It caches almost nothing by default.
Now I have to go check and see if it's not caching our fonts. Geez, I just assumed...
> fear of changing DNS settings
I recently had to migrate DNS to Cloudflare to stop a 40,000 QPS DDoS attack. DNS migration was slow, but painless. As long as you plan accordingly and set up the new destination in advance, it should be fine. Hosting DNS at a DNS provider will give you extra flexibility in the future.
Yeah, it's absurd. Every page load the fonts were sent again.
I use google domains for dns too, just with netlify as the host.
I’ve always thought positively about Netlify. About to launch my startup there as well.
I was thinking about using their identity and access plug-in to build out member access only pages. Would Render have this capability? Or any other non-code recommendations?
File a chargeback each time they charge your card. The merchant has to pay the transaction fees both ways and a fee for the chargeback.
But don't do it if its Google. I had been charged for g-suite for domain that expired and someone else picked it up (and parked), long story short after 3 months of back-and-forth with "support" I gave up and started with chargebacks. It was 7 of them, each month one for $6, until one sunny day I woke up and my own gmail account, my youtube TV and Google Play on 2 Android devices all got blocked with messages popping up I never seen before. Also my friend - who used my wi-fi plenty when we worked on a project together, got his gmail frozen with equally weird messages with no answer how to appeal or follow up. Just middle finger and good bye.
edit: and no, they did not stop charging me for youtube TV. I actually had to get a new card number for my credit card for them to stop.
Yes, chargeback is pretty much a nuclear option. But in his case they'd already closed his account and are not responding, so time for the nukes.
Just a heads up, Salesforce owns Heroku, so if OP did this he had better be willing to lose access to anything else Salesforce related. Like Slack or Quip
And nothing of any real value would have been lost...
Geez, interesting heuristics with the WiFi, I guess the fucktards weren't checking SSIDs but noticed his account and yours shared the same IP, although that was in the past as well?
That's a good reason to never use Google ever. They did you a favor.
This seems totally outrageous and retaliatory -- especially for the friend? Can you get some media attention on this? Is this not a violation of some kind of TOS? It seems wildly thuggish. Did your google authenticator also get nailed? Please answer, because if it's "yes" I'm moving to authy IMMEDIATELY.
Gotta chargeback and tell the CC company to block. Then file complaint with their states AG.
Not necessarily easy, but you can dispute it with your credit card company.
This is why I use the git commit short hash as part of the identification of the service (eg: container name). Allows for quick check of which is the running code version and identify problems like these.
Wouldn’t help in this case if you redeployed the same version. I usually log the PID and some form of host ID.
That’s smart. I like it.
So you have to constantly rename it with each commit or what?
Kinda refreshing - within the ever growing genre of stories about Heroku's downfall into junk status - to find such an article with a higher level of detail and analysis of the origins of the problem.
There's one thing that somewhat surprised me though: this line:
> "In 2018 Heroku was pretty much the only option for a newbie like me to get started with web-development"
Was it? Really? I mean, I'm not saying the author did anything wrong in choosing Heroku at the time (after all, who could have known back then what a dumpster fire Heroku would turn out to be), and the commercial success Heroku achieved before going down the gutter shows that it must have had some good reasons going for it, at least on paper before the users are confronted with problems that make them judge the situation differently…
… but I don't really get where that "pretty much the only option" vibe would come from. Maybe It's just me having completely different selection criteria, but from my perspective, there were lots of other options to "get started with web-development" and Heroku was just one among many. I don't see at all by what measure Heroku would have seemed like "pretty much the only option"?
Let's say you have never deployed anything to production before, and you've worked through a tutorial in Rails or Django or whatever and just built your first web app, and it's 2018, what are your options?
There's the zoo of AWS. Maybe there's something there you can use - Lightsail came out I think in 2016 - but good luck trying to find it out of all the plethora of weirdly named services. Again, total beginner here, and AWS can be daunting even to experienced developers.
You can go with Linode or Digital Ocean. You would need to set up a VM with all the dependencies and make it secure. Oh and you'll need a database - should that sit on another VM? What about backup and restore? What about deployment? Sure, you can use Ansible, but that's yet another learning curve.
Render launched in 2019. Fly.io came out 2020. As far as I remember, there wasn't a competitor that offered the sheer convenience for the hobbyist beginner on the level of Heroku.
> You can go with Linode or Digital Ocean. You would need to set up a VM with all the dependencies and make it secure. Oh and you'll need a database - should that sit on another VM? What about backup and restore? What about deployment? Sure, you can use Ansible, but that's yet another learning curve.
An interesting perspective. I started using Linux as a kid, long before I started programming. When I wrote my first webapps, setting up a VM and database was the easy, familiar part. (I didn't really care about securing it.) It makes sense that if someone's first delve into any technical field is writing webapps, setting up a VM and database would be daunting.
Well yeah the hard part in running your own VMs is security (and backups), if you don’t concern yourself with this then it isn’t super difficult to diy. But how long will it stay online?
Ten years before that, I rented a cheap dedicated server and learned to use Webmin and Virtualmin. And it wasn't particularly complicated, Virtualmin gave you everything you needed with minimal configuration and you could find plenty of help online for the rest.
And it gave you a certain idea of how it worked, instead of operating on a black box.
> you've worked through a tutorial in Rails or Django or whatever
People underestimate the momentum of educational content. The Ruby on Rails tutorial book is a perfect example of guiding people into the Heroku walled garden - and at the time it was a reasonable decision that benefited the readers and (IMO) helped encourage them to go beyond starter-apps and actually put something in the wild.
I used a digital ocean ubuntu droplet with haproxy and certbot back when I first started off. Used their Postgres service for the database and only opened port 443 and 80 to public traffic. Droplet backups for backups if the vm needed and deployments were a manual git pull.
Sure a little complicated but there are plenty of good tutorials out there.
I would say Heroku for a new dev is not actually ideal. It hides way too much of the inner workings and makes it harder to learn about web development. I think it's more appropriate for a startup which just wants a ci/cd pipeline and some redundancy without investing that much time into it.
Digital Ocean's Postgres service launched in 2019.
I mean sure, you can learn all the other bits and pieces and I have no doubt learning them is valuable, but for a novice who just wanted to get something out there - beyond a static website - Heroku was hard to beat. Sure, it got expensive fast, and that's when you should learn how to manage hosting on your own. But at that point you had more of an idea what you needed and why.
Why is "learn more about how to properly host something" never an option for people? And in 2018! Suck it up and learn how to secure a VM, folks, especially if you're turning tutorials into production services. Most of those issues don't just go away when someone builds yet another expensive abstraction on top of a server, I promise.
As someone who took this advice around 2016 and setup servers for clients' sites I was building, the lesson I would impart here is: DON'T DO THIS
Maybe do this for small side projects and people who don't care if the site goes down.
Nothing more fun than trying to figure out what your 2016 self did to set up that fucking server based on a half-baked tutorial that was the top Google hit. And now it's crashing, and you don't know what the fuck is wrong. And the client is frantically texting you asking when the site will be up again.
The curse of knowledge gets people to forget how fucking steep the learning curve can be when every Linux thing is new. Especially when you're trying to debug a problem and every StackOverflow answer has you chasing wrong paths.
2023 me would have no problem doing this now, but also why the fuck would I want to waste my time mucking about fixing dumb problems. There's no need to prove how awesome I am at doing DevOps. I'm 100% ok paying a premium to let that be someone else's problem. I would rather solve fun problems than doing endless maintenance tasks.
>I would rather solve fun problems than doing endless maintenance tasks.
Not everything in your career will be fun and exciting, and what you consider to be maintenance that you can ignore, some of us consider fundamentals that one ought to know to be considered a serious professional. Food for thought.
Edit: the real lesson is to avoid doing mission-critical, production work for customers without the requisite knowledge. This is hard to hear, but if people don't, they'll overestimate their abilities and get into trouble. It's fine to be junior, it's not fine to oversell your skills.
Again, standing in the shoes of a beginner, you don't know what you don't know.
Heroku offered a path to easy, relatively secure deployment of a database-driven web application. If your aim is to just get something up and running - an MVP - it was probably fine, until it got too expensive. Maybe then you could buckle down and learn the "right" way, or maybe your business took off and you could just keep paying Heroku. If you're running a one-person SAAS, you might not have the time to spend on learning devops, when you have to fix bugs and add features and deal with customer support and sales. Sure, you'll hit that pain point when Heroku no longer works for you, but as detailed in the original post, that pain point may be years off.
Assuming they wanted a webserver + database and wanted to learn web stuff, not server admin / unix stuff to configure a LAMP stack or whathaveyou + certbot etc. Deploying on your own domain of legitimately daunting without a lot of prerequisite knowledge. Heroku automated a lot of that and some people learned it as the only way to deploy without learning the manual process first, and that's fine IMO.
Hi. I’m the author. First off, happy to hear you find that refreshing - it’s a really nice compliment to hear!
I, like you, hate blanket statements. Perhaps I should I’ve emphasized a newbie like me in that sentence? I really knew next to nothing about how web development, and specifically serving your site from a server, works.
What's an alternative to Heroku with the same level of ease and establishment? AppEngine is established but not easy, for example.
I still have some smaller projects running on Heroku. Was running a mid-scale one that we shut down for unrelated business reasons. It's been fine.
Yeah I'd only agree with that statement in like 2009. By 2018 there were a hundred equally fully-featured PaaS options to choose from.
In case it's not clear from the article, Nixpacks build OCI (essentially, Docker) images, so they are perfectly vendor neutral as far as I know. The ending ambiguously implies that Nixpacks may be undesirable vs using Docker, but actually it's just another way to build an image. Fly.io supports Nixpacks out of the box too, I believe, which makes it even easier to use them with Fly (although, you can also just push an OCI image directly to the fly.io registry and deploy with that, which I have been experimenting with in spare time as an option for using Nix itself to build an OCI image for Fly. I'm sure there will be an even nicer way some day, but it works for now...)
I'm sure the author knew this, but I wanted to iterate it in case anyone misunderstood.
OP here: I agree my phrasing is kind of problematic. Will rephrase shortly. Thank you for bringing that up.
Everyone can relate to the sad demise of Heroku at this time. Sad, because they could've dominated this space which still has a lot of issues.
Yet-another-infrastructure-group nailed it in their graphic about "what your infrastructure says about you?"... "Heroku => "You are either negotiating the pricing or deplatforming" https://www.yaig.dev/
Not sure if you have done this already but: If you rotate your database, redis and email provider passwords/tokens, the zombie process might still be running but will not have any effects any more.
OP here: that’s a good idea that did come up to mind (specifically rotating the Redis queue credentials). I was just sure Heroku’s gonna take care of this shit by now.
BTW, I’m not 100% sure it’ll work: if Heroku updates that zombie dyno’s environment variables, it may still have access to the new credentials :/ (My Redis instance is also a Heroku add-on)
> BTW, I’m not 100% sure it’ll work: if Heroku updates that zombie dyno’s environment variables, it may still have access to the new credentials :/ (My Redis instance is also a Heroku add-on)
If the configuration only read once during startup, the celery process won't use the new configuration unless it's restarted, right?
Heroku will automatically restart dynos if you change environment variables.
Rotate a token, but also mangle it and change to the correct one in code. eg: change database url from `postgres://` to `invalid://` and replace it in code.
This is a really smart idea! If you can't kill the process, make it completely ineffective by making it's api calls fail.
Probably related to https://status.heroku.com/incidents/2531 ("On April 6, 2023, between 21:20 UTC and 22:30 UTC, our Common Runtime customers were unable to provision dynos in the US and EU regions. This issue impacted starting/scaling dynos in existing apps, one-off dynos, builds, and release phases.")
Similar thing happened to me. Took a long time to realize there was a zombie Heroku instance running jobs.
That horror when you delete code but it's still running, you're just so confused...
I've forgotten how I resolved it, but man it was a pain to diagnose.
>> So is it Celery then? This awesome library has its fair share of complaints about duplicated task execution — most are due to misconfiguration. I scanned dozens of Stack Overflow threads and GitHub issues in Celery’s repository. Very few were relevant to my case, and none of the fixes were.
I was so annoyed by the pain of configuring Celery I stopped my project and wrote my own job queuing system.
Job and message queues are ridiculously over complicated - including the one I wrote. For trivial usage, job queuing should be zero config.
Hell yeah. And people it them for low-load situations where they could just use a db table or even just spawining a new process. 30k lines of code and several binary dependencies to run a handful of tasks because "it's the best way to do it".
If you just need to send a set of emails once a week, the lowly cron job is fine. You don't need celerybeat.
RQ or Huey are otherwise fine for anything more complicated. I've rarely run into a situation where Celery is better, but teams just use it because it's the "default".
+1 Celery is awful. Gave up on it a few years ago Now just use simple asyncio scripts.
i wanna love celery but it's damn bloated that i gave up on using it.
nowadays, if i need to connect to rabbitmq directly, i just use pika/aio-pika, which are lower level, but a LOT more reliable and lightweight.
> In 2018 Heroku was pretty much the only option for a newbie like me to get started with web-development
Free PHP webhosts have been around for 15+ years
you could even just throw up the job as an endpoint and have Zapier call it once a day or something! provided you can configure timeouts.
But nobody was writing trendy Medium posts about PHP.
When heroku first came out they introduced so many wonderful new things that blew the development community away. Many people including myself were inspired by their work. They did serverless before serverless even existed as a marketing concept.
But I guess having salesforce buying them out pretty much stalled their progress, and over time leading them to where they are today.
Anyway this is why we're building something to continue to innovate in this space, there is a lot to do. https://instellar.app
If Heroku is running some zombie instance of your app, what if you were to just kill the instance you control and let Heroku run the zombie instance? When your service goes fully down, you'll know they've killed the zombie instance, so you can then run a clean copy.
Not being able to update your code plus your app will completely crash randomly at some point between now and eternity - sounds great!
It's salvageable. Maybe spin up some kind of Unix watch that pings the zombie and deploys the new version. (but then, what happens if you get another zombie... crap)
It’s such a pity that Heroku has fallen so much. But I definitely wouldn’t run anything I cared about on Heroku these days. I ended up with my apps on NorthFlank which I’ve been very happy with. Railway also looks like a good choice, especially for those looking for a free plan.
An option might be to fix your message IDs, e.g. something like 20230413-userid@yourapp. Let the recipient's email server de-duplicate if you are not sure you can do better than at-least-once delivery on your side.
Friendly reminder that if you want Heroku-like deployments for simple projects you can go and roll your own with https://github.com/piku :)
Or dokku, which is to a very high degree compatible with heroku too.
Dokku is amazing if you just want to get your stuff deployed behind a https domain.
It allows the average developer (me) to spin up docker containers behind HTTPS subdomains together with postgres and other popular services from nothing within less than half an hour.
It supports kubernetes and stuff nowadays too.
Looks nice, I'll try it for my next little project.
or cloud66.com - creates an environment like Heroku but on your servers on any cloud, plus you get 1 free server per application.
Author and me have so much in common. From journalism to software engineering and our formative career shift years were spent on home made music apps. Now I’m wondering just how many of us are out there.
Author here. Small world! Would love to see your app if you don’t mind sharing. I’m @SHxKM on Twitter if you’d like to connect.
Unfortunately it’s abandonware now. It was called Showhopping and it would use the Scrobbler API and a list of your favorite bands and find out if any bands you might like (including the ones you listed) were playing in a given area any time soon. You could give it a location and a time range and it would give a list of shows playing on a map with a percentage back based on the likelihood that you’d enjoy the show. It was very lightweight with no sign up and I had it in mind people could use it like Yelp essentially, just ad-hoc.
https://lifehacker.com/showhopping-finds-upcoming-shows-arou...
Anyway, nice to meet you! I enjoyed your write up.
In 2017, I worked at a company that built a websocket based app and ran it on Heroku. We had this exact same problem and all 5 of the engineers at the time spent all day until we realized that we had socket connections still connected to some "ghost dyno".
I can't remember exactly what we did but I think we just kept deploying over and over again until the old one finally went away.
I guess any "easy" way to solve this right now is to put some authentication on the celery communication bus? I wonder if flower is being used.
Once auth is required for the celery processes, the old zombie wont have access. And if this occurs again OP could revoke access etc.
Great read, thanks!
I haven't heavily used Celery anymore for the past few years, but I remember trying to setup a HA Celery Beat schedule process with Kubernetes in 2019 and hitting this exact same issue! There was an alternative scheduler[1] storing its state in Redis instead of a local file, after a few fixes it was working pretty well: multiple beat processes running concurrently and not firing twice a scheduled task.
Don't know if that still works though.
Clearly the author still hasn't learned his lesson: his "no more vendor lock" solution is another vendor(s) - which is always able to vendor-lock him, again.
It is truly mind blowing on how many people keep falling for one of the oldest trick in IT : vendor lock-in.
===
No more vendor lock In 2018 Heroku was pretty much the only option for a newbie like me to get started with web-development. The landscape is very different now with providers like Render, Railway, and more
"always able to vendor-lock him" how?
Moving to another vendor while making it easy to move between vendors doesn't get you locked in.
> Heroku was pretty much the only option for a newbie like me to get started with web-development
How, exactly? What happened in 2018 that somehow made it impossible to just host a website?
Plenty of VPS options, with free tiers, in 2018.
When all you have is a Heroku, everything starts to look like a nail.
So what should he be doing, building his own data center?
Building your own data center isn't enough, land ownership is a myth as you'll still be locked in to your government via property taxes.
The real self-hosted solution is running your server off a solar powered yacht in international waters while transmitting and receiving all data via worldwide shortwave radio. Fire any customers not willing to invest in a SW-Ethernet adapter.
Shortwave radio depends on ionospheric conditions, which can be manipulated via nuclear blasts, ionospheric heating facilities, solar activity, and volcanos. Instead you must modulate a neutrino beam from international waters using a nuclear submarine for power. Fire any customers not willing to invest in kiloton-scale neutrino detectors.
Or just use the regular Internet but conquer the entire world first to make sure nobody can tell you what to do with it.
Rent a $5/month VPS, install a few packages? Or just run a linux vm locally.
So, rely on yet another vendor, or do as I suggested except without any semblance of reliabiliy.
Some one just starting out is not Google. They do not have Google's problems. They do not need Google's complexity, or a dozen layers of docker/terraform/k8s bullshit.
I really don’t understand this. Docker is not difficult to learn. K8s marginally more so.
Even if you don’t need HA it’s still worth it for a small team for ease of deploy.
Docker is difficult to understand in-depth, and, at least in my career, I haven't met too many people who do more than just skim a blog post and then think they know everything about Docker. This is how you get Docker punching holes in your firewall[1] and everyone acting surprised, because they a) didn't read the docs and b) have no idea how firewalls work.
Docker's interface might seem simple, but it adds an entirely new layer of complexity, with semantics only superficially understood by the vast majority of its users, and nobody ever seems to talk about Docker's negatives. A good rule of thumb might be: if you can't accurately explain how Docker works under the hood, or if you don't understand the OS components Docker itself uses, you shouldn't use it.
Dockerizing (what the author said he would do) is almost always worth it though.
Agreed, instead of "a dozen layers of docker/terraform/k8s bullshit" they just need they application code and some config that will take them an hour to setup once.
But there is no vendor lock-in here, VPS providers are interchangeable.
Sure, and the vendors the author mentions are interchangeable, too. Just at a different layer of the stack.
you clearly have no idea how things work outside of hobby projects, what about reliability? scalability, guaranteed uptime, resolving incidences,... You can account for all for that for yourself by creating a mini cloud provider.. good luck with that
Easy with the big words. All of that really depends on whether you're B2C or B2B, what kind of app it is and what kind of client. There's a company that has my code (Rails apps) running on Ubuntu Server VPSes with one guy who picks up the phone and restarts the server if something goes wrong (i.e. once a year). And the clients are multi-million businesses.
Yeah, common primitive sense is "big words". You understand that competitiveness and cloud certificatios based on some sort of a measurements of those "big words". I wonder how B2B or B2C is a decisive choice.
Half of the "robust" and highly complex solutions I see employing modern practices go down way more often than the simple version that the GP described.
Probably I don't know enough to argue, but those are the repeated arguments and which I agree with. In my current place, I know we can reduce the infra bill significantly if we move to renting physical servers or VPSs, but nobody would like to gamble on the "big words" (availability,..). We already have a system to deal with downtime in one region but it will take much more efforts that would lead to a minicloud if we want to go with the dedicated hosting.
What about those things? They're just glittering generalities, and an appeal to them is frequently used to justify adding ever more complexity to software.
The vast majority of startup web apps don't need anything more than a decent MVC framework (seriously, just use the web as designed) and a fast database. Keep a warm spare of your application running if a box goes down and you need to cut over or something. No, it's not sexy. No, they probably won't invite you to speak at Re:Invent. But your shit will work and it'll be cheap and FAST.
I've seen way too many basic CRUD apps, written by developers who mean well, needlessly overcomplicated in the name of things like "scalability" and "reliability". And guess what? They were some of the least scalable, least reliable applications. I'm talking applications where low double-digit requests per second for basic web pages caused the entire thing to shit itself.
So no, you don't actually need your own mini cloud provider to run a solid service. You just need to know what the hell you're doing.
I don't really see avoiding vendor lock as the most important part of creating systems. It's definitely nice to have and all things being equal, I'll take a solution that avoids vendor lock over a solution that doesn't. But I'm still going to keep using AWS Lambda for example, since I can get pretty good value out of it despite it being not a portable solution.
https://caprover.com FTW - just host everything yourself. you can host multiple services without any problem on a 5$ VPS nowadays, especially if you using just a simple SSR webapp, some lightweight backend and sqlite db. as soon as your hardware is not keeping up with your demand, you make enough money to scale vertically.
Even though it won't help you now, instead of celery-once I highly recommend using the celery-redbeat scheduler which uses a distributed lock to ensure that only one scheduler instance is active. It's plug&play and compatible with all the traditional task scheduling methods which beat supports.
That doesn't help in this particular case when the zombie node is running old code that can't be modified.
Heroku really helped me get started. I then stated experimenting with running docker compose locally and finally was able to run my own kubernetes. You don't need Heroku as you progress. It takes time. Be patient.
I vote for moving to Render!
My god I wish I could short Heroku stock.
Looks really expensive. And weird pricing. I click "pricing" and it gives me per user costs. Wat? I thought I was hosting stuff, not managing teams. Click on +Computing costs and it's like $0! $0! $0! Check the fineprint and its like 4GB RAM and 2 CPUs is $85/mo, or you can get the same at DigitalOcean for $24.
Then add Postgres for another $95. Or if you're cheap like me, you self-host that in your $24 droplet and pay nothing extra.
And then they want you to pay for Crons....instead of just running a cronjob on your dedicated compute?
What is this world coming to?
Everyone charges for convenience. A lot of people don't want the headache to run and secure their own Postgres, for example. It's a trade-off, same as servicing your car vs just handing it off to a garage mechanic.
Yeah I understand charging for convenience... kinda. Markup is too big IMO. Should be like 10-20% more not 3x. And then they should make up the difference in volume because why would you not choose the more convenient platform if they provide the same great hosting but managed or easier to use.
It's a managed service. You pay a premium for it. Features like their blueprint file make it worth the price IMO - https://render.com/docs/blueprint-spec
If you are working on a team and you want everyone to be able to spin up a copy of the production infrastruction for each pull request then PaaS is the way to go. If you just have some random one-off production environment and you are happy to either manage the state of a HDD or a k8s cluster yourself (which comes down to will more so than skill) then DO is the way to go.
> It's a managed service. You pay a premium for it. Features like their blueprint file make it worth the price IMO - https://render.com/docs/blueprint-spec
Looks like k8s yaml.
> If you are working on a team and you want everyone to be able to spin up a copy of the production infrastruction for each pull request then PaaS is the way to go.
But I get that with k8s + docker too. Everything's containerized. Just run the config, it even brings up the cron jobs.
> or a k8s cluster yourself (which comes down to will more so than skill) then DO is the way to go.
Yeah...that's the rub. Takes a few weeks to learn. Worth the time cost to save the $ cost and vendor lock in IMO.
> Takes a few weeks to learn.
As I said, there’s more of a issue of wanting to maintain your infra than knowing how to.
Its been a little while since I looked at Render and their pricing definitely used to be a lot simpler. Charging per user is just stupid. And then weird compute costs with plans like "Pro Plus" and "Pro Ultra". "Web Services" and "Private Services". WTF is this shit.
I’m curious as to your experience using Render? When I tested it out, it seemed very clunky I was seeing build times in excess of 30 minutes even for small projects.
Really? I've only used it for small projects but I would see build times of around 5 minutes for Node back ends and NextJS front ends.
The article doesn't mention billing, I hope you weren't billed twice? :o
Please pay attention to this comment OP. The zombie dynos were likely not “closed”. Look at your bill closely.
Maybe Dokku us an option to self host and maintain Heroku code
I just hope you won't be billed twice too
There's been a lot of complaints about Heroku recently, and I think there will be a lot more.
I believe that Heroku under the Salesforce's management is a different product that a lot of developers are used to.
It's now in a Cash cow stage: https://en.wikipedia.org/wiki/Cash_cow. Salesforce is trying to extract as much revenue as possible from the company they bought. And guess what - the real margins doesn't come from SMBs and individuals - they come from larger companies with large contracts.
Heroku is no longer building a product for ordinary developer's side-project, or for SMBs or early-stage startups. They are building a product for larger accounts paying 25k+/month.
Customers that are expecting the old Heroku experience just need to look somewhere else. There are a lot of alternatives (such as render.com and many others). But the truth is, none of them is as good as Heroku. Luckily, these PaaS alternatives are getting better as we speak.
There are also different alternatives, such as https://stacktape.com (disclaimer: I'm a founder). For example, Stacktape offers PaaS-like experience directly within your own AWS account. It offers developer-friendly experience, and allows developers to deploy their apps entirely on their own, while at the same time offering the full power and flexibility of AWS.