If you're building API routes, processing webhooks, or running background tasks, you don't need a server running 24/7 for each one. Serverless computing lets you deploy functions that spin up on demand, scale with traffic, and cost nothing when idle, since the platform bills only for active execution time.
This guide explains serverless computing and when to use it, including 10 practical examples.
Link to headingWhat is serverless computing?
Serverless computing is a cloud execution model where functions are deployed on cloud infrastructure and executed on demand. The model emerged in response to traditional server-based architectures, in which teams provisioned and maintained always-on infrastructure regardless of whether the application was actively handling requests. AWS Lambda launched in 2014 as the first major serverless offering, and every major cloud provider now supports the model. The difference from server-based hosting is who manages the infrastructure. Servers are still involved, but the provider handles provisioning, scaling, and teardown so teams can focus on application logic.
In practice, when something triggers a function (an HTTP request, a file upload, or a webhook callback), the platform spins up an isolated environment, runs it, and tears it down once execution completes. Persistent state lives in external systems such as databases or object storage, whereas in server-based architectures, the application process can hold connections and state in memory across requests.
Because each environment is ephemeral, there's a tradeoff. When a function hasn't been called recently, its previous environment has already been reclaimed by the platform, so the next request requires a fresh environment. Initialization, dependency loading, and connection setup all happen from scratch. The resulting delay is known as a cold start, and on latency-sensitive routes, it can push response times beyond the threshold at which users perceive delay.
Link to headingFunction as a Service (FaaS) vs. Backend as a Service (BaaS)
Function as a Service (FaaS) is a model in which teams deploy custom business logic that runs in short-lived, provider-managed environments. Backend as a Service (BaaS) provides managed capabilities such as authentication, storage, and messaging that teams consume via APIs.
Most production web applications combine FaaS and BaaS. If your app uses a managed auth provider for login and serverless functions for the checkout flow, you're already working across both sides.
Link to headingWhy teams are adopting serverless
Once teams understand the model, the practical appeal becomes clear. Three benefits come up most often:
Pay-per-execution pricing: Billing per invocation or per unit of active execution time means costs track closely with actual request volume. Moving from provisioned servers to serverless typically drops spend during low-traffic periods because there's no idle capacity to pay for.
Auto-scaling without capacity planning: The platform spins up additional instances automatically in response to request volume. Traffic spikes from product launches, marketing campaigns, or webhook bursts get absorbed without any manual intervention.
Faster time to market: A route handler, an upload processor, or a CMS webhook can ship as part of the app rather than as a separate service to provision and maintain.
These advantages compound as the application grows, because each new route or webhook deploys the same way, without adding more work for the team.
Link to headingAPI backends for web and mobile applications
API backends are one of the clearest serverless fits because a function maps neatly to an API route, scales with demand, and deploys alongside the frontend code that calls it.
Link to headingRESTful and GraphQL APIs
REST APIs work well in serverless environments because each route can run as its own function, so there's no shared application process handling unrelated requests. Auth callbacks, form submissions, search endpoints, and cart actions are all short-lived, independent requests that don't need persistent connections.
GraphQL can also run in a serverless environment when teams want to aggregate data behind a single endpoint, though the fit depends on query complexity, resolver depth, and whether the resolver layer stays within the platform's execution limits.
Link to headingHandling traffic spikes with zero configuration
Serverless API backends shine when traffic is uneven. A launch-day burst, a newsletter campaign, or a product drop can quickly spike request volume, and the platform handles scaling without any pre-provisioned servers. In a server-based setup, handling that spike means either over-provisioning capacity in advance or scrambling to scale manually. On Vercel, Next.js apps get zero-configuration scaling. Other frameworks may need vercel.json adjustments.
Request-time performance benefits from small bundles and fast initialization because smaller bundles reduce the time the platform needs to spin up a fresh environment. Serverless works best when the handler performs focused work and hands off long-lived state to external systems such as databases or object storage.
Link to headingEvent-driven automation and workflows
Event-driven patterns work well with serverless because functions only need to exist for the duration of an event. No long-running process waits for something to happen.
Link to headingTrigger-based actions on file uploads or database changes
A file upload can kick off validation, metadata extraction, or thumbnail generation without a separate worker fleet. The same pattern applies to CMS publishing flows, where a webhook might update cached content, regenerate a page, or send a downstream notification.
Instead of running another always-on service, teams attach the processing directly to the event. The compute scales to zero when there's nothing to handle, so the team pays nothing between events, unlike a worker service that runs continuously whether or not there's work in the queue.
Link to headingOrchestrating multi-step business processes
Some web workflows span multiple steps, such as sign-up provisioning, order confirmation, and post-purchase email sequences. Serverless functions handle these individual steps well, while a separate orchestration layer manages retries and state transitions.
Link to headingMedia and file processing
The same event-driven model applies to media, where images, documents, and files work well because each task starts with a request, finishes quickly, and doesn't need to run continuously.
Link to headingImage resizing and on-demand media transformations
Image resizing is a textbook serverless use case. You store the source asset, generate the required variant at request or upload time, and cache the result for future requests. Avatars, product galleries, article thumbnails, and responsive images all work well with this model.
This works for processing that finishes quickly and affects what the user sees, not offline batch pipelines on a separate schedule. Vercel supports this through Image Optimization, which handles common variant generation without custom function code.
Link to headingOn-demand document transformation
Document preview generation is another strong fit for serverless. A function can convert a PDF page into an image, extract text for search indexing, or produce a browser-friendly preview the moment a user uploads or requests a file.
Apps where documents are part of the core workflow are a good fit for serverless architectures, including proposals, receipts, contracts, and support attachments. Deploying the processing as a function on the same route that needs it means there's no separate service to maintain.
Link to headingScheduled jobs and batch processing
Serverless handles time-based automation well because scheduled tasks are inherently short-lived: they run, complete their work, and the environment tears down until the next execution.
Link to headingCron-style tasks in a serverless environment
Managed schedulers can invoke functions on a time-based trigger, replacing the need for a dedicated cron server. In a web application, this might look like clearing expired sessions, syncing metadata, sending digest emails, or refreshing cached content.
Small, bounded jobs that run on schedule and exit cleanly fit this model well. On Vercel, teams can configure this through Vercel Cron Jobs when the job directly supports the web app.
Link to headingParallel processing for large datasets
Some workloads benefit from breaking a larger job into concurrent function calls that run in parallel. On Vercel, parallel fan-out patterns work well for splitting image generation, document previews, or outbound webhook delivery into smaller tasks that each complete within normal function limits.
Link to headingMicroservices and webhook integrations
Web applications also need to communicate with external systems, and serverless fits well as the receiving layer, handling inbound events and passing data to downstream services.
Link to headingDecoupled services that scale independently
A serverless function can own a focused responsibility, such as account provisioning, billing callbacks, search suggestions, or notification dispatch. In a monolithic server-based setup, a traffic spike on one endpoint means scaling the entire application. With serverless, each function scales independently, so teams only add capacity where demand increases. The goal isn't to decompose everything into tiny functions, but to isolate the pieces that benefit from independent scaling.
Link to headingConnecting third-party systems with serverless functions
Webhook handlers are one of the strongest serverless patterns for web teams. Payment providers, identity services, CMS platforms, and internal tools all emit HTTP events, and a serverless function can validate, persist, and respond to those events as soon as they arrive.
For higher-volume integrations, teams usually place a queue between the inbound webhook and downstream processing to keep the HTTP response fast. When the need is closer to routing or request rewriting, that logic can live in Routing Middleware instead.
Link to headingWhen serverless is not the right fit
Workloads that depend on persistent connections, long execution times, or in-memory state don't map well to short-lived function environments. Here are the most common ones:
Long-running or always-on processes: Persistent WebSocket connections, stream processors, and anything that needs continuous execution don't work well with serverless time limits.
Latency-critical paths with cold start sensitivity: If a function regularly takes more than a few seconds to respond because of startup overhead, a persistent service is the better choice. Vercel's Fluid compute helps reduce this cold start frequency.
Heavy batch processing: Data pipelines and large processing jobs that run independently of any web application need dedicated compute designed for sustained workloads.
If your workload doesn't fall into any of those categories, it's probably a good candidate for serverless.
Link to headingHow to choose the right serverless use case
If you can draw a straight line from a user action or system event to a function that does bounded work and exits, it's a good fit. On Vercel, here are the most common examples:
API routes and webhook handlers: Functions that respond to HTTP requests, process inbound events, and return results.
Media transformations and image processing: On-demand resizing, format conversion, and document previews triggered by uploads or requests.
Event-driven automation: CMS publishing flows, file upload processing, and downstream notifications that fire on application events.
Scheduled tasks and cron jobs: Recurring maintenance work like clearing sessions, syncing data, or sending digest emails.
Authentication and personalization: Request-time logic that checks credentials, evaluates feature flags, or routes users based on location.
When a task requires persistent compute or runs independently of any web-facing component, pairing Vercel with dedicated tooling for that layer is preferable.
Link to headingServerless computing on Vercel
Vercel's serverless capabilities are built around three primitives: functions, middleware, and Fluid compute.
Link to headingDeploying Vercel Functions
If you're using Next.js, route handlers in the app/api/ The directory automatically becomes Vercel Functions with no additional configuration. SvelteKit, Nuxt, Remix, Astro, and other supported frameworks follow their own routing conventions, and Vercel detects the framework and applies the right build settings. Functions support Node.js, Python, Go, Ruby, and Rust runtimes, and auto-scale based on demand.
Link to headingRunning request-time logic with Routing Middleware
Routing Middleware lets you run code before a page renders by creating a middleware.ts file at your project root. It executes globally on every request before the response is cached or served and runs on the Edge Runtime by default to minimize latency. If you need Node.js APIs, you can switch runtimes with a single config export.
Link to headingReducing cold starts with Fluid compute
Traditional serverless reuses warm instances but limits each one to a single request at a time, so when all warm instances are busy, the platform has to spin up a new one, triggering a cold start. Fluid compute removes that constraint, allowing a single instance to handle multiple concurrent requests, so the platform routes more traffic to warm capacity. It's now the default for new Vercel projects. Existing projects can enable it in settings without code changes, and the pricing model charges only for active CPU time, not for idle time during I/O waits.
Link to headingStart building with serverless
Serverless has moved beyond simple API handlers, and for web teams, the most important growth is still happening inside the web stack. When a task moves beyond web-facing logic, pairing Vercel with dedicated compute for that layer keeps each part of the stack on the right infrastructure.
Whether you're starting with an API route, a webhook handler, or a cron job, get started on Vercel to see how Vercel Functions, Routing Middleware, and Fluid compute work in your application. For production workloads that need higher concurrency, the Pro plan offers increased scaling limits.
Link to headingFrequently asked questions about serverless computing use cases
Link to headingWhat is the difference between serverless computing and traditional cloud hosting?
Serverless runs code on demand and scales automatically. Traditional hosting requires provisioning servers that stay running whether they're handling requests or not. The key difference is who manages the infrastructure: with serverless, the provider does.
Link to headingIs Vercel a general-purpose serverless platform?
No. Vercel is a frontend cloud platform built for deploying and scaling web applications. Its serverless capabilities target frontend and full-stack web use cases, and teams running persistent backend services, heavy batch jobs, or non-web compute typically pair Vercel with other tools for those layers.
Link to headingCan serverless handle high-traffic production workloads?
Yes, particularly for web applications with bursty or uneven traffic patterns. API routes, webhook handlers, media endpoints, and personalization logic are strong candidates because they scale automatically with demand rather than requiring capacity to be provisioned in advance.
Link to headingWhat are the biggest limitations of serverless architecture?
The main constraints are execution time limits, stateless function execution, cold start latency on initial requests (though Fluid compute reduces this on Vercel), and tighter coupling to the provider's tooling and APIs. Scoping serverless to event-driven work, with clear boundaries and by storing long-lived state in external systems, keeps you well within these constraints.