Static site vs server app: what to host where

Most apps are a mix of pages that are the same for everyone and requests that depend on who is asking. The first kind can be served as static files from a CDN, often for free. Only the second kind needs a server you pay for and maintain. Deciding this page by page is one of the easiest ways for a solo developer to cut hosting costs and reduce what can break.

This guide uses providers’ official documentation for prices and limits; no hands-on benchmarks were run.

Definitions

• Static site: HTML, CSS, JavaScript and images generated before deployment (by a static site generator such as Astro, Hugo or Eleventy, or a front-end build such as Vite). The host only serves files.
• Server app: code that runs on each request, such as an Express or Fastify API, a Next.js app with server rendering, or a Django or Rails app. It needs a runtime, memory and usually a database.
• Hybrid: a static front end plus a separate API, or a framework that pre-renders most pages and renders a few on demand.

The one-question test

For each page or endpoint, ask: does the response depend on who is asking, or on data that changes more often than you deploy?

• No → it can be static.
• Yes → it needs a server, or a third-party service that acts as one.

What static hosting costs

At small scale, static hosting is free on several platforms:

• Cloudflare: requests to static assets are free and unlimited; the Pages free plan allows 500 builds per month and 20,000 files per site.
• Render: static sites are free, with custom domains and TLS included; traffic counts against the workspace’s outbound bandwidth (5 GB/month on the free Hobby plan, then $0.15/GB).
• GitHub Pages: 1 GB site limit and a soft 100 GB/month bandwidth limit, and not intended for commercial SaaS or e-commerce.
• DigitalOcean App Platform: up to 3 static-site apps free with 1 GiB transfer each.

Static files can also be cached at the edge, so a traffic spike from a popular post costs little or nothing and does not take the site down.

What server hosting costs

An always-on server process starts at a few dollars a month, for example a $4–6 DigitalOcean Droplet, a $5 DigitalOcean App Platform container, or about $7/month for a Render Starter instance. Add a database, backups and monitoring, and the real cost of the server side of a small app is usually higher than the hosting line alone. See the cheapest way to host a Node.js app for a ranked list.

Three common architectures

1. Fully static

Everything is pre-built. Dynamic needs are handled by third parties: a hosted checkout link for payments, a newsletter provider’s sign-up form, a mailto: contact link.

Choose this if you are building a content site, a portfolio, documentation, or a landing page for a mobile app. Cost: usually $0.

2. Static front end + API

The marketing site and the app shell are static on a CDN. A separate API on a managed platform or VPS handles auth, data and webhooks.

Choose this if you have a real backend but most traffic hits public pages. The public pages stay fast and free even under load, and the API can be small because it only serves logged-in users.

Practical details:

• Serve the API from a subdomain such as api.example.com, and configure CORS to allow only your front-end origin.
• Keep auth cookies on the parent domain with SameSite settings, or use tokens; test this early.
• Deploy both from one repository, with separate build commands, if you want a single pull request to update both.

3. Full server app

One framework renders pages on the server and serves the API, such as Next.js with server rendering, Rails or Django.

Choose this if most pages are personalized, you rely on server rendering for SEO of dynamic content, or the framework’s conventions save you more time than splitting would. Even here, put static assets (images, downloads) on a CDN or object storage to save server bandwidth.

Worked example: moving a landing page off the server

A small SaaS runs everything on one Node.js server: the marketing site, the blog and the app. Every visit to the blog uses server memory and bandwidth.

Splitting it:

1. Move the landing page and blog to a static site generator and deploy to a free static host at example.com.
2. Keep the app at app.example.com on the existing server.
3. Point the “Log in” button to app.example.com/login.

Effects: the public pages no longer depend on the server being up, traffic spikes from a popular post cost nothing on the server, and the server can often drop to a smaller, cheaper plan because it now serves only logged-in users.

Decision rules

• If nothing depends on the visitor, go fully static.
• If only a few features need a backend, check whether a hosted service (checkout link, form provider, auth provider) can replace it before you run a server.
• If you have logged-in users, use static for public pages and a small API for the app.
• If almost every page is personalized, use a full server app, but still offload static assets.
• If you are unsure, start static. Adding an API later is easier than removing a server you no longer need.

Checklist before you deploy

• Each page classified as static or dynamic using the one-question test
• Static pages built in CI and deployed to a CDN-backed host
• API on a subdomain with CORS limited to your origin
• Large files served from a CDN or object storage, not the app server
• Custom 404 page on the static host
• Cache headers set for hashed assets (long) and HTML (short)

Moving from static to dynamic later

Starting static does not lock you in. When a feature needs a backend, add it as a separate service:

1. Build the endpoint as a small API (or a serverless function) on its own subdomain.
2. Call it from the static page with fetch, and keep the page usable if the API is down.
3. Add authentication only to the parts that need it.
4. Monitor the API separately from the static site, because they now fail independently.

FAQ

Is a static site worse for SEO? No. Static pages are fully rendered HTML, which search engines can crawl easily, and they tend to load fast. The issue is the opposite case: a single-page app that renders content only in the browser can be harder to index than a pre-rendered page.

Can a static site have a contact form? Not by itself; something must receive the submission. A mailto: link needs no backend at all. Otherwise, use a form service or a tiny serverless function.

What about Next.js? It can do both. Pages without per-request data can be statically generated, and only the pages or routes that need it run on a server. Check which mode each page uses, because it decides where and how you can host it.

Sources

1. Cloudflare Workers static assets: billing and limitations
2. Cloudflare Pages limits
3. Render: Static sites
4. Render: Outbound bandwidth
5. GitHub Pages limits
6. DigitalOcean App Platform pricing
7. DigitalOcean Droplet pricing
8. Render: Free instances
9. MDN: Cross-Origin Resource Sharing (CORS)

Last verified: October 9, 2026. Prices, limits and policies come from the official pages listed under Sources, not from hands-on testing. Providers change them often, so confirm on the provider's own page before you buy. Spotted something out of date? Tell us.