Unreliable deployments are my experience as well. I also encountered unexpected and unannounced downtimes surprisingly often.

I was excited about fly, but ended up sticking with digitalocean. I have only had one issue with deployment reliability there (when they changed their build tooling for Python applications on the apps platform), but they responded quickly with a fix and shortly after announced the change and potential issues to all customers. Fly is not like this, and as a hobbyist I don’t have the time or energy to deal with their platform’s issues. I’d rather pay for something I can depend on. DO has been amazing in that regard, and their tooling is excellent.

I’ve used vercel in a professional context and wouldn’t use it for personal work. The markup is crazy and the tooling isn’t appealing enough to justify the cost. This is definitely a subjective matter as opposed to reliability and communication which are objectively necessary. Vercel just “rubs me the wrong way”, and I’m sure many people here love it.

I really don’t understand how people can trust platforms like Vercel, Fly.io over robust could providers like Cloudflare, AWS or Azure.

I mean, Vercel has its usefulness, it’s so well integrated with the NextJS stack, it totally makes sense for small amateurish projects since it saves you time and money… but once you want to push to production, have real customers and satisfy them reliably, these platforms can’t compete with the big ones.

My uptime monitoring business made a similar migration (AWS Lambda to fly.io), and I ended up rolling it back a few months later.

I wrote more about the move to fly.io here: https://onlineornot.com/on-moving-million-uptime-checks-onto...

and (part of) the move back to AWS here: https://onlineornot.com/scaling-aws-lambda-postgres-to-thous...

Edit: forgot that second link doesn't actually explain that I moved off fly.io, will write a follow-up.

> Edge functions are cost-effective as you only pay for the actual CPU execution.

> We have over 1000 monitors, and the monthly cost to run them would be $150.

> While on fly we only have 6 servers with 2vcpu/512Mb It cost us $23.34 monthly ($3.89*6).

So edge functions are in no way cost-effective right? People using lambda functions are getting ripped off, they could just buy a couple of VPS.

Why is Fly apparently so unstable? I like many love the idea, but get a little scared by the many many anecdotes of issues.

What are they doing that makes it unstable? Lots of new locations spinning up that shake bugs loose? Cost-reducing refactorings that reduce stability?

I love a good migration post-mortem, thank you to the author for publishing it! There's a bit of extra detail I'd be curious to know, as someone completely unfamiliar with both Vercel & Fly.io:

Re: "we required a lightweight server" as one of the drivers to migrate -- how did deploying to Vercel impede this? What specific business/operational issues was this causing?

Re: migration issue of large container image -- what business or operational issues did the large container image size cause? Why was it necessary to shrink the image size, when it could be previously ignored?

edit: it appears that fly.io previously had a 2GB container image size limit, relaxed on 2023/08/11 to "roughly 8GB" -- https://community.fly.io/t/docker-image-size-limit-raised-fr...

I joined a project that was fully deployed on Vercel. We routinely ran into issues with limitations, outages and sharp edges. Our junior devs had also taken advantage of Vercel specific features (I remember a Vercel specific request object in the code specifically).

Given all the problems and the vendor lock in from tight coupling I advise everyone I discuss Vercel with to avoid them like the plague.

Every day I need to add a new feature to my app, I am grateful I picked fly (serverful) rather than Vercel. The fact that as far as I'm concerned, it's just a computer, is incredibly useful. We've added long-running tasks, background jobs, scheduled tasks, side-car processes, custom-code execution, etc etc. Then, the fact that I can run something like Redis or Metabase within the same VPN with just a dockerfile is incredibly empowering. And just giving up basic things like SSH access to your server seems like an incredibly short-sighted thing to do. Maybe I'm too old, I just don't get it.

I would be curious to know the performance using node.js as runtime, given that at the moment there is no evidence that bun on a real application offers better performance

I've tried Fly.io probably 3 times. I've never gotten a simple Node.js project to deploy correctly. Meanwhile, I deployed the same projects to DigitalOcean and Render without a single change successfully every time.

From one toy to another.

Next up: Migrating to Hetzner.

TLDR: They could have done it cheaper, quicker and without adding DevOps to their workload with just migrating to Cloudflare.

- Vercel: 150$/m.

- Fly: 23$/m ( + managing servers and devops)

- Cloudflare: 11 $/m.

