Daniel sent us a prompt about the thing that's been quietly bothering every developer who grew up on VPS hosting but now deploys to Vercel or Netlify. The question is basically: when you push to Vercel and it builds and deploys, where does it actually go? Like, physically, conceptually, where does the website live? Because with a VPS you can point to a building in Frankfurt. With serverless, it feels like you're throwing your code into a cloud and hoping for the best.
This is one of those questions where the answer reveals that the entire mental model most of us carry around is about fifteen years out of date. And the prompt actually names the tension perfectly. The old model is: I have a computer, it has an IP address, it runs a web server, end of story. The new model is: I push code, and somehow it's everywhere and nowhere simultaneously. Which sounds like nonsense until you understand what's actually happening under the hood.
The everywhere and nowhere bit is what gets me. That's the magic trick. And I don't like magic tricks in my infrastructure.
So let's demystify the whole thing. The first thing to understand is that when you deploy to Vercel, your site doesn't go to one place. It goes to many places, and which place serves any given request depends on who's asking and where they are. But let's back up just slightly and talk about what Vercel actually is architecturally. Vercel is not a hosting company in the traditional sense. It's a deployment and edge compute platform built on top of other people's infrastructure. Under the hood, Vercel runs primarily on Amazon Web Services. The compute layer, the build infrastructure, the storage, a lot of it is AWS. But Vercel adds a global edge network on top, and that edge network is what makes the magic happen.
When I deploy to Vercel, I'm actually deploying to AWS, just through a very opinionated intermediary.
Yes, with a massive asterisk. The build step happens in Vercel's own build infrastructure. When you push to your Git repository, Vercel spins up a container, runs your build commands, generates your static assets or your serverless functions, and then distributes the output across a global content delivery network. That CDN is the destination. Your site doesn't live on a server. It lives on an edge network. Specifically, Vercel's edge network spans over one hundred locations worldwide. When someone types mywordprompts.com into their browser, the DNS resolution routes them to the nearest edge node, and that node serves the content. If it's a static page, it's already cached there. If it's a dynamic request that needs a serverless function, the function gets executed at an edge location close to the user, not in some central data center.
The answer to where is my website is: pick a city. It's in all of them.
And this is the fundamental shift from the VPS model. With a VPS, you have a single point of origin. Everyone in the world requesting your site hits that one server. If you're in Tokyo and your server is in Frankfurt, every request crosses half the globe. With Vercel's edge network, the request from Tokyo hits a node in Tokyo. The request from São Paulo hits a node in São Paulo. The content is replicated everywhere. So there's no home server. There's a distributed system of caches and compute nodes.
Here's where my old-school brain starts asking uncomfortable questions. If the site is cached everywhere, what happens when I deploy an update? How does the whole network know to invalidate everything simultaneously?
This is actually one of the more elegant pieces of Vercel's architecture. When you deploy, Vercel doesn't overwrite your existing deployment. It creates an entirely new deployment with its own unique URL. Every deployment is immutable. So the previous version of your site is still sitting there, perfectly intact, on its own URL. The new deployment gets distributed across the edge network, and only once it's fully propagated does Vercel update the DNS or routing rules to point your production domain to the new deployment. The old deployment stays available until you explicitly delete it. That's why you can instantly roll back to any previous deployment. The old version never went away. You just repoint the domain.
That explains the instant rollback thing, which I've always found borderline miraculous. But let me push on the edge functions piece, because static assets I understand. HTML files, CSS, JavaScript, images, they're just files. Cache them everywhere, done. But the prompt mentioned a database. MyWordPrompts has a database. If someone visits the site and the page needs to query the database, where does that query actually run?
Okay, this is where we need to distinguish between two different things Vercel offers. There are edge functions and there are serverless functions, and they're not the same. Edge functions run on Vercel's edge network, which is built on Cloudflare's Workers infrastructure, or more precisely, Vercel Edge Functions are powered by the same kind of lightweight runtime that Cloudflare Workers use. They run at the edge, very close to the user, and they're extremely fast to start up. But they have limitations. They can't run full Node.They're designed for lightweight operations like URL rewriting, authentication checks, A/B testing, geolocation logic. Things that need to happen in under fifty milliseconds.
Serverless functions are the heavy lifters. When you write an API route in a Next.js application and deploy it to Vercel, those become serverless functions. They run on AWS Lambda, in a specific AWS region. By default, that region is us-east-1, which is Northern Virginia. But you can configure it. Your serverless function gets packaged up, uploaded to AWS Lambda, and when a request comes in that needs that function, Vercel's edge network receives the request, forwards it to the Lambda function in the configured region, the function runs, queries your database, returns a response, and that response gets cached at the edge if appropriate.
The database query is still happening in a specific place. It's not edge-computed magic. It's a Lambda function in Virginia talking to a database that's probably also in Virginia or somewhere nearby.
And this is the part that often gets glossed over in the serverless marketing. Your database has a physical location. If you're using something like Neon, which the prompt's author uses, that's a serverless Postgres database, but it still has a home region. Neon's architecture separates compute and storage, so you can have multiple read replicas in different regions, but the write operations all go through a primary. So if your serverless function is in us-east-1 and your database primary is also in us-east-1, great. If your user is in Tokyo and the edge node in Tokyo forwards the request to us-east-1, the user is still waiting on a trans-Pacific round trip for the dynamic content. The edge only helps with the static shell.
That's a crucial distinction. The edge caches the static stuff, but any database-dependent content still has to travel from wherever the function runs to wherever the database lives.
And this is why Vercel and other platforms have been pushing toward truly edge-native databases. There's a whole ecosystem emerging. Turso, which is built on libSQL, distributes read replicas globally to edge locations. Cloudflare has D1. Neon has read replicas. The idea is that eventually your database reads can happen at the edge too. But we're not fully there yet for most production applications. The writes still need to go somewhere central for consistency.
The honest answer to where is my website is: the static parts are everywhere, the dynamic parts are in a specific AWS region unless you've done extra work to distribute them, and the database is wherever you put it. That's less magical but more useful.
I think this is what the prompt is really getting at. There's an understandable discomfort when you can't point to a single machine. But the reality is that even the old VPS model was an abstraction. You were pointing to a virtual machine that was itself running on a hypervisor on a physical server in a rack that you'd never seen. The difference with Vercel is just that the abstraction is higher and the distribution is wider.
The VPS abstraction was thin enough that you could pretend it was a real computer. You could SSH into it, check the uptime, look at the disk usage. With Vercel, there's nothing to SSH into. You can't log into the server because there is no server. There are thousands of them, and they're ephemeral.
Ephemeral is the key word. A Vercel serverless function doesn't exist until a request comes in. When a request arrives, Vercel's routing layer determines it needs a function, AWS Lambda spins up a container for your function if one isn't already warm, the function executes, returns a response, and then the container hangs around for a little while in case another request comes in. After a period of inactivity, it gets destroyed. The function has no persistent state, no fixed address, no permanent existence. It's a ghost that materializes on demand.
Which is both elegant and slightly unsettling. Like a restaurant that only exists when you're hungry.
That's actually a perfect analogy. It's a pop-up restaurant. The kitchen materializes when you place an order, cooks your meal, serves it, and then disappears. You don't know where the kitchen was, and you don't need to. The meal arrived. That's the contract.
The prompt mentioned something interesting about the economics of this. With a GPU, the argument for serverless is obvious: GPUs are expensive and idle most of the time, so sharing them makes sense. But for a website, the economics are different. A basic VPS costs five or ten dollars a month and can handle decent traffic. The case for serverless web hosting isn't obviously economic in the same way.
That's a sharp observation, and it gets at something I think a lot of developers feel but don't articulate. For a site like MyWordPrompts, a VPS would absolutely work fine. The reason to use Vercel isn't cost savings on infrastructure. It's operational cost savings. It's not having to configure Nginx, not having to manage SSL certificates, not having to set up CI/CD pipelines, not having to worry about server updates, not having to configure load balancers, not having to think about any of it. You push to Git and it's live. The value proposition is that Vercel eliminates an entire category of work.
It's paying a premium to not be a sysadmin.
And for a solo developer or a small team, that premium is often worth it many times over because the alternative is spending hours on infrastructure instead of building features. The cost isn't the server. The cost is the time.
Let me ask a question that might sound naive but I think gets at something real. When I used to run sites on a VPS, I knew exactly what would happen if the server went down. The site would be down until I fixed it. What happens if part of Vercel's infrastructure fails? If an AWS region goes down, or an edge node has problems?
This is where the distributed architecture actually provides resilience that a single VPS can't match. If one edge node goes down, the DNS routing automatically directs traffic to the next nearest healthy node. If the AWS region where your serverless functions run has an outage, that's a bigger problem because your dynamic functionality goes down. But Vercel's static caching means that even during a backend outage, any content that was already cached at the edge is still served. Visitors might see stale content instead of an error page. And for many sites, stale content is vastly better than a five hundred error.
The failure mode is graceful degradation rather than hard downtime. You lose dynamic features but the site still loads.
And Vercel also does something interesting with what they call Incremental Static Regeneration, or ISR. With ISR, you can specify that certain pages should be regenerated in the background at a set interval. So even if your database is temporarily unavailable, the edge continues serving the last successfully generated version of the page. The user never sees an error. They just see content that might be slightly out of date. For a podcast website, that's basically ideal. Nobody needs real-time consistency for episode pages.
The ISR thing is underrated. It's basically saying: generate the page once, cache it, and if the cache is stale, serve the old version while you regenerate in the background. The user never waits for a build.
And this connects back to the prompt's question about edge caching. The way edge caching works is that when a request hits a Vercel edge node, the node checks if it has a cached copy of the requested resource. If it does and the cache hasn't expired, it serves it directly from the edge. No serverless function invocation, no database query, nothing. The response comes from memory on a machine that's physically close to the user. That's why static sites on Vercel can feel impossibly fast. The content is already sitting there, a few miles from the user, waiting.
When the cache is stale or missing, the edge node acts as a reverse proxy, forwarding the request to the origin, which in Vercel's case is the serverless function or the static file storage. Then it caches the response for next time.
And this is where the CDN layer comes in. Vercel's edge network is essentially a globally distributed reverse proxy with caching. The origin is Vercel's infrastructure on AWS. The edge nodes are the public-facing part. When you deploy, Vercel pushes your static assets to all edge nodes and configures the routing rules so that dynamic requests get forwarded appropriately. The whole thing is orchestrated by Vercel's platform, but the physical infrastructure is a combination of Vercel's own edge hardware and AWS's cloud.
I want to zoom in on something you mentioned earlier about the build process. When I push to GitHub and Vercel starts building, what's actually happening in that build container? Because I've noticed the build log shows a lot of activity, and then it says deployed, and I don't see any file transfer step.
The build process is fascinating and it's one of the parts of Vercel's architecture that's genuinely innovative. When you push code, Vercel clones your repository into an isolated build container. This container has access to your environment variables, your build settings, and it runs whatever build command you've configured. For a Next.js site, that's typically next build. The build process generates a few things. Static HTML files for pages that can be pre-rendered. JavaScript bundles for client-side interactivity. And serverless function bundles for API routes and dynamic pages.
Then those outputs get distributed?
Yes, but the distribution happens in a very specific way. The static assets, the HTML, CSS, JavaScript, images, those get uploaded to Vercel's global edge network. Each edge node gets a copy. The serverless functions get packaged and deployed to AWS Lambda in your configured region. And importantly, Vercel also generates a routing manifest that maps URL patterns to either static files or serverless functions. This routing manifest is what tells the edge node what to do with each incoming request. Should it serve a cached file? Should it forward to a Lambda function? Should it apply some middleware?
The routing logic itself is distributed. Every edge node knows the full routing table for every deployment.
And that routing table is versioned per deployment. When you deploy a new version, the new routing table gets distributed alongside the new assets. The cutover from old deployment to new deployment is essentially a routing table swap. That's why Vercel deployments are atomic. There's no moment where half your files are updated and half aren't. The entire routing configuration changes at once.
That explains why I've never seen a Vercel deployment where the site is in an inconsistent state during the deploy. It's either fully the old version or fully the new version.
And this is a huge advantage over traditional FTP-based deployment, where you're uploading files one at a time and there's inevitably a window where some files are new and some are old. Vercel's atomic deployments eliminate that entire class of problem.
Let me ask about cold starts, because this is the thing everyone talks about with serverless. When a serverless function hasn't been invoked in a while, there's a delay while AWS spins up the container. How bad is that in practice on Vercel?
It depends on the runtime and the size of your function bundle. For small Node.js functions, cold starts on AWS Lambda are typically between one hundred and five hundred milliseconds. That's noticeable but not terrible. For larger functions or functions using less common runtimes, it can be longer. Vercel mitigates this in a couple ways. First, they keep functions warm by sending periodic health-check requests. If your site gets regular traffic, your functions are probably warm most of the time. Second, Vercel's edge functions don't have cold starts in the same way because they use a much lighter runtime. Edge functions start in under fifty milliseconds.
For a database-backed API route, you're probably using a serverless function, not an edge function, so cold starts are a real thing.
And this is one of the tradeoffs of the serverless model. With a VPS, your application is always running, always ready to handle requests. No cold starts. But you're paying for that readiness twenty-four seven. With serverless, you only pay for execution time, but you accept the possibility of occasional cold start latency. For most applications, it's a worthwhile tradeoff. For latency-sensitive applications, you might need to keep functions warm or use a different architecture.
The prompt also mentioned Cloudflare Pages and Netlify as alternatives. How do their architectures compare?
The broad strokes are similar. All three are edge-deployed, Git-integrated platforms that handle build and deployment for you. But there are meaningful differences under the hood. Cloudflare Pages runs on Cloudflare's own global network, which is massive, over three hundred cities. Their serverless functions are Cloudflare Workers, which use the V8 JavaScript engine rather than Node.This means they start faster, often under five milliseconds cold start, but they have a different API surface. You can't just drop in a Node.js application and expect it to work. Netlify is more similar to Vercel. They also use AWS under the hood for their serverless functions, and their edge network is their own, though it's smaller than Cloudflare's. Netlify Edge Functions are powered by Deno, which is another JavaScript runtime.
The choice between them is partly about which tradeoffs you prefer and partly about which ecosystem you're already in. If you're using Next.js, Vercel is the path of least resistance because Vercel literally created Next.
That's not a coincidence. Vercel's business model is built around Next.They open-source the framework, and then their platform is the best place to run it. It's a classic open-source business model. The framework drives adoption, the platform monetizes that adoption. And to their credit, they've been very good stewards of Next.It's a great framework, and the integration with Vercel is seamless because they control both sides.
It does mean there's some vendor lock-in. If you build your site with Next.js features that only work on Vercel, you're tied to Vercel.
That's the concern, and it's a valid one. js does support self-hosting. You can run a Next.js application on any Node.But some features, like Incremental Static Regeneration with on-demand revalidation, the middleware system, and certain image optimization features, work best or only on Vercel. The framework is open-source, but the platform provides proprietary value on top. That's the bargain.
I think the environmental angle the prompt mentioned is interesting too. Is there any data on whether edge-deployed, serverless architectures are actually more energy-efficient than traditional hosting?
There's not a lot of rigorous independent research on this specific question, but the theoretical case is reasonable. In a traditional hosting model, you have servers running twenty-four seven regardless of load. At three in the morning, when nobody's visiting your podcast website, the server is still drawing power, still generating heat, still consuming resources. In a serverless model, when there's no traffic, there's no compute. The functions scale to zero. Now, the edge nodes themselves are always running because they're serving many different customers, and the CDN infrastructure has its own energy footprint. But the overall utilization is much higher. You're sharing physical hardware across many tenants, and the platform can optimize resource allocation in real time.
It's the difference between everyone having their own car idling in the driveway versus a shared fleet of taxis that only run when someone needs a ride. The fleet is more efficient even if the taxis themselves are identical to the cars.
That's the analogy. And cloud providers have gotten very good at optimizing data center efficiency. AWS, Google Cloud, they've invested heavily in renewable energy and cooling efficiency. A shared, highly utilized data center is almost certainly more energy-efficient per request than a collection of underutilized VPS instances or on-premises servers.
I want to circle back to something the prompt said that I think is worth unpacking. The prompt said: if someone asked over coffee where MyWordPrompts is hosted, in the old model you could say AWS in Frankfurt and point to a building. In the new model, you have to say there's some magic going on. And I think the real answer is: you can still say where it's hosted. It's hosted on Vercel, which runs primarily on AWS, with functions executing in a specific region, and content cached globally. The building is still there. It's just that the building is not the point anymore.
The physical location hasn't disappeared. It's just become an implementation detail rather than the defining characteristic of the deployment. When you deploy to Vercel, your serverless functions are in an AWS data center somewhere. Probably Virginia, unless you've configured otherwise. Your database is in a data center somewhere. Your static assets are in edge caches all over the world. The magic isn't that the physical servers don't exist. The magic is that you don't have to think about them.
I think that's the real answer to the prompt's question. The destination that Vercel deploys to is: an AWS data center for compute, plus a global edge network for caching and routing, all orchestrated by Vercel's platform layer. There is no single home. There's a distributed system with multiple homes, and which home serves any given request is determined dynamically based on geography, load, and caching state.
The reason this feels like magic compared to the VPS model is that the VPS model gave you a single, stable address. You could memorize the IP. You could put it in your hosts file. The serverless model gives you a domain name and a platform, and the platform handles the rest. It's a higher level of abstraction, and abstractions always feel a bit like magic until you understand what they're abstracting.
Here's a concrete question. If I wanted to know exactly which AWS region my Vercel serverless functions are running in, how would I find out?
In your Vercel project settings, under Functions, you can see and configure the function region. By default, it's Washington D., which maps to us-east-1. You can change it to other regions like San Francisco, London, Frankfurt, Sydney, and a few others. But you can only pick one region per project. All your serverless functions run in that single region. If you want multi-region function execution, you need to use edge functions or a different architecture entirely.
If your audience is global and your database is in Virginia, and you're doing dynamic database queries on every request, users in Australia are going to have a noticeably slower experience than users in New York.
And this is the fundamental limitation of the current serverless model. The edge caching solves the static content problem beautifully. But dynamic content still has a home region, and users far from that region will experience higher latency. There are ways to mitigate this. You can use a distributed database with read replicas. You can use edge functions for lightweight operations. You can design your application to be as cacheable as possible, using ISR and CDN caching to minimize the number of requests that actually need to hit the origin. But at some point, if your application requires real-time, personalized, database-backed responses for users all over the world, you're going to hit the limits of what a single-region serverless deployment can do.
Which is why companies at scale eventually move to multi-region architectures, with database replication and regional failover. But for a podcast website, that's wildly unnecessary.
For MyWordPrompts, a single-region serverless deployment with good edge caching is more than sufficient. The content is mostly static. Episode pages change infrequently. The RSS feed gets regenerated when new episodes are published. Even the dynamic parts, like search, can be handled by a serverless function without noticeable latency for most users. The architecture fits the use case.
I want to talk about one more thing, which is the domain and DNS piece of this. When you set up a custom domain on Vercel, what's actually happening at the DNS level?
Vercel recommends that you point your domain's nameservers to Vercel's DNS service, or at minimum create a CNAME record pointing to cname.When a user's browser resolves mywordprompts.com, the DNS query eventually reaches Vercel's DNS infrastructure, which responds with the IP address of the nearest edge node. But here's the clever part: that IP address is dynamic. Vercel's DNS uses anycast, so the same IP address routes to different physical servers depending on where the query originates. The DNS response itself is geographically aware.
Even the IP address is an illusion. The same IP points to different machines in different places.
Anycast is a networking technique where multiple servers share the same IP address, and the internet's routing infrastructure automatically directs traffic to the nearest one. It's been used by CDNs for decades. Cloudflare built their entire business on it. Vercel uses it for their edge network. So when you look up the IP address for mywordprompts.com and you're in London, you get routed to a London edge node. Someone in Singapore doing the same lookup gets routed to a Singapore edge node. Same IP address, different physical machines.
That's elegant. The DNS system, which was designed to map names to fixed addresses, has been repurposed to do geographic load balancing without the user ever knowing.
It's one of those pieces of internet infrastructure that works so well that most people never think about it. Anycast has been around since the late nineties, but it became a core part of CDN architecture in the two thousands. Today, basically every major CDN and edge platform uses it. It's the reason you can type a domain name and get a fast response no matter where you are.
To summarize the answer to the prompt's question: when you deploy to Vercel, your static assets go to a global CDN with over one hundred edge locations, your serverless functions go to AWS Lambda in a single region of your choice, your database stays wherever you put it, and a geographically aware DNS system routes users to the nearest edge node. The destination is not one place. It's a distributed system that presents a unified face to the world. The magic is real, but it's engineering, not sorcery.
That's a perfect summary. And I'd add one thing. The reason this architecture has become the default for modern web development isn't that it's cheaper on a dollar-per-request basis. Often it's not. It's that it eliminates entire categories of operational work. You don't manage servers. You don't configure load balancers. You don't rotate SSL certificates. You don't patch operating systems. You don't set up monitoring for disk usage. All of that is handled by the platform. For a small team or a solo developer, that's worth a lot more than the few dollars a month you'd save on a VPS.
It's the difference between being a developer who occasionally does operations and being a developer who just develops. And I think that's what the prompt was circling around. The discomfort of not knowing where your code is running is real, but it's the discomfort of letting go of a responsibility you didn't actually want in the first place.
You trade control for simplicity. And for most projects, that's a trade worth making.
And now: Hilbert's daily fun fact.
Hilbert: In eighteen seventeen, the mineralogist John MacCulloch documented a peculiar find in the Outer Hebrides: a sample of aragonite that, when held over a candle flame, emitted a phosphorescent glow visible for nearly two minutes after the heat was removed. That's roughly the same duration it takes a modern microwave to pop a bag of popcorn.
A rock that glows for as long as it takes to make popcorn.
I have questions about the testing methodology. But I'm not going to ask them.
That's probably wise. This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you want more episodes, you can find us at myweirdprompts.com or wherever you get your podcasts. We'll be back with another one soon.
