Jamstack static site hosting

To set up an automated pipeline for generating and hosting static sites using content from a headless CMS, you need four core components: a Headless CMS (for content entry), a Static Site Generator (SSG) (to turn data into HTML/CSS/JS), a Git-based CI/CD platform or webhook (to trigger builds), and a static hosting provider (to serve the files globally via CDN).just-ten-miles.medium.com+1

Step 1: Choose Your Technology Stack

Select tools that match your language preference and scale needs:

Layer	Popular Options	Best For
Headless CMS	Contentful, Strapi, Sanity, Decap CMS, Prismic	Managing structured content and publishing via API
Static Site Generator (SSG)	Next.js (SSG mode), Astro, Nuxt, Eleventy (11ty)	Compiling dynamic API content into ultra-fast static pages
CI/CD & Source Control	GitHub / GitLab + Vercel, Netlify, or GitHub Actions	Automating builds on code push or CMS webhooks
Static Hosting & CDN	Vercel, Netlify, Cloudflare Pages, AWS S3 + CloudFront	Global edge distribution and automatic HTTPS

Step 2: Configure the Headless CMS & Webhooks

1. Model your content: Define your content types (e.g., Blog Posts, Authors, Pages) inside your headless CMS (such as Contentful, Sanity, or Strapi).
2. Create a Webhook: In your CMS settings, navigate to Webhooks and add a new webhook URL.
   • Trigger event: Publish, Unpublish, or Delete content.
   • Target URL: Your hosting platform's build-hook URL (e.g., a Netlify or Vercel build hook) or a CI/CD pipeline trigger.

Step 3: Build the Static Site Generator Project

1. Initialize the SSG project locally:

# Example with Astro or Next.js
npx create-astro@latest my-static-site
# or
npx create-next-app@latest my-static-site

2. Fetch CMS content at build time: Write your data-fetching logic inside your page templates or SSG data hooks so the site queries the CMS REST/GraphQL API during the build process.
   • Astro/Next.js example: Make an async request to your CMS API inside a server-side component or getStaticProps function.
3. Test the build command:

npm run build

Verify that it outputs a folder of pure static assets (e.g., /dist or /.next/server/app or /out).

Step 4: Connect to a CI/CD Pipeline and Host

The easiest and most resilient pattern is using a platform that natively manages both Git-triggered builds and static hosting (such as Vercel, Netlify , or Cloudflare Pages):

1. Push your code to Git: Initialize a Git repository and push your project to GitHub, GitLab, or Bitbucket.
2. Import into your hosting provider:
   • Go to Vercel or Netlify and click Add New Project / Import Site.
   • Select your Git repository.
3. Configure Build Settings:
   • Framework Preset: Select your SSG (e.g., Astro, Next.js, Eleventy).
   • Build Command: npm run build (or astro build, eleventy).
   • Publish Directory: dist, out , or .next.
4. Add Environment Variables: In your hosting provider's dashboard, add your sensitive CMS API keys, space IDs, or tokens (e.g., CMS_API_KEY, CONTENTFUL_SPACE_ID ) so the build server can securely query your content.
5. Paste the CMS Webhook: Copy the generated Build Hook URL from your host (Vercel/Netlify) and paste it back into your Headless CMS webhook settings. Whenever you hit "Publish" in the CMS, it pings the host, triggers a fresh build, and deploys the updated static files across the CDN in seconds.reddit.com+1

If you'd like to narrow this down, tell me:

• Which Headless CMS and SSG you are leaning toward (or if you need a recommendation)
• Whether you prefer serverless hosting (Vercel/Netlify) or self-hosting on a VPS/S3 bucket

I can write out a concrete project template or configuration for your stack.

How to build a static-site pipeline using a headless CMS

A good approach is to create an automated content-to-deployment pipeline that takes content from a headless CMS, generates static HTML/CSS/JavaScript, and deploys the result to a static hosting platform.

The key idea is that your CMS manages content separately from your website, while your build pipeline turns that content into a fast, production-ready website.

1. Understand the architecture

Headless CMS

Content, images, pages, blog posts

Examples: Sanity, Strapi, Contentful

(API / Webhook)

CI/CD Pipeline

Fetch content → Build → Test → Generate static files

Examples: GitHub Actions, GitLab CI

Static Site Generator

Astro, Next.js, Eleventy, Hugo

Produces HTML, CSS, JS and assets

Static Hosting / CDN

Cloudflare Pages, Netlify, Vercel

Published Website

Fast, globally distributed static pages

The workflow should also support preview deployments, error notifications, and automatic rebuilds when editors publish content.

2. Choose your technology stack

A practical starting stack would be:

Component	Recommended option
CMS	Sanity or Strapi
Static generator	Astro
Content integration	CMS REST API or GraphQL
Source control	GitHub
CI/CD	GitHub Actions
Hosting	Cloudflare Pages or Netlify
CDN	Cloudflare
Webhook	CMS publish event

Why Astro? It is particularly well suited to content-heavy websites because it generates static pages efficiently and can use interactive JavaScript only where needed.

3. Connect the CMS to your static-site generator

The next step is to fetch published content from the CMS during the build.

For example, suppose your CMS contains blog posts with these fields:

{
  "title": "Getting Started with Static Sites",
  "slug": "getting-started-static-sites",
  "body": "Article content goes here...",
  "publishedAt": "2026-11-01",
  "status": "published"
}

Your Astro project can retrieve this content using the CMS API.

Install dependencies:

npm create astro@latest my-static-site
cd my-static-site
npm install

Create a content-fetching module:

src/lib/cms.js

const CMS_API = import.meta.env.CMS_API_URL;
const CMS_TOKEN = import.meta.env.CMS_API_TOKEN;

