Serverless Web Hosting Explained: When It Fits and When It Doesn’t

Serverless hosting promises a simpler way to run web applications: deploy code and let the platform handle servers, scaling and infrastructure capacity. For some applications, that model can remove a large amount of operational work. Static pages can be served from a global network while small backend functions run only when requests arrive.

The word “serverless” can also create the wrong expectation. Servers still exist; the provider manages them. Developers still need to think about databases, regions, execution limits, security, logs, deployment and cost. A workload that fits the request-driven model can be elegant, while a long-running or highly stateful application may be simpler on a traditional server or container platform.

This guide explains serverless web hosting in practical terms and shows where it works well, where it becomes awkward and how to evaluate it without architecture hype.

What Serverless Web Hosting Usually Includes

A modern serverless website often combines several managed components rather than one traditional server.

Typical components

• Static HTML, CSS, JavaScript and images served from a CDN.
• Functions that run backend code when requested.
• Managed database or external data service.
• Object storage.
• Authentication service.
• Queues or scheduled jobs for background work.
• Managed logging and observability.

Cloudflare’s current Workers documentation describes deploying static assets and Worker code together across its network, while Vercel documents Functions that run server-side code without customers managing the underlying servers.

See Cloudflare Workers static-assets documentation and Vercel Functions documentation for current examples of this architecture.

Static-First Sites Are a Natural Fit

Documentation, marketing pages, portfolios and content sites can often generate most pages during a build. The resulting files are easy to cache globally and require little server-side work for each visitor.

Benefits of static delivery

• Fast CDN delivery.
• Low origin compute requirements.
• Simple scaling for traffic spikes.
• Reduced attack surface compared with a constantly running application server.
• Predictable deployment artifacts.

Dynamic features such as contact forms, search or user authentication can be added through functions or external services while the majority of the site remains static.

For edge caching fundamentals, see our CDN for websites guide.

Functions Turn Requests Into Short-Lived Compute

Serverless functions are pieces of backend code invoked by requests or events. A function might process a form, create an API response, generate an image, verify a webhook or read data from a database.

Vercel’s current documentation describes function invocations that scale with incoming requests and can scale down when demand disappears. AWS API Gateway similarly supports web APIs connected to services such as AWS Lambda.

See Amazon API Gateway documentation for another common serverless backend pattern.

Good function characteristics

• Request-driven.
• Relatively short execution.
• Stateless between invocations or state stored externally.
• Can retry safely.
• Does not depend on a local disk remaining available.
• Scales independently.

Automatic Scaling Is Valuable but Not Infinite

One of serverless computing’s main advantages is that the platform can create more execution capacity as traffic increases. That can be useful for unpredictable bursts.

However, every platform has concurrency, duration, memory, request or account limits. Vercel’s current function documentation, for example, publishes plan-specific duration and memory limits. Cloud providers also enforce quotas and downstream services may become the bottleneck even when functions scale.

Scaling dependencies to check

• Database connection limits.
• Third-party API rate limits.
• Queue throughput.
• Function concurrency quotas.
• Outbound network capacity.
• Authentication service limits.

A thousand functions trying to open a thousand database connections can overwhelm a database that was designed for one hundred. Serverless scaling must be designed across the full system.

Cold Starts and Startup Overhead Still Matter

Serverless platforms may create or wake execution environments as demand changes. That startup work can add latency, particularly for large applications, uncommon runtimes or infrequently called functions.

Modern platforms use techniques such as instance reuse and concurrency optimization to reduce startup overhead. Vercel’s current “fluid compute” model, for example, is designed to reuse compute more effectively. Even so, developers should measure real request latency instead of assuming all functions start instantly.

Reduce unnecessary startup cost

• Keep function bundles focused.
• Avoid loading huge libraries for simple requests.
• Reuse database connections where the platform supports it.
• Measure first-request and warm-request latency separately.
• Choose a runtime suited to the workload.

Data Locality Can Matter More Than Function Location

Running code near the user sounds ideal, but an edge function may still have to contact a database thousands of kilometers away. That adds network delay to every data request.

Vercel’s documentation specifically recommends placing functions close to their data source when database latency matters. This is an important serverless principle: compute and data should be designed together.

Possible strategies

• Run functions in the database region.
• Use a globally distributed database where appropriate.
• Cache frequently read data at the edge.
• Minimize sequential database round trips.
• Use read replicas for geographically distributed reads.

Our hosting data center region guide explains data locality and regional latency in more detail.

Traditional Relational Databases Need Special Attention

A traditional application server may maintain a stable pool of database connections. Serverless functions can create many short-lived concurrent requests, which can stress connection limits.

Evaluate database fit

