Vue Deployment
Build and publish a Vue application for production.
Overview
Deployment publishes a tested Vue application to a server or hosting platform so users can access it through a public URL. For a typical Vite-powered Vue single-page application, the production build creates optimized static files in dist that a host can serve.
Key concepts
- Test and build the application
- Preview the production output
- Configure public environment values
- Deploy the dist directory
- Support client-side route fallback
What is deployment?
During development, a Vue application usually runs on a local address such as http://localhost:5173. Deployment builds the application and places its production files on infrastructure that can serve them through a public domain.
Deployment turns a local portfolio, shop, dashboard, or learning project into an application other people can visit. It also creates a repeatable path for publishing fixes and new features.
The deployment workflow
Write code
↓
Run quality checks
↓
Build for production
↓
Preview the build
↓
Deploy generated files
↓
Verify and monitor the live applicationPrepare the application
Before publishing, verify behavior rather than relying only on the development server.
- Run tests, linting, and type checks used by the project
- Check navigation, forms, API requests, and error states
- Test important screen sizes and browsers
- Confirm image and asset paths
- Remove debugging code and unused dependencies
- Review accessibility and keyboard behavior
- Confirm production environment settings
Create a production build
Run the build script defined in package.json. A standard Vite Vue project uses the following command.
npm run buildThe build process compiles Vue single-file components, bundles modules, removes development-only behavior, optimizes assets, and creates browser-ready files.
Understanding the dist folder
By default, Vite writes the production output to dist. This generated directory is the deployable artifact and should not be edited manually because the next build replaces it.
dist/
├── assets/
│ ├── index-[hash].js
│ └── index-[hash].css
├── index.html
└── other generated assetsHashed asset names allow hosts and browsers to cache JavaScript and CSS safely. A changed file receives a new name during the next build.
Preview the production build
Previewing serves the actual production output locally. It can reveal missing assets, environment mistakes, or route problems that do not appear in development.
npm run previewThe preview server is for local verification, not a replacement for production hosting.
Choose a hosting approach
A client-rendered Vue application can be hosted anywhere that serves static files. Common options include static hosting platforms, cloud object storage with a content delivery network, and a traditional web server.
- Connect a Git repository for automatic builds
- Upload the contents of dist manually
- Build in a continuous integration workflow
- Serve dist through an existing web server
When configuring a platform, the usual build command is npm run build and the publish or output directory is dist.
Environment variables
Deployment environments commonly need different API base URLs or public feature settings. In Vite, variables intended for browser code use the VITE_ prefix and are read through import.meta.env.
# .env.production
VITE_API_BASE_URL=https://api.example.comconst apiBaseUrl = import.meta.env.VITE_API_BASE_URL;
const response = await fetch(apiBaseUrl + "/products");Client-side environment variables are bundled into public browser files. Never place database passwords, private API keys, signing secrets, or other credentials in VITE_ variables. Sensitive operations belong on a secure server.
Client-side routing fallback
With Vue Router history mode, navigating inside the application works in the browser. However, directly opening /courses causes the server to look for a physical courses file. Configure the host to serve index.html for application routes that do not match real files.
Request: /courses/vue
No matching static file
↓
Host serves /index.html
↓
Vue Router renders the matching pageWithout this SPA fallback, refreshing a nested route often produces a 404 even though navigation from the home page works.
Deploying under a subpath
If the site is hosted at a path such as example.com/my-app/ rather than the domain root, configure Vite's base option and ensure the router uses the same base.
// vite.config.js
import { defineConfig } from "vite";
import vue from "@vitejs/plugin-vue";
export default defineConfig({
plugins: [vue()],
base: "/my-app/"
});import { createRouter, createWebHistory } from "vue-router";
const router = createRouter({
history: createWebHistory(import.meta.env.BASE_URL),
routes
});Caching production files
Hashed JavaScript, CSS, fonts, and images can usually receive long cache lifetimes. index.html should be refreshed more frequently so it can point visitors to the newest hashed assets after a release.
Automated deployments
A continuous deployment workflow can build and publish after approved changes reach a chosen branch. Automation makes releases repeatable and prevents forgotten manual steps.
Push approved change
↓
Install locked dependencies
↓
Run checks and tests
↓
Create production build
↓
Publish dist
↓
Run a live health checkVerify the live application
- Open the public URL in a private browser window
- Refresh nested routes directly
- Check browser console and network errors
- Submit important forms
- Confirm APIs allow requests from the deployed domain
- Inspect mobile layout and loading behavior
- Verify the correct release and environment are active
Plan for updates and recovery
Deployment is a cycle, not a one-time event. Keep source code in version control, record which revision is live, monitor errors, and maintain a way to restore the last known good build if a release fails.
Common deployment problems
- Uploading source files instead of the dist output
- Forgetting to rebuild after changing code
- Using the wrong output directory
- Receiving 404 errors when refreshing Vue Router routes
- Using an incorrect base path for subpath hosting
- Missing production environment values
- Exposing secrets in frontend variables
- Blocked API calls caused by server CORS configuration
- Caching index.html so aggressively that users receive an old release
- Assuming a successful upload means the live application works
Best practices
- Make builds reproducible with a lockfile
- Run automated checks before publishing
- Preview the production build
- Keep secrets on the server
- Configure SPA history fallback
- Use HTTPS and a custom domain where appropriate
- Automate repeatable releases
- Verify the live site after every deployment
- Monitor failures and performance
- Keep a tested rollback path
Key takeaways
- Deployment makes a Vue application publicly accessible
- npm run build creates optimized production files
- A standard Vite build outputs to dist
- npm run preview verifies the generated build locally
- Static hosts can serve client-rendered Vue applications
- History-mode routes require an index.html fallback
- Subpath hosting requires a correct base path
- Browser environment variables are public and must not contain secrets
- Deployment includes testing, publishing, verification, monitoring, and recovery