export async function getPosts() {
  const response = await fetch(`${CMS_API}/posts`, {
    headers: {
      Authorization: `Bearer ${CMS_TOKEN}`
    }
  });

  if (!response.ok) {
    throw new Error("Failed to fetch CMS content");
  }

  const posts = await response.json();

  return posts.filter(
    post => post.status === "published"
  );
}

Then generate individual static pages.

src/pages/blog/[slug].astro

---
import { getPosts } from "../../lib/cms";

export async function getStaticPaths() {
  const posts = await getPosts();

  return posts.map(post => ({
    params: { slug: post.slug },
    props: { post }
  }));
}

const { post } = Astro.props;
---

<html>
  <head>
    <title>{post.title}</title>
  </head>
  <body>
    <h1>{post.title}</h1>
    <article set:html={post.body} />
  </body>
</html>

This generates a separate HTML page for every published article.

Note: Sanitize CMS-provided HTML before rendering it with set:html. Adjust the API response parsing to match your CMS.

Astro supports fetching CMS content during builds and generating pages from dynamic routes.docs.astro.build+2

4. Automate the build and deployment pipeline

This is where CI/CD comes in.

The desired sequence is:

1. A developer pushes website code to GitHub.
2. GitHub Actions installs dependencies.
3. The pipeline fetches content from the CMS.
4. Astro generates static files.
5. Automated tests validate the build.
6. The hosting platform publishes the generated files.

For GitHub Actions, create:

.github/workflows/build.yml

name: Build Static Website

on:
  push:
    branches:
      - main

  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install dependencies
        run: npm ci

      - name: Build website
        run: npm run build
        env:
          CMS_API_URL: ${{ secrets.CMS_API_URL }}
          CMS_API_TOKEN: ${{ secrets.CMS_API_TOKEN }}

      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: static-site
          path: dist/

This workflow builds your site and saves the generated files as an artifact.

For production, add a deployment step using your hosting provider's official deployment action or CLI. Store deployment credentials in GitHub Secrets.

GitHub Actions supports automated build and deployment workflows.docs.github.com

5. Trigger builds when CMS content changes

This is one of the most important parts of the architecture.

You don't want editors to have to contact developers whenever they publish a new article.

Instead, configure a CMS webhook.

For example, with Sanity:

1. Open your Sanity project settings.
2. Navigate to API and Webhooks.
3. Create a webhook.
4. Configure it to trigger when published content changes.
5. Set its destination to your hosting provider's build hook URL.

The resulting process is:

Editor publishes article
          |
          v
CMS sends webhook
          |
          v
Hosting build hook receives request
          |
          v
CI/CD starts new build
          |
          v
Fetch latest CMS content
          |
          v
Generate static website
          |
          v
Deploy to production CDN

Sanity supports configurable webhooks for document changes, including filtering and customized HTTP requests.www.sanity.io+1

Important: Use a protected webhook endpoint or secret token. Avoid exposing CMS API credentials in browser code.

If your CMS sends a webhook for every document update, consider filtering for published changes or batching rebuilds to avoid unnecessary deployments.

6. Host the generated static website

Once your build is successful, deploy the dist/ directory to a static hosting provider.

Three good choices:

Cloudflare Pages

• GitHub/GitLab integration
• Automatic deployments
• Preview deployments for branches
• Global CDN infrastructure

Good for fast, globally distributed websites.

Cloudflare Pages documentation

Netlify

• Git-based deployments
• Build hooks for external triggers
• Preview environments
• Custom domains and HTTPS

Good for CMS-driven publishing workflows.

Netlify documentation

Vercel

• Git integration
• Preview deployments
• Build automation
• CDN and custom domains

Good for Astro and Next.js projects.

Vercel documentation

For a straightforward implementation, I'd start with Astro, Sanity, GitHub Actions, and Cloudflare Pages.

Cloudflare Pages supports automatic deployment from connected Git repositories and preview deployments.developers.cloudflare.com+1

7. Add production safeguards

Before considering your pipeline production-ready, implement these features:

Also consider:

• Incremental builds: Avoid rebuilding everything if your generator and hosting platform support incremental generation.
• Scheduled rebuilds: Useful for content that changes automatically or expires.
• Draft previews: Allow editors to review unpublished content without exposing it publicly.
• SEO generation: Automatically generate sitemaps, canonical URLs, metadata, and structured data.

8. Recommended end-to-end implementation

Here's how I'd organize the project:

my-static-site/
│
├── .github/
│   └── workflows/
│       └── build.yml
│
├── src/
│   ├── components/
│   ├── layouts/
│   ├── lib/
│   │   └── cms.js
│   └── pages/
│       ├── index.astro
│       └── blog/
│           └── [slug].astro
│
├── public/
├── astro.config.mjs
├── package.json
└── .env

The production publishing lifecycle:

1. Content creation

   An editor creates or updates content in the headless CMS.

2. Content publication

   The editor publishes the content, triggering a webhook.

3. Automated build

   CI/CD retrieves the published content and generates static pages.

4. Quality checks

   Tests validate the generated website and detect errors.

5. Deployment

   The generated website is deployed to static hosting.

6. Distribution

   The CDN distributes the updated website to visitors.

9. Useful official resources

• Astro – CMS integration guides
• Astro – Data fetching
• GitHub – Automatic website deployment
• Sanity – Webhooks
• Cloudflare Pages – Git integration

My recommendation

Start with a full rebuild triggered by a CMS publish webhook. It is simpler to implement, easier to debug, and works well for most content-driven websites.

Move to incremental builds or more sophisticated event-driven processing only when your content volume or publishing frequency makes full rebuilds too expensive.

One important question: Which headless CMS are you planning to use?

That will help determine the exact API integration, webhook configuration, and deployment workflow.