JAMstack without the conference fog

JAMstack once stood for JavaScript, APIs, and Markup. As a slogan it grew to mean “pre-build your pages, talk to APIs from the browser or at build time, host the results on a CDN-ish static platform.” Beginners then meet product catalogs full of functions, edge middleware, and identity add-ons and assume those extras *are* JAMstack. They are optional.

This guide demystifies the core and maps it onto StaticHost, which hosts the markup/assets piece and intentionally does not run platform functions or remote builds.

The three letters, grounded

Markup. HTML you wrote or generated (Hugo, Eleventy, Astro static, Next export). That is what StaticHost stores.

JavaScript. Progressive enhancement or a full client app that runs after download. Still files. Routing must respect try_files $uri $uri/ =404SPA reality.

APIs. HTTP services elsewhere: CMS content APIs at build time, payment APIs at click time, form endpoints, auth vendors. StaticHost is not the API host.

If you can explain your project in those terms, you understand enough JAMstack to ship.

What beginners can ignore on day one

  • Edge workers
  • Platform serverless functions
  • Atomic branch deploy previews with twenty integrations
  • Arguments about whether the acronym is outdated

You need a build command (sometimes as simple as “save HTML”), an output folder, and HTTPS hosting. StaticHost: zip or GitHub of that output, HTTPS preview immediately, certificates on custom domains after DNS verifies, deploy history/rollback. No npm/hugo/jekyll on the server. No cPanel, email, built-in CDN product, or forever-free (trial ~1 day).

A minimal JAMstack-shaped project

  1. Write Markdown.
  2. Run Eleventy or Hugo locally → HTML.
  3. Upload _site/public to StaticHost.
  4. Contact form posts to a form SaaS.
  5. Optional: fetch public JSON from a headless CMS at build time and regenerate when content changes.

That is JAMstack practice without functions-as-a-service on the web host. When content changes, rebuild and redeploy—not “mutate the server database.”

Where StaticHost sits versus “full” JAMstack platforms

Full platforms may: run your build, inject env, attach functions, rewrite SPAs to index.html. Convenient, and sticky.

StaticHost: you run the build, you bring env at build time, you do not get functions, you do not get SPA fallback. Smaller product on purpose—compare where to host. Choose full platforms when functions are requirements; choose StaticHost when files and honesty about =404 are enough.

APIs without confusing them for hosting

NeedPattern
Blog contentBuild-time fetch from CMS → HTML files
SearchClient-side index or third-party search API
LoginExternal IdP; tokens in browser
CheckoutStripe.js-style client flows
ContactForm endpoint SaaS

None of these require PHP on StaticHost. If you need WordPress runtime, use a WordPress host.

Plans as you grow

Starter $9 (1 site, 2 GB). Pro $30 (3 sites, 10 GB, staging)—useful when “build with staging CMS keys” should not overwrite production. Scale $65 (10 sites, 30 GB). Business $130 (30 sites, 100 GB, teams).

Learning path

  1. What static hosting is
  2. Static site hosting for beginners
  3. Pick a generator guide (Hugo/Eleventy/Astro) or plain HTML
  4. Return here when someone says you “need functions” — ask which API is missing first

Often the missing piece is an external API, not a host-native function.

Worked example: recipe blog with a headless CMS

You store recipes as JSON in a headless CMS. Locally (or in CI):

node scripts/fetch-recipes.js   # writes Markdown or data files
npx @11ty/eleventy              # emits _site/
cd _site && zip -r ../recipes.zip .

Upload to StaticHost. HTTPS preview shows / and /recipes/sourdough/. Editors change CMS content; they do not SSH anywhere. A GitHub Action rebuilds on a webhook and publishes an artifact branch—git deploy. Contact form → form SaaS. Search → Pagefind or a client index built at generate time.

Nobody asked StaticHost to run Eleventy or to host a function that queries the CMS per request. When marketing demands WordPress admin, you either teach the rebuild workflow or move the blog to PHP hosting—wrong choice—instead of pretending JAMstack means “WordPress without WordPress.”

Failure table: beginner JAMstack traps

SymptomLikely causeFix
“JAMstack host won’t build”Expected remote npmBuild in CI; upload output
Deep link 404Assumed SPA fallbackHash or prerender files
Content stale after CMS editNo rebuild wiredWebhook → CI → redeploy
Looking for functions dashboardConfused optional add-ons for coreUse external APIs or other platform
Email from “the JAMstack host”No mailboxes hereForm/mail vendors
CDN checkbox anxietyStaticHost has no CDN productOptimize assets; add CDN later if measured

Extra procedure: explain JAMstack to a non-engineer stakeholder

Use this script:

“We pre-build the website into ordinary files—like exporting a PDF, but for web pages. Those files live on StaticHost with HTTPS. When we need data—forms, payments, content—we call specialized services. We do not run a big application server for the brochure pages. If we need a true app backend, that is a separate system on purpose.”

Then show the HTTPS preview before DNS. After they approve, attach the domain (verify → cert). Mention plans plainly ($9/$30/$65/$130), the short trial, and what is out of scope (email, cPanel, forever-free, host functions, SPA rewrite myths). Clarity early prevents “can we just install a plugin” week three.

Build-time vs request-time: the beginner fork

If data must be fresh on every browser request (live inventory counts, per-user HTML), you are leaving pure static hosting. If data can be minutes-to-hours stale, build-time generation fits StaticHost. Beginners often overestimate how “live” marketing content must be. A homepage rebuilt on each CMS publish via CI is still JAMstack-shaped and usually good enough.

Draw the fork on a whiteboard: left = rebuild+redeploy; right = application server. StaticHost lives on the left. APIs on the right can still be called from browser JavaScript for clicks and forms. Confusion starts when someone names a platform function “the JAMstack way” as if files were obsolete. Files remain the point; functions are optional glue you may host elsewhere. Keep learning on Starter pricing after the short trial until site count forces Pro or Scale.

FAQ

Is JAMstack dead as a term?

The term is quieter; the architecture (prebuild + APIs + static hosting) is still common. Judge architectures, not stickers.

Do I need a CDN to be JAMstack?

No. CDN helps globally; StaticHost does not bundle a marketing CDN tier. Optimize assets; add CDN later if measured need appears.

Can I add serverless later without redoing the site?

Yes—point the client at new APIs. You might also move hosts if you want functions colocated with hosting vendor tooling.

Does StaticHost run build plugins?

No. Your CI runs plugins; the host receives output.

Is a pure HTML site “JAMstack”?

It is static hosting. Add JS and APIs when you need them; do not force the acronym.