---
term: 'JAMstack'
seoTitle: 'JAMstack Explained: JavaScript, APIs, Markup — and the Backend'
headline: 'What is JAMstack?'
slug: jamstack
category: frontend-web
shortDefinition: 'JAMstack is a web architecture that prebuilds the frontend into static markup on a CDN, with JavaScript and APIs for dynamic features.'
relatedTerms:
  - ssr-vs-csr-vs-ssg
  - baas-vs-custom-backend
  - cdn-content-delivery-network
  - auto-generated-database-apis
contrastsWith:
  - ssr-vs-csr-vs-ssg
aboutTerms:
  - 'JavaScript, APIs, Markup'
  - 'Pre-rendering & Decoupling'
  - 'Headless Architecture'
faq:
  - question: 'What is JAMstack?'
    answer: 'A web architecture that prebuilds the frontend into static markup at build time, serves it from a CDN, and uses client-side JavaScript calling APIs for anything dynamic — decoupling the frontend from the backend. It is a pattern, not a framework or product.'
  - question: 'What does JAM stand for?'
    answer: 'JavaScript, APIs, and Markup. JavaScript runs in the browser for interactivity; APIs supply the dynamic data and server-side operations; Markup is the prebuilt static HTML served from the edge. The two founding principles beneath the acronym are pre-rendering and decoupling.'
  - question: 'Who created JAMstack and when?'
    answer: 'The term was coined in 2015 by Mathias Biilmann (often co-credited to Chris Bach) at the static-hosting platform that pioneered the model, as a short way to name decoupled frontends that talk to APIs and are served statically from a CDN.'
  - question: 'What is the difference between JAMstack and a traditional stack?'
    answer: 'A traditional stack like a database-backed CMS renders each page on a server per request from a database. JAMstack serves prebuilt static files from a CDN and calls APIs only for the dynamic parts — no origin server rendering the page on every visit, and no database exposed to the public web.'
  - question: 'Can JAMstack sites be dynamic?'
    answer: 'Yes — the dynamic functionality is delivered at runtime by JavaScript calling APIs: serverless functions, a headless CMS, third-party services, or a backend-as-a-service. The "static" part is only the shell; auth, data, search, and commerce all arrive through API calls.'
  - question: 'How do you handle auth, data, and forms without a backend?'
    answer: 'You do have a backend — reached over APIs rather than run by you. Auth goes through an identity service or BaaS with tokens; data comes from a content or database API; forms post to a serverless function or a form service. Every "dynamic" need maps to an API call.'
  - question: 'What is the difference between JAMstack and SSR?'
    answer: 'Timing. SSR renders HTML on the server per request; JAMstack pre-renders at build time and serves static files. Modern frameworks blend them — static routes prebuilt, dynamic routes server-rendered or regenerated — which is the hybrid the JAMstack idea evolved into.'
  - question: 'Is JAMstack dead?'
    answer: 'The marketing term faded — its originator retired the label around 2023 in favor of "composable" and "modern web architecture." But the architecture won: prebuild what you can, fetch the rest via APIs, serve from a CDN is now simply how much of the web is built, living inside headless CMS, hybrid frameworks, and edge platforms.'
  - question: 'What is a headless CMS and how does it fit?'
    answer: 'A content store that exposes content over an API with no built-in frontend. The static site generator or frontend consumes it at build or runtime — the classic JAMstack content source, and one example of the broader "backend behind an API" the architecture depends on.'
  - question: 'When should you use JAMstack?'
    answer: 'It excels for content, marketing, docs, and SEO-sensitive sites where speed and a small attack surface matter, plus e-commerce fronts backed by APIs. It fits less well for heavily real-time or per-request-personalized apps, where server-side or edge rendering is the better tool.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'What is Jamstack? — jamstack.org'
    url: 'https://jamstack.org/what-is-jamstack/'
  - name: 'JAMstack — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/JAMstack'
  - name: 'Rendering patterns — patterns.dev'
    url: 'https://www.patterns.dev/'
  - name: 'Is Jamstack Toast? — The New Stack'
    url: 'https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/'
cta:
  title: 'The dynamic 20%, handled'
  text: 'JAMstack prebuilds the static shell; Back4app is the API behind the JavaScript — auth, database, and cloud functions for the dynamic part, no server to provision.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-30'
translationKey: jamstack
---

