Static, server-rendered or serverless: which hosting your app needs
What static hosting, server-side rendering, serverless functions and always-on servers each do, the limits that matter (timeouts, payload sizes, sleeping free tiers), and five questions that tell you which one your app needs.
Key Takeaways
- Static hosting serves the same files to everyone. It is fast, cheap and often free, and it is enough for apps with no accounts and nothing to save.
- Server-side rendering builds each page on request. It helps when pages must show fresh or per-user content and need to be readable by search engines and link previews before JavaScript runs.
- Serverless functions run your backend code on demand. You pay per use and never manage a machine, but each call has time and size limits and nothing stays in memory or on disk between calls.
- Always-on servers suit long-running work. WebSocket-heavy apps, workers that process queues all day and jobs that run for hours fit a server or container better than functions.
- The database is a separate decision. None of these models stores data on its own. Whatever you choose, user data belongs in a managed database, not in files on the server.
Quick-Start Prioritization Framework
| Your app | Hosting model that fits | Why |
|---|---|---|
| Calculator, portfolio, landing page, docs | Static | Same content for everyone, nothing saved |
| Logins, saved data, admin pages | Static frontend + serverless backend + managed database | Backend code only runs when someone does something |
| Content that must appear in search and link previews, changing often | Server-side rendering | HTML is complete before it reaches the browser |
| Chat or live dashboards with many open connections | Always-on server, or a platform with realtime built in | Connections stay open for a long time |
| Video processing, long imports, queue workers | Background workers or containers | Work runs longer than a function allows |
Hosting pages throw a lot of terms at you: static, SSR, SSG, edge, serverless, containers. For someone who built an app with an AI assistant, the real question is simpler: what does my app do, and what kind of hosting can do that? A recipe calculator and a booking system with logins need very different things, and choosing wrong shows up later as data that disappears, jobs that time out, or a bill for a server that sits idle. This guide explains each model in plain terms, gives the real limits from the providers’ own documentation, and ends with a short decision process. Most apps end up as a mix, and that is normal.
The four models in one paragraph each
Every option on a hosting page is some combination of these four. Learn them once and the marketing pages become readable.
Static hosting
Your app is built once into HTML, CSS and JavaScript files, and those files are copied to a content delivery network that serves them from locations around the world. MDN describes a static site as one where every user receives the same content for a given URL, with no server-side logic. A React app built with Vite is static by default: the browser downloads the files and JavaScript does the rest.
Server-side rendering (SSR)
A server generates the HTML for each request, filling in data before sending the page. MDN lists the benefits: content is readable before JavaScript runs (useful for search engines and especially social media crawlers, which usually don’t run JavaScript), and the server can fetch all the data a page needs in one go. Next.js, Remix and Nuxt are common SSR frameworks.
Serverless functions
Small pieces of backend code that run only when called, such as an endpoint that saves an order or sends an email. The platform starts them on demand, scales them with traffic and charges for what they use. AWS Lambda describes itself as designed for short-lived compute tasks that don’t retain state between invocations. Vercel Functions, Netlify Functions and Cloudflare Workers are built on the same idea.
Always-on servers and containers
A process that runs continuously on a virtual machine or in a container, like a traditional Node or Python server. You pay for it whether or not anyone is using it, but it can hold connections open, keep things in memory and run as long as needed. Render, Railway, Fly.io and a plain virtual server from DigitalOcean or Hetzner are examples.
How they compare
The table summarizes the trade-offs that usually decide the choice. The limits shown come from each provider’s documentation and vary by plan.
| Static | Server-rendered | Serverless functions | Always-on server | |
|---|---|---|---|---|
| Runs your backend code | No | Yes, per page request | Yes, per call | Yes, continuously |
| Cost when nobody visits | Usually nothing | Little or nothing on serverless platforms | Little or nothing | Full price |
| Handles traffic spikes | Very well | Well | Well, up to concurrency limits | Up to the machine’s size |
| Long-running work | No | No | Limited (minutes) | Yes |
| Keeps state in memory | No | No | No | Yes, until restart |
| Typical example | Vite React build on a CDN | Next.js pages | An /api/orders endpoint | A Node server with WebSockets |
Static hosting: when it is enough
If the app does everything in the browser and saves nothing, static hosting is the cheapest and most reliable choice. There is no server to crash, and a CDN can absorb large traffic spikes.
Good fits
Calculators, converters, quizzes with fixed answers, portfolios, landing pages, documentation, and single-player games. Static apps can still call third-party services that are designed to be called from browsers, such as a form service or a map widget with a public key.
Where it stops
The moment you need accounts, saved data shared across devices, payments or a secret API key, you need backend code somewhere. AI assistants sometimes work around this by storing data in the browser’s local storage. It looks fine in testing and fails when the user opens the app on another device or clears their browser.
Server-side rendering: when pages need to be ready on arrival
SSR is about how pages are delivered, not about whether you have a backend. You can have a full backend without SSR, and many apps do.
When it matters
Public pages whose content changes and must be read by crawlers: product pages, listings, articles, public profiles. When someone shares a link in a chat app, the preview card comes from the HTML the server returns; if that HTML is an empty shell, the preview is blank.
When it doesn’t
Pages behind a login, such as dashboards, admin panels and account settings, aren’t indexed by search engines anyway. Rendering them in the browser is simpler and puts less load on the server. Many apps render public pages on the server or at build time and private pages in the browser.
Static generation is the middle ground
If public pages change rarely, generate them at build time (static site generation) and rebuild when content changes. You get crawler-friendly HTML with static hosting’s cost and speed.
Serverless functions: the default backend for small apps
For most apps built with AI tools, a static frontend plus serverless functions plus a managed database is the right default. You don’t patch servers, you pay little when traffic is low, and scaling is automatic. The trade-off is a set of limits worth knowing before you build.
Time limits
AWS Lambda functions can run for up to 15 minutes per invocation. Vercel Functions default to 300 seconds; on Hobby that is also the maximum, while Pro and Enterprise can raise it to 800 seconds, with a 30-minute extended maximum in beta. Anything that might take longer, such as transcribing a long video, needs a background job or a worker.
Size limits
Request and response bodies are capped. Vercel’s limit is 4.5 MB for a function’s request or response body (streamed responses are exempt from the response limit); synchronous Lambda calls allow 6 MB each way. That’s why file uploads usually go straight from the browser to object storage using a short-lived upload URL, rather than through a function.
Nothing persists between calls
Each call may run on a fresh instance. A variable in memory, a file written to disk or a counter kept in a global won’t reliably be there next time. Store everything that matters in the database or object storage.
Database connections
Many function instances can start at once, and each may open its own database connection. Traditional Postgres has a limited number of connections, so use your database provider’s connection pooler or a serverless driver, which most managed Postgres hosts provide.
Always-on servers: when you actually need one
Some workloads fit a long-running process better than on-demand functions. If your app does one of these, consider a server or container for that part, even if everything else is serverless.
Long-lived connections
Multiplayer games, chat with thousands of open sockets, or live trading dashboards hold connections for a long time. Some serverless platforms now support WebSockets (Vercel lists it as public beta), and some app platforms include realtime messaging as a managed feature, but heavy realtime use is still the classic case for a server.
Background workers
A worker that pulls jobs from a queue all day, or a scraper that runs for hours, is cheaper and simpler as a process that stays up. Short scheduled tasks, like a nightly cleanup, usually fit in a scheduled function instead.
Watch free tiers that sleep
Free always-on tiers often sleep when idle. Render’s free web services spin down after 15 minutes without traffic and take time to wake on the next request. That is fine for a demo and confusing for real users, who see a slow first load.
Five questions that decide it
Answer these about your app, in order. Most apps get their answer by question three.
1. Does anything need to be saved or kept secret?
No: static hosting. Yes: you need backend code and a database. Continue.
2. Does every backend action finish in under a minute or so?
Saving a form, charging a card, sending an email, calling an AI model for a short answer: yes. Then serverless functions fit. If some tasks take many minutes, plan a background job or worker for those tasks only.
3. Do public pages need to show up in search and link previews?
If yes and they change often, use server-side rendering for those pages. If they change rarely, generate them at build time. Private pages can stay client-rendered.
4. Does the app hold many connections open?
Live chat, multiplayer and streaming dashboards at scale point toward a server, or a platform with managed realtime.
5. Who will maintain it?
A virtual server is cheap per month but someone has to apply updates, renew certificates, watch disk space and restart the process. If that someone is you and you’d rather not, prefer managed serverless or an app platform.
Common mistakes
These are the mismatches between app and hosting that cause the most trouble.
Writing user data to the server’s disk
Works on your laptop and on a single server, then disappears on serverless platforms or after a redeploy. Use the database for records and object storage for files.
Running long jobs in a request
A function that processes a large upload inside the request times out halfway. Accept the request, queue the work, and let a background job report back when it’s done.
Paying for an idle server
A small app with a few hundred users rarely needs a machine running all month. Serverless often costs less until traffic is steady.
Choosing SSR for a private dashboard
Server-rendering pages that only signed-in users see adds complexity and cost without the search benefit. Keep SSR for public pages.
Putting the database far from the functions
Every query crosses the distance between the function’s region and the database’s region. Put them in the same region; Vercel, for example, runs functions in a single default region that you can change.
If you’d rather not do this yourself
If you’d rather not assemble these pieces, Floot builds apps in this common shape for you: a React frontend, serverless backend endpoints and a Postgres database per app, with scheduled jobs, background tasks and realtime included, and publishing is free on every plan.
Frequently Asked Questions
What is the difference between static and dynamic hosting?
Static hosting serves pre-built files that are the same for every visitor. Dynamic hosting runs code for each request, either to build the page (server-side rendering) or to handle actions like saving data (serverless functions or a server).
Can a React app be hosted as a static site?
Yes. A React app built with a tool like Vite produces static files that any static host can serve. If it needs logins or saved data, it also needs a backend and a database somewhere.
Is serverless cheaper than a server?
Usually for small or spiky traffic, because you pay only when code runs. For steady, heavy traffic or long-running work, an always-on server can cost less per request.
Do I need server-side rendering for SEO?
For public pages you want indexed and previewed when shared, it helps, because the HTML arrives complete. Static generation achieves the same for pages that change rarely. Pages behind a login don’t need it.
What is a cold start?
The delay when a serverless platform starts a new instance of your function before it can handle a request. It is usually short, and it is one reason idle free-tier servers feel slow on the first visit.
Can I mix these models in one app?
Yes, and most apps do: static or server-rendered pages, serverless functions for actions, a managed database, and sometimes a worker for long jobs.
Sources
- MDN, SSR (server-side rendering), 2026 https://developer.mozilla.org/en-US/docs/Glossary/SSR
- MDN, SSG (static site generator), 2026 https://developer.mozilla.org/en-US/docs/Glossary/SSG
- AWS, Lambda quotas, 2026 https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
- Vercel, Vercel Functions limits, 2026 https://vercel.com/docs/functions/limitations
- Render, Deploy for free, 2026 https://render.com/docs/free
- Cloudflare, Workers pricing, 2026 https://developers.cloudflare.com/workers/platform/pricing/