Deployment & Best Practices

Everything covered so far has been about building the app. Shipping it is a separate question, and Nuxt's answer is more flexible than most frameworks': the same codebase can deploy to a traditional Node server, a serverless platform, or a static host, without you rewriting anything — because Nitro (the same engine behind server/api/ routes) compiles your app differently for each target.

Nitro presets

# Build for the target platform via an environment variable or CLI flag
NITRO_PRESET=vercel npx nuxi build
NITRO_PRESET=cloudflare-pages npx nuxi build
NITRO_PRESET=node-server npx nuxi build   # the default: a standalone Node server

Most hosting providers with first-party Nuxt support (Vercel, Netlify, Cloudflare) auto-detect the right preset from their build environment, so in practice you often don't set this by hand at all — but knowing it exists explains why deploying the same project to two different platforms can produce meaningfully different output artifacts (a server.mjs you run yourself, versus a set of edge functions).

Choosing a rendering strategy per environment

Revisit routeRules (from the config-basics lesson) with deployment in mind: a marketing site with no real backend need might run entirely as SSG (nuxi generate) on a plain CDN, which is both the cheapest and the fastest option since there's no server compute at request time at all. An app with authenticated, per-user content needs SSR or a hybrid mix, and should be deployed to a platform that runs Nitro's server output, not just static files.

A closing checklist

A few habits from this course are worth treating as non-negotiable before shipping:

• No secrets in public runtime config or in client-bundled code — anything sent to the browser is visible to anyone who opens dev tools.
• Every useFetch/useAsyncData call has an error path — an unhandled rejection during SSR can take down the response for that request.
• Auth checks live in middleware, not onMounted — so protected data is never rendered server-side for a logged-out user, even briefly.
• SEO tags are set with useSeoMeta/useHead per page, not left at sitewide defaults, for any page that should show up distinctly in search or link previews.
• Route rules match reality — a page that's actually static shouldn't be paying SSR's per-request cost, and a genuinely dynamic page shouldn't be pre-rendered with stale data.

The theme across this whole course

Nearly every Nuxt feature covered here exists to answer one question: where and when should this code run — server or client, once at build time or on every request, before navigation or after. Vue itself doesn't have an opinion on that; a component works the same wherever it's mounted. Nuxt's job is to give you clear, composable tools (useFetch, useState, middleware, route rules, Nitro presets) to make that decision deliberately, page by page, instead of it being an accident of how the app happened to be wired together.