Nuxt 3 SSG Deployment on Static Hosts: Netlify, Vercel, Cloudflare

1. Why Static Site Generation for Nuxt 3

Static Site Generation in Nuxt 3 means that every page of the application gets fully generated as an HTML file at build time, instead of being rendered again on a server for every request. The result is a directory of pure static files that can be copied to any web server or static host, with no Node.js runtime required in production at all. For marketing pages, documentation and blogs with a manageable rate of change, this is often the most robust and cheapest deployment option available.

The decisive advantage of Static Site Generation over server side rendering lies in operational safety: a static file cannot crash, has no serverless cold starts and scales automatically through a content delivery network without any application logic running per request. That exact property makes static Nuxt 3 builds the preferred choice for projects where resilience and low latency matter more than real time personalization.

A practical example illustrates the difference: a company website with fifty subpages that changes editorially once a week barely benefits from server side rendering on every request. With Nuxt 3 and Static Site Generation, the entire page tree gets generated once at build time and then delivered through an edge network, so every request is answered directly by the nearest edge node without any compute load on an origin server.

2. Understanding nuxt generate in detail

The nuxt generate command is the central building block for Static Site Generation in Nuxt 3. Internally it first starts a build in the background, then crawls every route reachable through links inside the application and renders each discovered route into its own HTML file in the output directory .output/public/. This crawler automatically follows every <NuxtLink> in the application, which in most cases eliminates the need to maintain a manual route list.

An important distinction for Static Site Generation is the difference between nuxt build and nuxt generate: nuxt build produces a Nitro server that renders at runtime, while nuxt generate additionally runs the full crawling and prerendering step. At the end of nuxt generate, a purely static directory exists that works without any Node.js execution at all. For projects with exclusively static requirements, nuxt generate is therefore the correct command inside the CI pipeline, not nuxt build.

# Standard command for full static site generation
npx nuxt generate

# Resulting output structure — pure static files, no Node.js needed
.output/
└── public/
    ├── index.html
    ├── about/
    │   └── index.html
    ├── blog/
    │   ├── index.html
    │   └── my-first-post/
    │       └── index.html
    └── _nuxt/
        └── [hashed assets]

# Preview the generated static build locally
npx serve .output/public

3. Discovering dynamic routes for prerendering

The automatic crawler behind Static Site Generation in Nuxt 3 only finds routes that are actually linked through <NuxtLink> elements. Dynamic routes such as /blog/[slug].vue, whose concrete values come from an API or a content module, are not automatically guessed by the crawler. For this case, the Nuxt configuration must be told explicitly which concrete paths should additionally be rendered.

The nitro.prerender.routes option in nuxt.config.ts accepts either a fixed list of paths or a function that dynamically loads every id from the data source at build time and generates the full path list from it. This pattern matters especially for blogs, product catalogs or documentation sites with hundreds of subpages, where manually maintaining the route list would be unrealistic.

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    prerender: {
      // Crawl links automatically, plus explicitly discovered routes
      crawlLinks: true,
      routes: await getAllBlogSlugs()
    }
  }
})

// Dynamically fetch all slugs at build time
async function getAllBlogSlugs() {
  const posts = await $fetch('https://api.example.com/posts')
  // Turn each post id into a concrete route to prerender
  return posts.map((post) => `/blog/${post.slug}`)
}

4. Route rules: hybrid rendering per path

Nuxt 3 allows deciding for every route individually how it should be rendered, through the routeRules option in nuxt.config.ts. For a primarily static project, individual paths can still be exempted from the prerendering requirement or given their own caching behavior. This fine grained control becomes valuable when an otherwise fully static Nuxt 3 project needs a single server side API route for a contact form or a webhook.

An important detail for Static Site Generation in the narrow sense: once a route is marked with ssr: false, it disables server side rendering for exactly that path and instead delivers a minimal HTML shell that gets hydrated client side. This makes sense for areas like an admin dashboard behind a login, which should not be publicly indexed anyway and whose content only becomes visible after authentication.

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    // Homepage and blog fully prerendered as static HTML
    '/': { prerender: true },
    '/blog/**': { prerender: true },

    // Admin area rendered client side only, no prerendering
    '/admin/**': { ssr: false },

    // Contact API route stays server rendered even in a static build
    '/api/contact': { cors: true }
  }
})

5. Deployment to Netlify

