The commit lands, CI finishes in forty seconds, and the CDN updates. The demo impresses leadership: blazing pages, automatic deploys, no visible server. Two weeks later, full-text search returns nothing because it called an Elasticsearch API that was never in the quote. Customer accounts run through Auth0. The cart hits a stock API hosted somewhere else. The "static site" actually hides five dynamic services that were never budgeted or monitored.
The Jamstack promise — JavaScript, APIs, Markup — holds when you pre-render HTML and serve it from a nearby edge network. Fast publishing, good resilience under spikes, low origin load for static content. The classic mistake is believing everything becomes static while cart, auth, comments, search, and live pricing remain dynamic by nature.
Jamstack speeds delivery; it does not remove the need to map backends. Before the first git push, list what stays live — and where it runs.
What stays static and what cannot
The build can produce blog posts, translated landing pages, stable product docs, and optimized assets ahead of time. But as soon as a visitor logs in, filters a live catalog, or pays online, you leave pure static territory. Cart, user session, instant search, server-validated forms, and payment webhooks all need a dynamic layer somewhere — serverless, a dedicated API, a managed database, or a third-party service.
That boundary is not academic: it drives hosting budget, security surface, and monitoring plans. A fully static marketing site is cheap to serve. A platform with accounts and search costs whatever its APIs cost, whether or not they are buried in "serverless included" marketing.
Hosting: three layers to separate
A credible Jamstack setup separates at least three layers. The Git repo feeds CI — GitHub Actions, GitLab CI, or the platform's native integration. The front host — Netlify, Vercel, Cloudflare Pages, S3 with CloudFront — serves HTML and assets from the CDN. The headless or Git-based CMS, plus dynamic services, often live on other accounts: Sanity, Contentful, Strapi, a Laravel API on a VPS, a managed Postgres instance.
For a pure brochure site without a remote CMS, the static site guide is enough. Once editors touch content through a web UI, the split described in headless CMS becomes central. Do not merge CDN billing with CMS billing: two contracts, two SLAs, two possible regions.
Preview, freshness, and costs the demo skips
Preview branches — one URL per pull request for editors — are sometimes included, sometimes billed by build minute. On large sites, a full deploy can take minutes; hence incremental builds, incremental static regeneration, or on-demand revalidation on Next.js and equivalents. Editorial freshness is a trade-off between build cost and acceptable delay: publishing hourly does not face the same constraints as a minute-by-minute news feed.
Heavy media and API calls outside the main CDN can also inflate egress bills. If images sit in a bucket far from visitors, the CDN will not fix everything. The choosing a cloud region guide applies to storage as much as to the front.
The climax: fast deploys hide the API map
Compare edge platforms and object storage hosts via our directory and comparator while filtering region, build minutes, and serverless functions.
Decide and move forward without blind spots
Start with an exhaustive list of truly static pages and flows that require an API or database. Choose a freshness strategy — incremental regeneration, CMS webhooks, partial server rendering — matched to real editorial cadence, not the ideal slide deck. Budget build minutes, function invocations, and CMS subscription alongside the CDN, not instead of them. Test editorial preview before launch: if authors cannot validate a page without deploying all of main, the workflow will break in production. Finally, document who responds when the search API fails on a Friday night — the static front will stay up, but the site will be incomplete.
Frequently asked questions
Does Jamstack mean zero servers?
No. HTML can be pre-rendered and served from a CDN, but authentication, search, payments, and live data still hit APIs or functions. Jamstack mostly describes how markup is delivered, not the absence of dynamic behavior.
How do you handle content updated several times a day?
A full rebuild on every edit does not scale editorially. Use incremental static regeneration, on-demand revalidation, or hybrid rendering, plus CMS webhooks that rebuild only affected pages.
Where should a Jamstack site be hosted?
The static front fits Netlify, Vercel, Cloudflare Pages, or object storage with a CDN. The headless CMS, databases, and auth services usually live elsewhere — see the headless CMS and static site guides.
What about contact forms on Jamstack?
A static page cannot handle POST on its own without a dynamic layer. You need a serverless function, a small API, or a third-party service — otherwise the form is an empty shell server-side.
Before saying "we're on Jamstack," ask one question: what stays dynamic, and where does it run? Without that list, you have a CDN — not an architecture.