--- (original comment)

They could have gone from Vercel to Cloudflare to reduce their costs.

But that would have been almost no work to create a blog post about :p

https://developers.cloudflare.com/pages/framework-guides/dep...

Did some raw math.

Cloudflare is 0,15$ per million requests and Vercel is 2$ per million requests.

Their calculation for Vercel was: 77,600 * (2/1,000,000) = 0.15c per monitor monthly

So that's ~0,011c per monitor monthly on Cloudflare. That would be a bill of 11€ per month ( vs 150 € per month on Vercel ). Probably less, since Cloudflare doesn't count idle CPU time, which is very relevant in this use-case ( outbound http calls) ... - https://blog.cloudflare.com/workers-pricing-scale-to-zero/

Which is cheaper than their VPS of 23.34$ / month.

And would have avoided managing servers + security to their workload...

> Additionally, we have not discovered a quick method to rollback to the previous version

I feel like this should be a high priority. Deployments should be quickly reversible so that a livesite caused by a bad deployment can be mitigated quickly.

I’m curious if you looked at Heroku (I work there). You mention functions (which we don’t support), also servers (which we definitely support). I’m curious if that’s it or there was more to the decision.

Hmm if they hole point is save memory and smaller sizes, and since they are willing go with Bun (very experimental type of tech), then they should also just tried Deno.

I have been using Vercel for production NextJS apps and have been very satisfied.

these issues aren’t particularly severe and strike me as the kind of thing you’d generally run into switching hosts.

I find it interesting that people seem to be trading short term gains with long term reliability and maintenance costs. This glut of 0-friction deploy services lull people into a nice false sense of security.

But in actuality you are wasting hours, days, weeks of time when they become unreliable, support is unresponsive, or something unexpected pops up.

There is a huge advantage (outside of amateur, low importance projects) for putting in place - at the beginning - an infrastructure that is dead simple and reliable. AWS, GCP may have some upfront complexity but provide advantages in terms of reliability, knowledgeable support, and proven track records.

I would never recommend these current platforms to be used for building a long term business on top of. I have been tempted by the siren song of one click deploys but in the long run so much extra time is wasted.

This is what happens when you do HN-frontpage-driven development. I mean, they use Bun (which I’m sure will be great in a couple years’ time) and quickly ran into an fd leak in it. Does that sound like a production grade runtime?

However, I suppose it’s good for content marketing. You’re not going to make front page by choosing boring old technology (unless you’re migrating back to boring old technology after failed HN-frontpage-driven development).

> I really don’t understand how people can trust platforms like Vercel

It's not an apples to apples choice. The people who use Vercel don't know anything about how to deploy on AWS. That's the whole point of Vercel. Whether or not they can be trusted is really orthogonal to the reason they were selected as a provider. But that said, they're just a layer over AWS so why should they be significantly less trustworthy? I haven't used Vercel in production, but I have used a similar "layer over AWS" service (Aptible). The problem where wasn't to do with QoS or support, but rather that the narrowing of the functionality of the "interface" (which is pretty much the point) ends up causing frustration when you want to integrate with other stuff you're doing in AWS.

Vercel is great for pre-prod ethereal environments for testing and CI. But they desperately want to sell you their enterprise stack which is completely inadequate, and will drag their feet for months if you just want to sign the damn “pro” version.

Some people avoid large providers, since large providers have approximately no incentive whatsoever to keep you, specifically, as a customer. I.e. large providers will happily raise their prices, alter the deal, throw you under the bus, disable your account, delete all you data and then refuse to talk to you. They can do this because, when they look at the big picture, you don’t matter to them. And since doing this saves them some money, they all do it.

I worked at ZEIT (before it became Vercel) and if they've retained even a 10th of their engineering culture then they're solid, if not a bit "niche" in what and who they target.

Anecdotal, sure, but it'd be hard to quantify it.

Plenty of people end up building vercel-but-worse out of CI pipelines on aws or similar, doesn’t strike me as crazy to keep using it well past the prototype stage for projects that for its constraints.

Whats the use case for edge computing like Fly.io. I have yet to figure it out the use case where a edge provider is necessary. That is, having a database on the edge.

Several SaaS companies are pushing for Next.js as their main SDK, that is how real customers end up in Vercel.

The only platform you can truly trust is the one you handcraft down to the NAND gates.

