Jamstack is a web architecture in which pages are prebuilt into static files at deploy time, served directly from a content delivery network, and made dynamic in the browser through JavaScript and APIs. The name originally stood for JavaScript, APIs and Markup, and it describes a way of decoupling the frontend from the backend rather than a specific product or framework.
In web architecture, Jamstack is the opposite of the classic request-time model, where a server such as a PHP or Node.js application builds every page when a visitor asks for it. Jamstack moves that work to a build step, so the live site consists mostly of static assets with no application server in the request path.
How Jamstack architecture works
A Jamstack project starts with source content and templates, often stored in a Git repository or pulled from a headless CMS. A static site generator such as Hugo, Eleventy, Astro, Gatsby or the static export mode of Next.js combines content and templates into finished HTML, CSS, JavaScript and images.
The build output is uploaded to a CDN with many edge locations, so a visitor receives the page from a nearby server without waiting for database queries. Interactive features such as search, forms, comments, payments or user accounts call third-party or custom APIs directly from the browser or through serverless functions.
The typical request and deployment flow has four distinct stages, each handled by a different part of the toolchain.
| Stage | What happens | Typical tools |
|---|---|---|
| Content change | Editor or developer commits content or code | Git, headless CMS |
| Build | Generator renders all pages to static files | Hugo, Eleventy, Astro, Next.js |
| Deploy | Files are pushed atomically to the CDN | CI pipeline, hosting platform |
| Runtime | Browser loads files and calls APIs for dynamic data | Serverless functions, SaaS APIs |
Deploys are usually atomic and immutable: a new version goes live only when every file is uploaded, and the previous version remains available for instant rollback. This removes the half-updated state that occurs when files are copied onto a running server.
Core principles and rendering variants
Jamstack rests on two principles: pre-rendering as much as possible and decoupling the presentation layer from data and business logic. Over time, purely static builds proved too slow for very large sites, so several hybrid rendering modes appeared that keep the CDN-first model while relaxing the full rebuild requirement.
| Variant | When pages are built | Best fit |
|---|---|---|
| Static site generation (SSG) | All pages at deploy time | Blogs, documentation, marketing sites |
| Incremental static regeneration | Rebuilt in the background after a set interval | Large catalogs with periodic updates |
| Deferred or on-demand builds | On first request, then cached | Sites with tens of thousands of rarely viewed pages |
| Client-side rendering islands | Static shell, dynamic parts in the browser | Pages with small interactive widgets |
| Edge rendering | Per request at CDN edge nodes | Personalization close to the user |
The more a project relies on per-request rendering, the less it differs from a conventional server-rendered site. Many practitioners now treat Jamstack as a set of practices rather than a strict definition, centered on static delivery, Git-based workflows and API-driven features.
Jamstack compared with other web architectures
Jamstack is closely related to headless architecture, but the two are not identical. Headless describes separating the content backend from its presentation; Jamstack describes how the frontend is built and delivered. A headless CMS can feed a Jamstack site, a mobile app or a server-rendered site equally well.
| Aspect | Jamstack | Monolithic CMS | Server-side rendered app |
|---|---|---|---|
| Page generation | At build time | Per request, often cached | Per request |
| Hosting | CDN and static storage | Web server with database | Application server |
| Attack surface | Small, no live database | Larger, plugins and admin panel | Medium, depends on code |
| Content freshness | Delayed until next build | Immediate | Immediate |
| Scaling under traffic spikes | Handled by the CDN | Needs caching and capacity | Needs capacity planning |
The key trade-off is performance and security against content freshness. A static page cannot reflect a change until a build finishes, while a monolithic system shows it immediately but must protect and scale a live backend.
When Jamstack is the right choice
Jamstack fits best when most visitors see the same content and updates happen minutes or hours apart rather than seconds. Documentation portals, company websites, campaign landing pages, product catalogs and blogs are classic candidates, because they gain fast load times and low hosting costs.
It fits poorly when every page depends on real-time, user-specific data, such as banking dashboards, social feeds or collaborative editors. Those applications still benefit from static assets, but their core value lies in a live backend.
| Project | Recommended approach | Reason |
|---|---|---|
| Documentation with 2,000 pages | Full static generation | Content changes with releases |
| E-commerce with 50,000 products | Hybrid static plus on-demand builds | Full builds would take too long |
| News site with breaking updates | Server rendering with CDN caching | Freshness matters within seconds |
| Marketing site edited by non-developers | Static site with headless CMS | Visual editing plus fast delivery |
| Logged-in analytics dashboard | Single-page app with API backend | Data is personal and live |
Limitations and common pitfalls
The most frequent problem is build time growth. A site with tens of thousands of pages can take many minutes to rebuild, so a typo fix waits for the whole pipeline. Incremental builds, caching between builds and on-demand rendering reduce this delay, but they add complexity.
- API sprawl: many third-party services each bring their own costs, limits, outages and data contracts.
- Editor experience: content teams lose instant preview unless the CMS offers preview builds.
- Hidden server logic: serverless functions reintroduce backend code that needs monitoring and security reviews.
- JavaScript weight: heavy client-side frameworks can erase the speed advantage of static HTML.
- Vendor coupling: hosting-specific features such as edge functions can make migration harder.
Teams avoid most of these issues by keeping pages genuinely static where possible, limiting client-side JavaScript, and choosing APIs with clear service levels and export options.
Put simply
A Jamstack website is like a shop that prepares its products before opening hours. Nothing is made to order. The pages are finished in advance and placed on shelves in many cities. Visitors pick them up instantly from the nearest shelf.
Some tasks still need to happen live, such as a payment or a search. For those, the page asks a specialized service for help. The result is a fast, secure site that is cheap to host. The trade-off is simple: changes appear only after the pages are rebuilt.
In practice
A software company runs product documentation with about 1,500 pages in Markdown files stored in a Git repository. Previously, a server-based CMS rendered every page on request, and traffic spikes after each release slowed the site.
The team moves to a static site generator that builds the documentation in roughly two minutes on every merge. Files are deployed to a CDN, search uses a hosted search API, and a feedback form posts to a small serverless function.
After the switch, pages load from nearby edge servers, release-day traffic no longer affects response times, and the team retires a database server. Each change becomes a reviewed commit with instant rollback, which also gives the writers a clear history of every edit.