Learn Nuxt - Deployment & Hosting

#Introduction

Code that only runs on a laptop isn't yet an application. Episode 20 covers how to deploy Nuxt to production: hosting platform choices, Nitro deployment targets, how to read the build output, and the correct flow from commit to a live site.

Nuxt's biggest advantage here: because Nitro abstracts the server, the same application can be deployed to Vercel, Netlify, Cloudflare, or your own Node server without changing application code. You just pick the matching preset.

#Deployment Options: Vercel, Netlify, Cloudflare, and Self-Host

#Popular Serverless Platforms

The three most common serverless platforms for Nuxt:

• Vercel: the smoothest integration, the default preset for Nuxt projects, edge support.
• Netlify: similar to Vercel, popular for static sites and functions.
• Cloudflare: deploys to a global edge network with a dedicated preset.

All of them can be connected directly to the repository — every push to main triggers an automatic build and deploy. That's the fastest path for both personal and team projects.

#Self-Hosting

If you need full control — local data, compliance, or a specific budget — run it yourself on a VPS or with Docker:

docker build -t belajar-shop .
docker run -p 3000:3000 belajar-shop

Self-hosting gives you complete flexibility with operational costs you manage yourself: monitoring, scaling, and updates. Choose according to your team's needs.

#Nitro Deployment Targets and Serverless

#Choosing a Preset

Nitro provides many deployment presets. Configure it through nuxt.config.ts:

Pilih preset Nitro

export default defineNuxtConfig({
  nitro: {
    preset: "vercel",
  },
})

Presets like vercel, netlify, cloudflare_pages, and node-server produce output matching the platform. Every platform has official Nuxt documentation — check the recommended preset.

#What Happens Behind the Scenes

At build time, Nitro translates your server routes and SSR into the form understood by the target platform — for example, serverless functions or edge service workers. You don't need to write a manual adapter; the preset handles everything.

#Build Output and Caching Strategies

#Understanding the Output Folder

The build produces a .output folder containing the entire application:

npm run build
ls .output

The public folder holds static assets, and server holds the ready-to-run server entry point. Static assets are usually served from the platform's CDN, while the server entry runs as a function.

#Caching on the Platform

Leverage the caching strategies we set up with routeRules in episode 14. Prerendered pages are served as static files; swr pages are cached at the edge. Also set headers for static assets so the browser stores them:

Cache aset statis

export default defineNuxtConfig({
  routeRules: {
    "/_nuxt/**": { headers: { "Cache-Control": "public, max-age=31536000, immutable" } },
  },
})

Files under /_nuxt are hashed, so they're safe to cache for a very long time — their filenames change when content changes, so users always get the new version on deploy.

#Production-Ready Deployment Flow

#The Flow from Commit to Production

A mature deployment flow looks like this:

1. Developers push to a branch.
2. CI runs typecheck, lint, and tests (episode 19).
3. If it passes, a production build runs.
4. Deploy to staging for manual testing.
5. Once approved, deploy to production.

npm run build

Make sure environment variables are complete on the platform — NUXT_PUBLIC_* and the secrets from episode 8. Without the right env values, the application can run but break at runtime.

#Verifying After Deploy

Once live, verify: open a few important pages, check the error logs, and run a performance audit. Episode 22 will cover observability for continuous monitoring.

#Conclusion

Episode 20 brings your application into the real world: hosting choices from Vercel, Netlify, Cloudflare, to self-hosting; an understanding of Nitro presets for serverless; managing build output and caching; and a verified deployment flow from commit to production.

Key takeaways:

• Nuxt can be deployed to almost any platform thanks to Nitro presets.
• Vercel, Netlify, and Cloudflare are the smoothest serverless choices.
• Self-hosting with Docker gives full control with your own operational costs.
• The .output folder contains static assets and the server entry for the platform.
• Use routeRules for edge and browser caching.
• Make sure environment variables are complete before deploying to production.

In the next episode, episode 21, we will discuss edge and serverless runtime — deploying Nuxt on an edge runtime, serverless functions with the Nitro server, runtime differences and environment considerations, and edge versus serverless use cases.