Netlify automatically recognizes a Nuxt 3 Static Site Generation build once the build command is set to nuxt generate and the publish directory to .output/public. The big advantage with Netlify is native deploy preview integration: every pull request automatically produces its own preview URL with the generated static build, which considerably eases code review because reviewers see the change live right away without running anything locally.

For forms without a backend, Netlify offers its own form handling feature, which combines well with a purely static Nuxt 3 build since no dedicated server for form processing is needed. Redirects and header rules are defined through a netlify.toml file at the project root, maintained alongside the Nuxt configuration and working independently of the Nuxt build.

# netlify.toml
[build]
  command = "npm run generate"
  publish = ".output/public"

[build.environment]
  NODE_VERSION = "20"

[[redirects]]
  from = "/old-page"
  to = "/new-page"
  status = 301

[[headers]]
  for = "/_nuxt/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

6. Deployment to Vercel

Vercel also automatically recognizes Nuxt 3 projects and offers a particularly close integration with the Nitro preset for Vercel when it comes to Static Site Generation builds. It matters that purely static deployments explicitly configure nuxt generate as the build command, since Vercel otherwise defaults to a hybrid server mode with serverless functions, which is unnecessary for pure static hosting and can cause extra costs.

Environment variables are managed in the Vercel dashboard and are available during the build process, for example for API endpoints from which prerendering routes get loaded dynamically. Vercel additionally offers automatic preview deployments per branch, which in combination with Nuxt 3 Static Site Generation enables fast feedback on every change without operating a separate staging system.

{
  "buildCommand": "nuxt generate",
  "outputDirectory": ".output/public",
  "framework": null,
  "installCommand": "npm ci"
}

7. Deployment to Cloudflare Pages

Cloudflare Pages is a good choice for Static Site Generation projects that want to benefit from a particularly large global edge network. The build command stays identical to the other platforms, nuxt generate, with the output directory .output/public. An advantage of Cloudflare Pages is the close integration with Cloudflare Workers, should individual dynamic functions be added later without changing the rest of the architecture.

For projects with strict data protection requirements within the EU, it matters that Cloudflare works with regional services that allow restricting data processing to European data centers. That sets Cloudflare Pages apart from other providers where such a regional restriction is not always granularly configurable. For a team already running DNS and CDN through Cloudflare, adding Cloudflare Pages for the static Nuxt 3 build is usually the path with the fewest additional contractual parties.

# Cloudflare Pages build configuration (dashboard settings)
Build command:      npm run generate
Build output dir:   .output/public
Root directory:      /
Node.js version:     20

# Manual deployment via Wrangler CLI as an alternative
npx wrangler pages deploy .output/public --project-name=my-nuxt-site

8. Common pitfalls with static deployment

The most common mistake with Static Site Generation in Nuxt 3 is forgetting dynamic prerender routes. Without the explicit nitro.prerender.routes configuration, only pages the crawler finds through links get generated. If a detail page is not linked anywhere, for example because it is only reached through a direct URL, it is completely missing from the generated build and later returns a 404 error on the static host.

A second typical pitfall involves useState and other server side shared state. With Static Site Generation, every page runs as an isolated prerendering process, which means global state between different pages during generation is not shared the way it would be on a classic server. A third mistake is using absolute, environment dependent URLs in API calls during the build, which resolve differently in the CI environment than locally and can lead to empty data in the generated HTML without producing a visible build error.

9. Static hosts compared directly

All three platforms presented support Static Site Generation with Nuxt 3 reliably, but differ in details that can tip the scale depending on project requirements.

In practice, a team's existing infrastructure often decides the platform choice. Anyone already using Cloudflare for DNS usually sticks with Cloudflare Pages. Teams closely tied to the Vercel ecosystem and switching frequently between SSR and Static Site Generation benefit from the seamless Nitro integration at Vercel. Netlify remains a solid, platform independent choice with particularly mature deploy preview features for teams with an intensive review process.

10. Summary

Static Site Generation with Nuxt 3 reliably solves the problem of delivering applications without operating Node.js in production. nuxt generate crawls every reachable route automatically, while dynamic routes need to be explicitly added with nitro.prerender.routes. Route rules allow hybrid configurations where individual paths keep running server side or purely client side while the rest of the application stays fully static.

Netlify, Vercel and Cloudflare Pages all support this workflow with nearly identical build configuration, but differ in details like preview deployments, form handling and regional data protection options. The platform choice should follow the team's existing infrastructure, while the technical foundation, a cleanly configured nuxt generate build with complete prerendering, stays the same across projects.

11. FAQ: Nuxt 3 SSG Deployment on Static Hosts