**JAMstack is a web architecture that prebuilds the frontend into static markup on a CDN, with JavaScript and APIs for dynamic features.** The acronym — **J**avaScript, **A**PIs, **M**arkup — rests on two principles: *pre-rendering* (the frontend is built into optimized static files ahead of time) and *decoupling* (frontend and backend communicate only over APIs). The reframe this glossary adds, and the one the frontend guides skip: **the A is a backend.** JAMstack's famous "no server" doesn't mean no backend — it means *someone else's server, reached over an API*.

## Key takeaways

| Question | Answer |
| --- | --- |
| JAM | JavaScript (browser) · APIs (dynamic) · Markup (prebuilt static) |
| The two principles | Pre-rendering + decoupling |
| Delivery | Static files from a [CDN](/glossary/cdn-content-delivery-network/) — no per-request origin render |
| The "A" | APIs = a backend ([BaaS](/glossary/baas-vs-custom-backend/), functions, headless services) |
| "Is it dead?" | The term retired; the architecture won and went hybrid |

## The JAM in practice

**JavaScript:**

```javascript
// JavaScript — the JAM in practice: static Markup, browser JS, an API for the dynamic
// The page shell was prebuilt at build time and served from a CDN.
// The dynamic 20% — auth, data, comments — is this API call at runtime:
const query = new Parse.Query('Comment');
query.equalTo('postSlug', 'what-is-jamstack');
const comments = await query.find();
render(comments); // "no server" really means: someone else's server, via an API
// The A in JAM = APIs = a backend. A BaaS is that backend, with no server to run.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// A prebuilt shell, made dynamic by API calls — the JAMstack pattern
final query = QueryBuilder<ParseObject>(ParseObject('Comment'))
  ..whereEqualTo('postSlug', 'what-is-jamstack');
final comments = await query.query();
render(comments.results);
// Static delivery + dynamic-via-API: the backend is a BaaS, not a server
// you provision — auth, data, and functions reached over one API.
```

**Swift:**

```swift
// Swift — Back4app Swift SDK
// A prebuilt shell, made dynamic by API calls — the JAMstack pattern
let comments = try await Comment.query("postSlug" == "what-is-jamstack").find()
render(comments)
// Static delivery + dynamic-via-API: the backend is a BaaS, not a server
// you provision — auth, data, and functions reached over one API.
```

**Kotlin:**

```kotlin
// Kotlin — Back4app Android SDK
// A prebuilt shell, made dynamic by API calls — the JAMstack pattern
val query = ParseQuery.getQuery<ParseObject>("Comment")
query.whereEqualTo("postSlug", "what-is-jamstack")
val comments = query.find()
render(comments)
// Static delivery + dynamic-via-API: the backend is a BaaS, not a server
// you provision — auth, data, and functions reached over one API.
```

The page shell was prebuilt and served from the edge; the comments — the dynamic part — arrive at runtime through an API call. That single call is the whole architecture in miniature: static where you can be, API where you must be, and the "server" behind the API is a service you consume rather than one you run.

## Traditional stack vs. JAMstack

```mermaid
flowchart LR
  accTitle: Traditional server-rendered stack versus JAMstack
  accDescr: In a traditional stack, each visitor request hits an origin web server that queries a database and renders HTML per request. In JAMstack, the frontend is prebuilt into static markup at build time and served from a CDN, and the browser's JavaScript calls decoupled APIs for dynamic data, so no origin server or database is exposed on the request path.
  subgraph T["Traditional (per request)"]
    U1["Visitor"] --> WS["Origin server<br/>renders HTML"] --> DB1[("Database")]
  end
  subgraph J["JAMstack (prebuilt + API)"]
    U2["Visitor"] --> CDN["CDN<br/>prebuilt static markup"]
    U2 -->|"JS calls APIs<br/>for dynamic data"| API[("Decoupled APIs<br/>BaaS · functions · CMS")]
  end
```

| | Traditional (server-rendered) | JAMstack |
| --- | --- | --- |
| HTML made | Per request, on the origin | At [build time](/glossary/ssr-vs-csr-vs-ssg/), prebuilt |
| Served from | An origin web server | A [CDN](/glossary/cdn-content-delivery-network/) edge |
| Dynamic data | Rendered inline from the DB | JavaScript calling APIs |
| Coupling | Frontend and backend fused | [Decoupled](/glossary/decoupled-architecture/) over APIs |
| Attack surface | Origin + DB exposed | Static files + a hardened API |

## Where the dynamic actually comes from

The section the SERP avoids because it breaks the "serverless" spell. Every dynamic need on a JAMstack site maps to an API call, and behind that API is a backend someone runs:

