Static vs Dynamic Deployment

Build the mental model

A static site is made of plain HTML, CSS, JavaScript, and images served directly to the browser with no processing in between. Marketing pages, documentation, blogs, and portfolios are a natural fit, since the same files go out to every visitor unchanged.

A dynamic application needs a runtime to execute code on every request, usually backed by a database, authentication, and server-side logic that makes decisions per visitor — think of a feed or a store where each person sees something different.

Does it need a database to store or update data?
Does it need authentication to identify users?
Does it need server-side logic to decide what to show?

In real projects these two halves are often deployed separately: a frontend to a platform built for fast global file delivery, a backend to a server, serverless platform, or container, and a database to its own managed service — though some frameworks blur the two into one unit.

Static Site: A site made of pre-built HTML, CSS, JS, and image files served directly to every visitor with no per-request processing.

Dynamic Application: An application that runs code per request, typically backed by a database, authentication, and server-side logic that varies the response per user.

text

STATIC VS DYNAMIC DEPLOYMENT
----------------------------
STATIC:
  Browser --> CDN / Static Host --> HTML, CSS, JS files
              (Netlify, Vercel, GitHub Pages, S3+CDN)

DYNAMIC:
  Browser --> Frontend App --> Backend API --> Database
                                (auth, server logic)

Connect it to a real scenario

When planning a deployment, start by asking what each part of your project actually needs. A page with no forms or accounts can usually ship as static files. Anything that stores data, remembers users, or talks to a payment provider needs a backend and persistent storage.

Many real products are a mix — a marketing site, a docs section, and a logged-in dashboard, each with different needs. It is completely normal to deploy them differently instead of forcing everything through one path.

Does it need a database?
Does it need authentication?
Does it need to run custom logic per request?

If the answer to all three is no, static hosting is usually simpler, cheaper, and faster. If any answer is yes, you need a dynamic deployment path — the specific platform is a separate decision covered in this site's other tutorials.

Static sites serve pre-built files directly with no server-side processing per request.
Dynamic applications need a runtime, database, and often authentication to handle logic per request.
Frontend, backend, and database pieces are commonly deployed to separate platforms rather than as one bundle.

Try the working example

javascript

function classifyProject(project) {
  const needsBackend = project.needsDatabase || project.needsAuth || project.needsServerLogic;
  return needsBackend ? "dynamic-fit" : "static-fit";
}

const projects = [
  { name: "Portfolio site", needsDatabase: false, needsAuth: false, needsServerLogic: false },
  { name: "Company blog", needsDatabase: false, needsAuth: false, needsServerLogic: false },
  { name: "E-commerce store", needsDatabase: true, needsAuth: true, needsServerLogic: true },
  { name: "Docs site", needsDatabase: false, needsAuth: false, needsServerLogic: false },
  { name: "Social media app", needsDatabase: true, needsAuth: true, needsServerLogic: true },
];

for (const project of projects) {
  console.log(`${project.name}: ${classifyProject(project)}`);
}

You should see

Portfolio site: static-fit
Company blog: static-fit
E-commerce store: dynamic-fit
Docs site: static-fit
Social media app: dynamic-fit

5-minute try-it

List three real projects you've used or imagined (e.g. a personal blog, a to-do app, a company brochure site). For each, decide whether it needs a database, authentication, or per-request logic, and classify it as static-fit or dynamic-fit using the same criteria as the code example.

One important caution

Assuming a project needs a full dynamic stack when its content never actually changes per visitor — a static host would be simpler and cheaper.

Deploying a dynamic app's database on the same host as the app code, which makes scaling either piece independently harder.

Introduction to the server side — MDN Web Docs — Cloud & Deployment