Serverless container or edge function? Same promise, different runtime
Cloud Run ships a whole Docker image into a private room; Cloudflare Workers and Vercel Edge load just your code into a V8 isolate. Runtime, startup, freedom and location follow from that.
"Serverless" is an ops promise: nobody on your team provisions or patches a server. It says nothing about how your code runs once a request arrives. A serverless container and an edge function share the label and almost nothing underneath it, and four things follow from that difference: runtime, startup time, freedom, and location.
1. Runtime
Take Google Cloud Run, a serverless container runtime. You build a Docker image that contains your application, its runtime, its libraries, and the system dependencies it leans on, then deploy that complete image. The platform runs the whole thing as a container.
It's a private room for your app, already packed with almost everything it needs. Nothing is shared with a neighbour, and the contents are exactly what you put in the Dockerfile.
An edge function works differently. On Cloudflare Workers or Vercel Edge you deploy your code, not an image. There is no Dockerfile and no OS layer of your own.
That code is placed inside a small V8 isolate, running alongside many other isolates in the same process. Each isolate has its own heap and globals, so tenants can't see each other's variables, but they all share one engine.
2. Startup time
To start a new container instance, the platform has to create the container, then initialise your runtime, then initialise your application. Each step is real work, and it happens before the first request is served.
With an edge function the V8 engine is already running. The platform only has to load your code into a lightweight isolate.
Much less machinery has to start, so your code is usually ready much faster. Not zero, but a different order of magnitude from a container cold start.
3. Freedom
Inside a Docker image you bring your own language, framework, system packages, and native dependencies. If it runs on Linux, it runs in your container.
At the edge you get only what the edge runtime supports. Traditional filesystem access, child processes, some standard library APIs, and arbitrary native binaries may simply not be available.
4. Location
An edge function can run close to the user, but that doesn't move the rest of your infrastructure. If your database still lives in a distant region, every query makes the entire round trip anyway.
Choosing
Use edge functions for redirects, request filtering, stateless authentication checks, and similar small, latency-sensitive work. Use serverless containers for complete backend services, native dependencies, and heavier processing.
Neither is universally better. One gives you more runtime freedom; the other gives you faster startup and execution closer to the user.