- **Auth** → an identity service or [BaaS](/glossary/baas-vs-custom-backend/) issuing [tokens](/glossary/json-web-token-jwt/).
- **Data** → a content or database [API](/glossary/auto-generated-database-apis/) returning JSON.
- **Forms** → a [serverless function](/glossary/cloud-code-serverless-functions/) or form service.
- **Search, comments, commerce** → third-party or backend APIs.

So the honest description of JAMstack is *static frontend + decoupled backend*, and the natural backend is a **BaaS**: it supplies the dynamic 20% — database, auth, cloud functions, [auto-generated APIs](/glossary/auto-generated-database-apis/) — with no server for you to provision. Vendor pages push a *headless CMS* here, which handles content only; a BaaS handles the whole dynamic backend, which is why the pairing is the most complete answer to "how is a static site dynamic?"

## The security dividend

Decoupling isn't only a performance story; it's a security posture. With no origin server rendering pages and no database on the request path, the public web sees *static files*, which can't be SQL-injected and run no server-side code to exploit. The only live surface is the API boundary — separately hosted, independently hardened, and usually far narrower than a monolith's. The [decoupled architecture](/glossary/decoupled-architecture/) entry generalizes the benefit; on JAMstack it shows up as an attacker finding a CDN full of flat HTML where the origin server used to be.

## Is JAMstack dead? The honest verdict

The most-asked question deserves the plain answer. The *acronym* faded — its originator retired the "JAMstack" branding around 2023 for "composable" and "modern web architecture," and the marketing energy moved on. The *architecture* won. "Prebuild what you can, fetch the rest via APIs, serve from a CDN" stopped being a movement and became a default, absorbed into headless platforms, hybrid meta-frameworks, and edge rendering. What evolved is the rigidity: pure static-everything gave way to *mixing* prebuilt and [server-rendered routes](/glossary/ssr-vs-csr-vs-ssg/) per page. So JAMstack isn't dead; it's the water the modern web swims in, no longer needing a name.

## Common use cases

- **Marketing, docs, and blogs** — content that's the same for everyone and changes on a schedule: prebuild and serve from the edge.
- **E-commerce storefronts** — static product pages fronted by a CDN, cart and checkout via APIs.
- **SEO-sensitive sites** — prebuilt HTML that crawlers read instantly, no JS-execution penalty.
- **Static frontend + [BaaS](/glossary/baas-vs-custom-backend/)** — the dynamic 20% (auth, data, forms) over a managed backend.
- **High-traffic launches** — the CDN absorbs spikes the way an origin server can't.

## Should you use JAMstack? A decision matrix

| Situation | Lean |
| --- | --- |
| Content, docs, marketing, SEO-first | JAMstack — its home turf |
| Static frontend needing dynamic data | JAMstack + a [BaaS](/glossary/baas-vs-custom-backend/) for the API |
| Heavily personalized, per-request pages | [Server-side rendering](/glossary/ssr-vs-csr-vs-ssg/) or edge |
| Real-time, highly interactive app | Client rendering + [live data](/glossary/real-time-live-queries/) |
| Huge page counts, frequent changes | Hybrid — prebuild some, render the rest |
| Small attack surface a priority | JAMstack — the security dividend |

## Limitations and trade-offs

- **Build times grow with the site.** Prebuilding thousands of pages makes deploys slow; large or fast-changing catalogs push toward hybrid regeneration.
- **Dynamic means wiring.** Every interactive feature is an API integration; the simplicity is on the delivery side, not necessarily the build side.
- **Content editing is less turnkey.** Non-technical editors need a headless CMS or admin layer; there's no built-in "edit this page" like a monolithic CMS.
- **You depend on APIs you don't own.** Third-party services on the request path add availability and versioning risk — the decoupling cuts both ways.
- **Not everything should be static.** Per-request personalization and real-time data fight the prebuild model; the modern answer is to mix, not to force.

## JAMstack on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. It is precisely the "A" a JAMstack site needs: the static shell prebuilds and serves from a CDN, and every dynamic call the JavaScript makes — [login](/glossary/authentication-vs-authorization/), data reads and writes, form submissions, search — resolves to a Back4app [API](/glossary/auto-generated-database-apis/), with no origin server for you to run and the [ACLs](/glossary/access-control-lists-acl/) hardening the one live surface the architecture exposes. The pairing is the honest completion of the "serverless" story the code tabs sketch: static delivery from the edge, dynamic behavior from a managed backend, and the security dividend of a public web that sees flat files instead of your database.