Deploying SSG

nuxi generate outputs plain HTML and JS — deploy to any static host like Cloudflare Pages, Netlify, Vercel, or an S3 bucket.

4 min read Level 2/5 #nuxt#deploy#ssg

What you'll learn

Run nuxi generate to produce a dist folder
Upload dist to a static host
Configure SPA fallback for client-side routes

If your content is the same for every visitor — marketing pages, docs, a blog — nuxi generate is the cheapest, fastest path to production. Static files served from a CDN, no Node server, no scaling worries.

Generate

npx nuxi generate

Nuxt crawls every reachable route, renders it, and writes the HTML to dist/:

dist/
├─ index.html
├─ about/index.html
├─ blog/
│  ├─ index.html
│  └─ hello-world/index.html
├─ 200.html              # SPA fallback
└─ _nuxt/                # hashed JS, CSS, fonts

Cloudflare Pages, Netlify, Vercel

All three auto-detect Nuxt and run nuxi generate for you. Connect your repo, they handle the rest. The build settings are:

# Build command
nuxi generate

# Output directory
dist

Manual Upload — S3 + CloudFront

For full control, sync to an S3 bucket and front it with CloudFront.

aws s3 sync dist/ s3://my-bucket --delete
aws cloudfront create-invalidation \
  --distribution-id ABC123 --paths '/*'

Set the CloudFront default root object to index.html, and add a custom error response — 404 from origin → /200.html — so client-side routes still resolve.

SPA Fallback

Routes that exist only in your client router (anything Nuxt couldn’t crawl, like hash-based admin tools) need a fallback HTML file. Nuxt writes 200.html for exactly this — point your host at it for “not found in static files”.

// netlify.toml — example
// [[redirects]]
//   from = "/*"
//   to = "/200.html"
//   status = 200

When SSG Won’t Work

SSG only works when content doesn’t depend on the request. If you need per-user dashboards, geolocation, auth-aware menus, or fresh data on every visit, go SSR (next lesson) or mix both with routeRules.

Deploying SSR — Node Hosts →