Ask HN: Why are people paying so much for Vercel?
Vercel is just a layer on top of AWS, and they charge 100-200% more than what AWS charges. So, why do people pay for it when they can use AWS directly?
I personally can't stand it, and actively work to excise it from front-end applications though _because_ it's difficult to work with it as a 'part' of your world. Like a lot of dev-experiential products/business models, their moat only exists if they can keep you "in" vercel, the moment they become just nodejs + lambda to a customer, then their value-add ceases; So they make it difficult to "grow up" out of vercel -- for many shops that's fine, it will be all they need from it, so a premium for a polished nodejs+lambda+deployment+cdn experience is worth it.
But if you're a micro-arch with backend services running on your own cloud, vercel will always be the wart in your infrastructure making everything from network policy to authentication and monitoring or tracing more difficult.
If that’s the case, your web app is much less complex too, which reduces the need for a product that reduces complexity?
That doesn't need to be snarky. I know JavaScript and a variety of other languages, but if I'm picking a stack to work on the whole of, it's going to be a whole lot less context switching to use one language throughout, so JavaScript (in fact, TypeScript) it generally is.
I think the biggest "growing pain" is that C# runtime is multi-threaded so devs that are used to single-threaded Node.js environment need to understand object lifetimes. (Of course there are other differences as well, but the biggest IMO is understanding threading and object lifecycles in the underlying runtime.)
Syntactically identical promises/futures; syntactically identical lambdas; largely congruent tuples, classes, interfaces, generics, anonymous objects. C# 13 collection initializers are going to largely feel like JS array initializers.
Minor syntax differences can be picked up quickly. Frameworks like Nest.js are super similar to .NET Web API.
I use an apple computer and prefer to write my code in a simple text editor. Getting C# (or god forbid C++) just running in such a way that I can just focus on the code and not the surrounding environment or build tools took me long enough the last time I tried, that I decided to just not use C#.
brew install dotnet-sdk
dotnet new console -o ConsoleApp --aot
cd ConsoleApp
dotnet publish -o .
./ConsoleApp
Feel free to comment out `PublishAot` property in .csproj file if you don't want AOT (i.e. using libraries that want JIT), or use dotnet watch and run commands for quick iteration.
Note that for rich editing experience you do not need C# Dev Kit (which requires an account), only a baseline C# extension which has all the good bits. For running and debugging the project out of VS Code - upon first F5 press it will suggest generating config assets for .NET project it managed to find in an opened folder - just agree and it will work on the next F5 press.
You can also write C# with Neovim and csharp-ls.
Give it another look!
It's the same for a lot of similar things, Deno land, cloudflare workers/pages, etc. Things that reduce the friction to get something running online can be beneficial. They all have practical offsets and negatives too.
It's not a bad decision so much as a decision of where you derive value, and how much.
We're essentially a bunch of passionate engineers but none of us care for ops work including myself, I really want to focus on the code, not on the deployments.
Vercel actually kind of saves us money because the apps we work on are mostly internal tools that don't have millions of requests per minute and developer time is expensive. If vercel saves us one hour of engineering work per month compared to aws it's already cheaper and it definitely saves more than one.
This aligns with my own experience. I do deep backend systems stuff in my day job (just bringing this up to refute the whole "people just don't want to learn Linux" thing, I've even done kernel and eBPF work in the past and can still see value in Vercel), but still support some mostly front end Next.js apps for some small clients from back when I was freelancing.
The vercel ecosystem is perfect for that kind of work. I don't want to (and probably don't have the time) to be managing a bunch of cloud infrastructure for several varied small businesses outside of my day job. I need something where I get a call, go in and make a change, send them a nice preview link to preview the change, then deploy. Vercel makes that kind of business very easy to manage for me, and realistically none of these clients have the kind of traffic where a 100% price difference over managing it yourself would be saving them a lot of money or have a material impact on their finances or my pricing.
My clients get more value from retaining my services this way because I have more free time to help them make actual changes, and less time taken up managing their infra, which they wouldn't see and wouldn't understand and shouldn't have to care about. They pay me a pretty average to below average web guy amount to be their "web guy", not their "server/cloud guy".
If I switched from Vercel and started managing it all myself in AWS or Hetzner or something and trying to pinch pennies, I probably wouldn't be able to substantially lower my prices (time opportunity cost), but I WOULD probably have to drop some clients that have been with me a long time and that I feel some responsibility for.
I say this because, I develop moderately complex applications. We just always end up with some level of server side functionality, and even though Next.js is beautiful, the prevalence of these issues lead up to us self hosting. We do incur occasional issues scaling up, but so far, and despite intense applications with 5 figures of users, had had no issues with single/dual instance set ups. Any running a dockerized next.js application with auto restart is very easy for us.
I emphasize a lot with you - I too hate dev ops. But I suppose that comes from once spending 10 days migrating a service from VPS to AWS (back in the 10s mind - it would be easier now due to the standardization of environments)
But as to next.js features which can be caught out by the vercel resource limits - Do you not encounter those limitations, or do you work around them?
These have really generous free tiers. 180,000 vCPU seconds/mo, 360,000 GiB seconds/mo, 2m requests/mo. Resets each month.
The trick is that they scale to 0. So you can run a pretty sizable indie project/low volume internal tools for free. I run a bunch of stuff on GCR this way.
For example renting bunch of bare metal machines and running rke kubernetes implementation is orders of magnitude cheaper compared to using aws kubernetes, food has very low margins comparatively.
I’m not including engineering time that is spent on maintaining it but it is still cheaper by a lot for sure.
The ROI so far from a "financial" point of view has been terrible, I've spent probably close to 40-60 hours just to set up things and it's still held by stitches. My apps go down from time to time, deploying takes 5x the time and each new website/app I try to migrate is 1~3h from beginning to end vs a few minutes it'd be in Heroku.
I started with DigitalOcean+Dokku, but I'm thinking about investing another 20~50h and learn Coolify, I have only heard amazing things on Twitter (my main concern is that it's "the new cool kid in the block" and maybe not as good as people make it seem).
Edit: the ROI of learning new things has been amazing though, I wish I had done this earlier.
If you have enough traffic that your bill is > $1,000, put some time into switching.
But I can have my entire site deployed with CI/CD on Github to Vercel in less than an hour. If I'm doing client work, my clients can go preview new work immediately. I can test and build deployments on different branches and send test builds to stakeholders. It's got a lot to like and it ends up saving you a lot of money.
What is right for just starting out is rarely right for scaling up. Too many people wasting too much time on AWS instead of shipping their app first.
If your time is free, great. If you REALLY like ansible and want to do it at a discounted rate, also fine. But for most people and companies, dev time comes at a rate of ~50$ per hour. For that amount of hours you don't even get scalability, documentation, failover and a host of other things that Vercel provides.
Not to mention you’re learning transferable skills and not a proprietary stack from a company that may not exist in ten years.
Also Ansible was quite hip 10 years ago but I'd hardly call it a transferable skill anymore. Most shops seem to have migrated away from it already.
Depends if you’re running VMs (or bare metal). As cloud repatriation builds, I expect Ansible / Puppet / Chef demand to rise.
If you want to fork money over to Vercel every month, fine, but assume that this can’t be done reliably and safely while also not taking forever. Did I invest a lot of time in the past learning and honing these skills? Of course. Now they’re useful for something beyond a hobby.
I do wonder when we started losing interest about where our code is actually being executed ?
I don't think we did - it's more that new programmers aren't forced to learn it, and a lot of them are lazy and only here for the money. The result is a lot of people who think all that matters is shipping quickly. To them, it doesn't matter that this will result in lots more work down the road once the product needs to scale up.
*Might* result in lots more work, *if* the product needs to scale up. Program lazily and ship quickly enough and that isn't an issue.
[1]. https://sst.dev/
You can add to the built-in constructs via CDK (urgh) or pulumi (with SST ion).
The balanced approach is to learn basics of Linux, get a decent VPS or even a dedicated server (rented) and setup the stack. Plenty of documentation everywhere. Just ensure that you have good backups running.
And no, most people don't need complex setup or expensive hosting. We just choose to do so because either it is the cool thing to do OR we don't know any better.
I started as a BSD/Linux systems programmer / sysadmin, which required a working knowledge of infrastructure. Lack of ubiquitous resources meant higher stakes for correctness of work for the "whole stack". Now, there are as many abstraction and translation layers between the "code" and the hardware as people can come up with, despite there being excellent native tools (albeit, not sold by a vendor).
It's not worse or wrong, as long as you can afford it, but despite working on PaaS and IaaS up until a few years ago, I still don't understand why so many seem allergic to fundamental auxiliary skill sets like administration.
Even for stuff I deploy, my preference is a pretty bare host OS, and just using Caddy + Docker to deploy and reverse-proxy applications. It works fine at the small scale, and you can vertically scale a lot. But I'm not sure I would take that approach for a lot of various applications. It really just depends.
I do hope that the likes of Vercel, AWS Lambda, Cloudflare Workers and others start to align more from a developer perspective. I know hono.dev has worked to smooth over some of the edges a bit.
I'm also hoping to see similar efforts for other developer toolkits, I know there's several out there, but nice to see all the same. I think there may be some strides with WASM in the future too. shuttle.rs definitely looks interesting.
If you have a hammer, everything looks like a nail. Vercel type services are not necessarily the right answer in many cases just because it is easy to start with.
Look, I'm an SRE by heart and mind. I love tinkering with Linux, have around 10 different physical boxes (mostly Pi/NUC sized) running various distros for the fun of it.
Just because I want to and can doesn't mean everyone should DIY everything. For a random developer working on a business thing, or a side project, any time not spent developing is a time that doesn't bring any value - it doesn't help them advance on their work.
Managing a VPS is not trivial. Yeah, maybe you can get away with unattended upgrades and FTPing PHP files to it, if you're lucky. If you're not you'll pick the wrong VPS provider whose datacenter will go up in flames. Hope you remembered to do backups of everything.
Many tutorials/docs, and hell, whole pieces of software are "now draw the rest of the owl" style, with terrible security and reliability defaults. You cannot expect a random developer to be aware of the intricacies of what it means to not bind to localhost only (reminder that e.g. MongoDB used to by default to bind to all interfaces, and start without a password, so you got an insecure unauthenticated DB on the internet by default; another reminder that Docker automatically port forwards all your Docker containers' exposed ports to all networks, so same thing).
Yeah, it's not that hard, but you need a ton of knowledge to know how not hard it is, and even then there are caveats and tricks depending on a ton of things.
> but most people also don't need to use AWS ... that are another wrapper/layer and charge excessively
Yeah, this is bullshit. Yes, AWS is a wrapper around infrastructure, but unless your needs start and end with "VM with storage and a network", having pretty much any piece of software you can desire available at an API call with a clear billing structure is pure magic. How long will it take you to set up a a reliable object store? Message broker? Trace storage? PostgreSQL? All reliable, backed up, regularly updated, properly monitored. How much time will you spend in maintenance on all of those? A random small project probably doesn't need all of those, but arguing "most people" don't need AWS is like arguing "most people" don't need fancy high level languages which are just wrappers and should just code everything in assembly.
I have a version in the UI and the backend. If the UI is on an older version then I can either force reload the client or display a prompt to the user saying there's a new version of the app.
Is it more complex with react server components?
The Vercel sites on 76.76.21.0/24 IP addresses seem faster to me than many other sites submitted to HN.
If a site is particularly fast to connect, I will sometimes check to see what CDN/hosting it is using. I have done this with several sites that turned out to be using Vercel.
Yes, if you really want to save cost and forgo the convenience, bare-metal is also available on-demand, but you're going to end up building and managing your own subset of AWS on top of it, and that itself comes with a cost.
Time is money, and sure, once you reach some scale it will be efficient to move stuff to AWS, but for most projects it is not.
Sure, but if you're going to use it on "many" projects, then just learning these things once and building an appropriate abstraction layer for them pays for itself very quickly.
The premium for the "vercel flavored" wrapper around these necessary components is way too high.
No point building an abstraction, if none of your projects make money… it’s wiser to focus on building something people will pay for
If your plan is for none of them to /ever/ make money, then this is logical. If your hope is that one of them somehow does make money, you'll probably want your code to be flexible enough to be moved to a platform that won't destroy your profit margin over pay-as-you-go billing. At which point, the investment of effort will have paid for itself.
There's the problems you currently have, then there's the problems you want to have.
We’re updating everything to use SSO so we can do BeyondCorp-style auth on SaaS platforms. Vercel wanted to charge >$10k / year to get on their enterprise plan for SAML access, vs bill prior to that was ~$2.5k / year. The migration took ~30 mins and we expect our bill to drop to $500 / year. the toughest part was making sure we didn’t miss any build variables / secrets.
Is this as cheap as running base metal? No. But 30 mins to save $10k / year was worth it. And maybe the bigger point: what value are they really adding if it’s this easy to migrate off?
We can fit close to 40 .NET Docker Apps on a single 2vCPU/8GB RAM/20TB Bandwidth Server for €14.40/mo, which works out around $0.40/mo per .NET App. After a one-time setup to install Docker compose lets us deploy new .NET Apps by publishing to a new GitHub Repo and setting a few GitHub Action Variables.
Since we use SQLite and litestream.io for streaming replication to R2 we also avoid any expensive managed DB hosting costs.
We've also deployed a hono.dev/TypeScript/React/JSX Web App with Cloudflare Workers which at ~60k reqs/day fits within Cloudflare's 100k/day free quota so doesn't cost us anything yet. It's a pretty nice managed dev UX that I'd use again for any future (non .NET) Apps we want publicly accessible from the Internet.
Developers dont want to be working on managing AWS infrastructure, they just want to push code up easily.
It's also easy to optimise that cost later and cut it down.
The answer is the same: Convenience, SLAs, layers of abstraction…
Even AWS can be pretty expensive compared to other hosts, when most of the services are just amazon versions of readily available tools like Postgres or RabbitMQ that you could install on any cheap linux VPS and save a chunk of change. You just might have to learn a bit of linux sysadmin instead of stacking a teetering jenga tower of "abstraction".
Also, the truth is, for most small businesses, they don't need half the shit they are paying Vercel for. Most small businesses barely have any traffic so they're paying Vercel for a worldwide CDN and caching etc when a single AWS-micro instance in a single region would be fine, and setting up a single instance in AWS doesn't need complex server admin experience.
Spoken like either someone who has never ran those at scale, properly available, or has for so long they've forgotten how much they've learned along the way.
The majority of my career has been working on products that barely get 100k monthly active users. These projects don’t really need to worry about scalability because it’ll never happen. It hasn’t happened in the last 30 years, unlikely to happen in the next two years.
With that in mind why spend so much resources on complexity where the only benefits are to the engineers that get to add another buzz word to their resume?
I’m guessing the total percentage is less than 5, probably 1% seeing how Wordpress is still the most used framework on the internet.
I’ve worked at companies that cared about complexity and it was baked into the code. After the product was released we only got 500 users when the initial projection was 10,000 (this was a company selling Medicare advantage plans). The org was eventually disbanded.
We probably spent $20 million in additional “engineering” effort that was never used.
At some point you have to question why things are done a certain way if there aren’t material benefits.
100k MAU for a static blog and 100k MAU for an online game simulating a real world economy will have vastly different usage patterns of the underlying databases/message queues/etc.
> With that in mind why spend so much resources on complexity where the only benefits are to the engineers that get to add another buzz word to their resume?
It's not the only benefits, it's making things potentially easier down the line; more often than not it can be premature optimisation (preparing for a future that never comes), but there are also plenty of examples of companies outgrowing their initial infrastructure and having to spend lots of time on rearchitecting everything. A lot of that time can be saved by thinking a little bit beforehand and making things theoretically scalable.
Engineers know this too, which is why they choose Vercel over rolling their own infra. Frontend engineers get paid for building nice UXs that people will pay for, not mechanically implementing routing policies. So they’ll outsource that work to Vercel. It’s similar for backend engineers. What compounds this effect is that, at a small startup, you are on call in perpetuity. So you need to aggressively farm out support work for nonessential systems to service providers or else you risk being overwhelmed.
To take several numbers and examples from other threads, if you simply train on a technology for a week (40 hours) at $50/hour (@ $100,000 TC), that's $2000 for that week. Compare and contrast to some of the services ($1,200/year, $10K/year for SAML, etc) and you can begin to see the order(s) of magnitude difference between these "expensive" tools compared to a relatively "inexpensive" developer. From a business perspective, it can be a better ROI to have your developers work on products and buy the Operations.
and very cheap at the low end?
I feel like you either don't understand AWS or Vercel at all if you think they're equivalent or interchangable.
You will likely find that it targets a similar audience as heroku et al.
- Near instant Git deploys with links for each deployment
- Really easy to setup templates with "Deploy with Vercel" deeplinks
- Easy to setup web framework that works seamlessly with the platform
- All the add you need as your app grows (and yes, some you probably don't)
Once you're on its a pain to switch so its easy to stay on, so that's why so many people just continue.
If you liked Rails convention over configuration, you will likely appreciate Vercel. The only issue IMO is the full stack JS/TS approach. The JS ecosystem can be, let's just say, tough to navigate sometimes :)
but if you're in the stick to simple stuff - and not into the optimizing clicks business - deploying to cloudflare pages or just vps or cdn isn't much of a hustle.
Until the costs outweigh the benefits, I'll keep using it.
Using a Platform as a Service (PaaS) is a much better experience over using cloud service providers like AWS. The amount of premium that one pays for using the former and whether it's justified is a separate discussion.
Also this should be an Ask HN.
Vercel works fine if you're starting out and have low volume apps.
Also depending on what's costing you most, i.e. CDN you could easily swap URLs around to use Cloudflare or some other alternative
so you could go a long way before considering moving :)
Can you do this yourself? Yeah, obviously. But it's a build vs buy conversation and for a lot of people the value that this tooling gives you immediately is worth the buy.