← Guides

JAMstack examples: what to build with a static site generator

Six kinds of site that are better built static — a blog, docs, a landing page, a portfolio, an app's front end and a company site — which generator suits each, how the dynamic parts work, and a live example of every one.

Last checked

JAMstack — JavaScript, APIs and Markup — is a way of building websites. A static site generator turns your content (Markdown, templates, components) into a folder of finished HTML, CSS and JavaScript before anyone visits; the host serves those files as they are; and anything that has to be dynamic happens in the visitor’s browser, or through an API the browser calls.

Astro, Hugo, Eleventy, Nuxt, SvelteKit and Next.js can all write that folder, so the useful question is not whether a site counts as JAMstack. It is which parts of your site have to be decided at the moment someone asks for a page. If the answer is “none”, or “only a form and a few API calls the browser can make”, generate it. The rest of this guide is six sites where the answer is “none”, what each one looks like, and a live example of every one that you can copy.

If “static” itself is the unfamiliar part, what static site hosting is is the place to start.

1. A blog

What it is: posts written in Markdown, an index of them, tags, and an RSS feed. The canonical static site — every page is known the moment you finish writing it.

Generators that suit it: Astro, Hugo, Eleventy, Jekyll. Pick Hugo when the archive runs to thousands of posts and you want builds that finish before you have looked away. Pick Astro when you want components inside your posts. Pick Eleventy when you want nothing between you and the HTML.

The dynamic parts, and where they go:

  • RSS and the sitemap are generated at build time, like any other file. There is nothing to run.
  • Comments are built in. On One9x Pages, one snippet in your post layout puts a thread under each post, and new comments wait in your dashboard for approval — no third-party embed, and no account for commenters (comments).
  • A newsletter signup is a form. On One9x Pages, a site’s forms post to the site itself and land in your dashboard — no form service, no third-party endpoint in your HTML.

Live example: astro-blog.one9x.app — posts, tags, RSS, a sitemap and dark mode. Start from one9x/template-astro-blog.

2. Documentation

What it is: a sidebar of pages, a search box, code samples, and an “edit this page” link. Docs change in the same pull requests as the code they describe, so they belong in the same repository and the same review.

Generators that suit it: Starlight (built on Astro), VitePress, Docusaurus, MkDocs. They differ mostly in which language’s ecosystem they come from; choose the one your project’s contributors already know.

The dynamic part is search, and it is not dynamic any more. Starlight, VitePress and MkDocs build the search index at build time, and the visitor’s browser searches it. There is no search server to run.

The other thing docs want is review before publish, and static hosting is good at it: every release is a complete, separate copy of the site, so a pull request can get its own preview URL that a reviewer clicks through before anything goes live.

Live example: starlight-docs.one9x.app — sidebar, search, light and dark. Start from one9x/template-starlight-docs.

3. A landing page

What it is: one page for a product launch, an event or an app. A headline, what it does, a few reasons to believe it, and a signup.

Generators that suit it: Astro, Eleventy, or plain HTML. A landing page is one page, so the generator earns its keep through components and image handling rather than through routing.

The dynamic part is the signup form — historically the one thing that pushed a landing page onto a server or a form service. On One9x Pages it is a form: define it in the dashboard, paste the markup, and signups appear on the form’s page in your dashboard. Every plan includes a Forms plan, the free one too.

Why static matters most here: a landing page is the first thing a visitor ever sees from you, and files served straight from cache are as fast as a page gets.

Live example: astro-landing.one9x.app — hero, features, FAQ and a working waitlist. Start from one9x/template-astro-landing.

4. A portfolio or personal site

What it is: who you are, a few projects told as short case studies, and a way to get in touch.

Generators that suit it: Eleventy, Hugo, Astro — whichever you will still be comfortable opening in two years.

That is the real reason to build it static: a personal site is the site you neglect. A folder of HTML on a managed host has no plugins to update, no database to back up and nothing to patch, and it is serving exactly what it served the day you left it. The contact form is, again, a form.

Live example: eleventy-portfolio.one9x.app — projects, case studies, a CV page and a contact form. Start from one9x/template-eleventy-portfolio.

5. A web app’s front end

What it is: a React, Vue or Svelte app built with Vite, talking to your API. This is the A in JAMstack: the product is dynamic, but the front end — the JavaScript, CSS and the one index.html that loads them — is a folder of files like any other.

The dynamic part is all of it, and all of it happens in the browser: sign-in, data, everything goes to your API. The host’s only job is to serve the bundle fast and to send index.html for every route the client-side router owns. On One9x Pages that is --spa.

Live example: vite.one9x.app. Start from one9x/template-vite.

6. A company or marketing site

What it is: a home page, a product page, pricing, a blog, docs and the legal pages — several of the sites above under one roof.

The live example is the page you are reading. one9x.com is an Astro site: the docs and guides are Markdown content collections, the build runs in CI, and it is released to One9x Pages with the same CLI our customers use. The one part that needs a backend, the abuse-report form, posts to an API, which is exactly what the A in JAMstack is for.

Which generator, in one table

GeneratorWritten inPick it when
AstroJavaScriptContent sites where you want components, and JavaScript only where a page needs it
HugoGo, one binaryLarge sites, very fast builds, and no node_modules
EleventyJavaScriptSmall sites where you want full control of the HTML
StarlightJavaScript (Astro)Documentation, with search and navigation already built
VitePressJavaScript (Vue)Documentation for a Vue or JavaScript project
JekyllRubyA site that already lives on it — there is little reason to start one new
Next.js static exportJavaScript (React)A React app that already uses Next.js
ViteJavaScriptSingle-page apps

Which folder each one builds to, and which of them need --spa, is in Frameworks.

When static is the wrong choice

Some sites need a server, and generating them is the harder path:

  • The HTML itself differs per visitor. A logged-in page can be static HTML that fetches its data in the browser — that is section 5. But if the server has to render something different for each person, you need a server.
  • Users write the content. Forums, wikis and anything with accounts and posts need a database and something accepting writes. A form collects submissions; it does not make a site a forum.
  • Huge catalogues that change by the minute. A hundred thousand product pages whose stock moves all day means a rebuild for every change. Render those on request.
  • Code that has to run beside the site. Calling a paid API with your secret key, say. That needs a function or a server, and One9x Pages runs neither — there are no functions here, and no redirect rules or custom response headers either. Netlify, Vercel and Cloudflare all run functions next to your files; if you need that, start there.

Start from a template

Each example above is a GitHub template repository. Press Use this template, set two values in the new repository’s settings, and every push deploys it: a pull request gets a preview URL, and a merge to main goes live. They are all on one page, with the minimal framework starters beside them, at Templates.

One9x Pages hosts the finished folder

Drop a build directory on the dashboard or point the CLI at it, and get an HTTPS URL with atomic deploys, a preview per release and instant rollback. The free plan takes three sites and does not expire.