A Jamstack website is prebuilt markup served from a CDN, with dynamic behavior added through APIs called at build time or in the browser, rather than a server rendering every request from scratch. The term itself has faded since its 2016-era peak; most people building this way in 2026 say headless or composable architecture instead, even though the underlying pattern, and its real limits around authentication, personalization and forms, has not fundamentally changed. Knowing the pattern matters more than knowing the label.
Search this term and you land on pages that either treat 2016 as the present tense or announce the term is dead without explaining what actually replaced it. Both miss the useful part: the architectural decision, prebuilt pages versus rendered-per-request, is exactly as relevant now, it is just described with different words and implemented with different frameworks, Next.js dominant among them.
Table of contents
- What the pattern actually is, independent of the label
- Why the vocabulary shifted
- The build-time vs request-time decision
- The limits that do not go away
- Where the backend goes
- Choosing the shape for a real project
- How this fits the rest of the stack
- FAQ
What the pattern actually is, independent of the label
Strip away the branding and Jamstack describes one architectural choice: generate as much of the page as possible ahead of time, at build, and serve it from a CDN as static files, then fill in anything that has to be current, a cart total, a logged-in user’s name, through API calls rather than a server template re-rendering the whole page on every request.
The three letters, JavaScript, APIs, Markup, described the pieces rather than a strict rule, which is part of why the term stretched to cover everything from a plain static blog to a fully server-rendered Next.js app with ISR, and part of why it eventually stopped being a precise enough word to bother with.
A concrete example makes the pattern easier to hold onto than the acronym does. A documentation site builds every page at deploy time from markdown in a repository, ships as static HTML with no server involved, and its search box calls a small hosted search API in the browser rather than querying a database on your own server. That is the whole pattern in one small site: static where possible, an API for the one piece that has to be dynamic.
Why the vocabulary shifted
Headless describes the same decoupling from the content or commerce side: a CMS or a store back end exposes data through an API with no opinion about how it is rendered, which is the half of the Jamstack pattern that survived cleanly. Composable architecture extends that to infrastructure generally, picking best-fit services for auth, search, payments and content rather than one monolithic framework.
Neither term is a rebrand for marketing’s sake alone; they describe slightly different emphases, headless is about the content layer, composable is about the whole stack, and the fact that both outlived Jamstack as a search term says more about the label’s vagueness than about the pattern being abandoned.
The build-time vs request-time decision
This is the actual decision every project in this category makes, whatever it is called. Build-time rendering, generate the HTML once when content changes, is fast and cheap to serve and needs no server at request time, but every page is only as fresh as the last build. Request-time rendering handles per-user or frequently changing data correctly but needs a server or function to run on every visit.
Most real sites mix both: marketing pages and blog posts build-time, a logged-in dashboard or a live cart request-time. Getting this split right, not picking one universally, is the actual skill the label used to imply.
The limits that do not go away
- Authentication. A static page cannot know who is logged in without an API call after load or a request-time render; there is no session baked into pre-generated HTML.
- Personalization. Content that differs per visitor either regenerates per request or gets fetched client-side after the static shell loads, both of which add complexity a purely static page does not have.
- Forms. A static page cannot process a submission itself; it needs a serverless function, a webhook, or a backend endpoint to receive the data.
None of these are solved by choosing a newer name for the architecture. They are the actual trade-offs of the build-time-first approach, and every implementation, whatever it calls itself, deals with them the same way: an API layer sitting behind the static shell.
Where the backend goes
The API layer is not optional infrastructure bolted onto an otherwise complete site; it is where the site’s real logic lives once anything needs to be dynamic. That can be as small as a single function handling a contact form, or as substantial as a full backend with a database for accounts, orders, or content that changes constantly.
This is also where the architecture stops being purely static hosting territory. A web service with a managed database beside it is the backend half of the pattern, deployed separately from the static frontend and called over an API, the same shape whether you call the whole thing Jamstack, headless, or nothing at all.
Choosing the shape for a real project
Start by listing what actually needs to be dynamic: a login, a cart, a form, content editable without a rebuild. Everything else defaults to a static build. That list, not the architecture’s name, decides whether the project is a static site with one function, or a static frontend paired with a full backend service and database.
The static half deploys the same way regardless: build from the repository, serve from a CDN, keep the bandwidth allowance in mind once traffic or media grows. See static pages explained for that half in more depth, and headless architecture for the content-layer half of this same decision.
Projects also tend to move through this shape incrementally rather than choosing it all at once: a static brochure site adds a contact form and needs its first function, then a customer area and needs real authentication, then an admin view and needs a proper backend with a database. Each step is additive, the static shell keeps working the same way, which is the main practical advantage of starting static rather than starting with a full backend a small site does not yet need.
How this fits the rest of the stack
Whatever the site is called, pricing the static half and any backend piece together up front avoids surprises once traffic or a new feature arrives: the RunxBuild hosting calculator models a static site, a service, and a database on one page. Static sites on RunxBuild covers the build-from-repository path for the front end, and the dashboard is where the pieces connect.
Useful related references:
- What Is a Static Website? Benefits, Examples, Hosting
- Website Management: What It Covers and What It Should Cost
- Deploy an Astro Website for Free
- Services on RunxBuild
FAQ
Is Jamstack still relevant in 2026?
The pattern is, the term less so. Prebuilt markup served from a CDN with dynamic behavior added through APIs is still how most modern sites work; people increasingly describe it as headless or composable architecture rather than Jamstack specifically.
What is the difference between Jamstack and headless architecture?
Headless specifically means the content or commerce source exposes data through an API with no built-in rendering layer. Jamstack was a broader label for the whole build-static-serve-from-CDN pattern that headless content typically feeds into.
Can a Jamstack site have a database?
Not directly attached to the static frontend, but the backend or API layer that a Jamstack-style site calls absolutely can and usually does, whether that is a headless CMS’s own database or a custom backend with a managed database behind it.
Does a Jamstack site need a backend?
Anything beyond a purely static page, a login, a form, a cart, needs some backend logic, even if it is a single serverless function. The frontend can be entirely static while the backend handles everything that has to be dynamic.
What replaced the term Jamstack?
No single term replaced it cleanly. Headless describes the decoupled content layer specifically, and composable architecture describes assembling best-fit services across the whole stack. Both describe pieces of what Jamstack originally tried to name as one thing.