• Does the provider offer connection pooling or a proxy?
• Does the database scale to bursty concurrent access?
• Can functions reuse connections?
• What is the geographic distance?
• How does pricing behave at high request volume?

Do not select a serverless web platform without testing the database under realistic concurrency.

Long-Running Jobs May Need a Different Service

Functions usually have execution-duration limits. A job that processes a multi-hour video, performs a large data migration or maintains a persistent socket may not fit a short request-response function.

Alternatives include

• Managed job queues.
• Container services.
• Batch compute.
• Dedicated workers.
• Scheduled tasks with appropriate runtime.

A serverless website can still use these services; “serverless architecture” does not mean every component has to be a function.

File-System Assumptions Often Break

Traditional applications sometimes save uploads or generated files to the local server disk. Serverless environments may use temporary or ephemeral file systems that are not guaranteed to persist between requests.

Use durable external storage for

• User uploads.
• Generated documents.
• Backups.
• Media files.
• Shared application state.

Object storage or a managed file service is normally a better fit than relying on the local function environment.

Observability Becomes More Distributed

Removing server administration does not remove troubleshooting. A request may pass through a CDN, function, authentication provider, database and third-party API.

Useful observability signals

• Function invocation count.
• Error rate.
• Execution duration.
• Cold/startup latency.
• Database query time.
• Third-party API latency.
• Request IDs or traces.
• Cost by function or endpoint.

Choose platforms that let you connect an error to the request and downstream service that caused it.

Serverless Security Follows Least Privilege

Each function should receive only the permissions required for its job. A public contact-form function does not need administrator access to every storage bucket or database table.

Security checklist

• Scope service credentials narrowly.
• Keep secrets outside source code.
• Validate request input.
• Authenticate private endpoints.
• Rate-limit abuse-prone functions.
• Verify webhook signatures.
• Patch dependencies.
• Review public deployment URLs.

Serverless reduces operating-system management, but application and identity security remain the developer’s responsibility.

Cost Can Be Excellent for Bursty Workloads—and Expensive at Scale

Pay-per-invocation pricing is attractive when traffic is low or irregular because there is little idle compute. A continuously busy application may eventually cost less on reserved or persistent infrastructure.

Workload	Serverless economics
Small site with occasional APIs	Often attractive
Seasonal campaign traffic	Strong scaling fit
Constant high CPU work	Compare with containers/servers
Heavy outbound data	Check transfer pricing
Many tiny database requests	Potential hidden latency/cost

Model actual requests, duration, memory, data transfer and database cost instead of comparing only the function price.

When Serverless Web Hosting Is a Strong Fit

• Static or static-first sites.
• APIs with variable traffic.
• Forms and webhook handlers.
• Event-driven automation.
• Jamstack/framework deployments.
• Teams that want less server administration.
• Applications that can store state externally.

When a Traditional Server or Container May Be Simpler

• Long-running processes.
• Applications that depend heavily on local disk.
• Constant high compute usage.
• Legacy applications built around persistent processes.
• Software requiring custom operating-system services.
• Teams that already manage stable container infrastructure effectively.

Architecture should simplify the workload, not force the workload to imitate a different model.

Serverless Hosting Evaluation Checklist

1. Classify static and dynamic parts of the site.
2. List every stateful dependency.
3. Measure function-to-database latency.
4. Review runtime and duration limits.
5. Test burst concurrency.
6. Test background jobs.
7. Review logs and tracing.
8. Calculate expected monthly cost.
9. Export/deploy to a second environment if portability matters.
10. Document fallback and recovery.

Frequently Asked Questions

Does serverless mean there are no servers?

No. The provider manages the servers and execution infrastructure. Developers interact with higher-level deployment and runtime services.

Can WordPress run serverless?

Parts of a WordPress delivery stack can use CDN or serverless services, but traditional WordPress depends on PHP and a database and is not automatically a natural serverless application. Static WordPress exports are a different architecture.

Is serverless always cheaper?

No. It can be cost-efficient for intermittent or bursty workloads, but constant high usage, data transfer and supporting managed services can change the economics.

Is serverless automatically global?

Static assets may be globally cached and some runtimes can execute across regions, but data sources and functions still have locality. Measure the full request path.

Conclusion

Serverless web hosting works best when the application can be separated into cacheable static content and short, event-driven backend operations. It can remove server maintenance and scale elegantly with demand, but developers still need to design data location, limits, security, observability and recovery.

Use serverless when it makes the application simpler. Test database behavior, execution limits and real costs before committing. If the workload needs long-running processes, persistent local state or constant high compute, a container or traditional server may be easier to operate. The right architecture is the one that matches how the application actually behaves.