Edit: Nevermind, wrong thread. Vercel does honor DCMA, of course, though.

> People using lambda functions are getting ripped off, they could just buy a couple of VPS.

A non-zero amount of our CICD pipelines are "perform API call with secret pulled from SSM/Secrets Manager". They happen 1-2 times per day and take less than a 5 seconds to run on each invocation. We currently have a burstable EC2 instance running 24/7 to handle these which costs us ~$5/mo. My napkin math says that this would cost us ~$0.01/month to run these as lambdas. More to the point though, we're limited in concurrency on these. It's pretty common that they all get triggered at the same time, it would be ideal if we could allow for an "unlimited" number of these to run. This sort of workload would be great to run for lambda functions, the engineering cost of implementing it just doesn't ever make sense.

If we paid someone $150/hour to spend half a day on it, right now our break even point is probably 5 years...

Edge functions are cost effective, the problem is that they are comparing from Vercel.

Vercel is basically a dev friendly wrapper for tier 1 services: https://news.ycombinator.com/item?id=35774730

Eg. Vercel is 25x more expensive than eg. Cloudflare Workers. Raw guess would be that their 150$ bill would have become 6$.

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

Eg. Image resizing

> Vercel : 5$ / 1000 requests

> Cloudflare : 9$ / 50.000 requests

Edit for comment below:

That's a blog post. I got my info from here:

https://www.cloudflare.com/plans/

See: image resizing

> 50,000 monthly resizing requests included with Pro, Business. $9 per additional 50,000 resizing requests

If you're bursty and only run 1000 invocations every few days or weeks and otherwise you run it 0 or 1 times per increment then you can end up spending a lot less than that estimated server cost with fly.io no?

In what universe is the difference between $23/mo and some amount less than that incomparable? That's what? Two paid users worth of revenue? $23 per month is a rounding error. It's one T-shirt. It's the cost of a few minutes of your time. If you're running a business and you're worried about saving ones of dollars on hosting, you need to reconsider how you're spending your time and how your business makes money.

Both are free for business,

It's not "just" a computer, a computer is a whole bunch of complicated stuff that I don't want to have to care about. I want to write some code and have it run and I don't want or need to care about the details of how that happens as long as it works reliably. Being able to ssh into your server is giving you more tools to fix problems, sure, but mostly problems that you created for yourself by having a server in the first place.

It is beyond me why anyone but the most pre-revenue bootstrapped projects would spend $150k+/yr eng hours into saving $100 month on infra. Projects like this are trying to make $1m+/yr in revenue.

Founder of OpenStatus here: We can't use Cloudflare because there's no way to execute in a specific region, if you know how to do it let me know

Can you deploy 700MB Dockerfiles to Cloudflare, as they mention as a minimum requirement in the article?

> I find it interesting that people seem to be trading short term gains with long term reliability and maintenance costs. This glut of 0-friction deploy services lull people into a nice false sense of security.

I find it interesting as well. I agree that it's a false sense of security, and there is no real long-term gain from avoiding the one time paydown of deploying to a big 3 cloud services provider. Still, I think the impulse reflects something a very real pain, and something I find my team continuing to face as we try to manage a the operationally minimalistic stack we can get away with on AWS -- poor DX.

It does still boggle my mind that AWS still doesn't have a Heroku-esque happy path DX that lets you get started easily and then add in complexity on an as needed basis rather than forcing it to get the most basic thing running. It seems like every minor customization requires in AWS parlance spinning up a Lambda to do something that should be a first class feature in the platform by default. Will I migrate off the platform? No. Would I use a simpler, opinionated interface that let me focus on my application and not arcanae, if AWS made it avaiable? Absolutely.

Azure actually had a nice Heroku-like service that served me well for a couple years. I forget what it’s called, but it’s probably the one reason I’d ever consider choosing Azure if that was ever my call to make.

This! Can't agree more, I think we share the same idea, that's what the tool we're making is about: https://github.com/mify-io/mify/. It generates backend service code in a scalable way from the beginning, so that you wouldn't have to rewrite and move services to some other platform.

It's better to have good architecture from the beginning, but I understand why people choose these platforms - they are saving a lot of time in the initial development, that helps them iterate quickly. What will happen next is that people spending time and resources to perform costly migrations, and some do this more that once.