Learn Vue - Deployment & Hosting

#Introduction

After all the episodes building the application, it's time to ship it into the real world. Deployment is the moment code becomes a product: the build must be correct, the environment must fit, and every route must work on the production domain.

Episode 20 covers how to take a Vue application to production: deploying to Vercel and Netlify, SPA and static site hosting including rewrite rules, configuring environment and build-time variables, plus a production deploy flow that can be repeated safely.

#Deploying to Vercel and Netlify

#Building from the dist Folder

Vercel and Netlify build automatically from the repo using the same commands:

npm install
npm run build

The build produces a dist folder containing HTML, JavaScript, CSS, and static assets. The platform auto-detects the Vue framework and puts a CDN in front of the build output.

#Deploying with the CLI

For full control, use the CLI:

npm install -g vercel
vercel --prod

vercel --prod uploads the build to production. Preview URLs can also be created before production for the team to review — a feature that makes deploying far less scary.

#SPA Hosting and Static Sites

#Rewrites for SPA Routing

An SPA with vue-router uses History mode, so every route must be pointed at index.html:

/*    /index.html   200

/* /index.html 200 makes Netlify send every path to the application. Without this rule, refreshing at /produk/1 shows a 404.

#Vercel Configuration

Vercel uses vercel.json for the same effect:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

"source": "/(.*)" catches every route and forwards it to index.html. The JavaScript router decides which page is shown.

#Firebase Hosting

Firebase also offers static hosting:

npm install -g firebase-tools
firebase init hosting
firebase deploy --only hosting

firebase deploy --only hosting uploads the dist folder to Firebase's CDN. Firebase Hosting is a good fit when the application already uses other Firebase ecosystem services.

#Environment and Build-time Variables

#Build-time Variables

VITE_ variables are replaced at build time, not at runtime:

VITE_API_BASE_URL=https://api.example.com npm run build

VITE_API_BASE_URL is baked into the bundle during build. Its value can differ per environment: staging uses the staging URL, production uses the production URL. Make sure secrets never enter build variables.

#Platform Configuration

On Vercel and Netlify, set variables in the dashboard or a config file, and those values are automatically used during the build. Store values in the platform's secret manager, not in the repo.

#Production Deployment Workflow

• Use the main branch as the production source and staging for previews.
• Build and deploy automatically from CI after tests pass.
• Review the preview URL before approving a release.
• Provide rollback: hosting platforms keep deployment history.
• Monitor health endpoints and error rates after deploying.

#Summary

Episode 20 delivered your application to production: correct builds for Vercel and Netlify, rewrite rules for SPA hosting, Firebase Hosting as an alternative, build-time environment variables, and a deploy flow that repeats safely.

Key takeaways:

• Vercel and Netlify build from the repo automatically.
• An SPA needs rewrite rules so routes don't 404.
• Firebase Hosting provides static hosting from a CDN.
• VITE_ variables are resolved at build time.
• Store secrets on the platform, not in the repo.
• Always have a rollback ready for every release.

In the next episode 21, we'll cover server-side rendering and Nuxt — SSR basics with Nuxt.js, hybrid rendering and static generation, Nuxt's data fetching model along with middleware, and when to choose SSR over an SPA.