Managing Assets in Production: A Laravel Vite Guide

Learn how to use Vite to compile your frontend assets for production. Master the build process and ensure your Laravel app serves optimized, linked assets.

LaravelViteDeploymentAssetsFrontendphpbackend

Previously in this course, we covered Environment Security Best Practices. Now that your server is hardened, we need to address how your browser sees your application. You’ve been using npm run dev to see your styles and scripts, but that command is strictly for local development—it won't work in a production environment.

Understanding Vite: Development vs. Production

Vite is a modern build tool that serves your assets via a local development server during development. When you run npm run dev, Vite watches your files and injects changes into your browser instantly. This is great for developer experience, but it’s not how you ship code to a real server.

In production, you don't want a Node.js process running to serve your JavaScript and CSS. Instead, you want "compiled" or "built" assets. This means Vite takes your source files (like resources/css/app.css and resources/js/app.js), minifies them, removes unused code, and bundles them into static files inside your public/build directory.

Compiling Assets for Production

To get your app ready for the world, you need to run the production build command. This process generates the optimized files that web servers like Nginx or Apache can serve directly.

Open your terminal in your project root and run:


Bash
npm run build

When this command finishes, look at your project directory. You will see a new folder at public/build. Inside, you’ll find versioned files (e.g., app-B4xY7z.js). The versioning—often called "cache busting"—ensures that when you update your code, users' browsers don't hold onto old, cached versions of your site's styles or scripts.

Linking Assets Correctly in Blade

In your Blade layouts, you’ve likely been using the @vite directive. This directive is smart: when you are in a local environment, it points to the Vite development server. When you run npm run build, Laravel automatically detects the manifest file in your public/build directory and swaps those links to point to the production-ready static files.

Ensure your resources/views/layouts/app.blade.php (or your master layout) includes the directive in the <head> section:


BLADE
<!DOCTYPE html>
<html>
<head>
    @vite(['resources/css/app.css', 'resources/js/app.js'])
</head>
<body>
    ...
</body>
</html>

You don't need to change anything when moving to production. As long as you run npm run build during your deployment process—as discussed in Deployment Basics: From Local Vite App to Production—Laravel handles the asset resolution for you.

Hands-on Exercise

Run npm run build in your terminal.
Check your public/build folder to confirm the generated files exist.
Open your .env file and verify that APP_ENV is set to production.
Refresh your browser; you should see that your styles are still loading, but they are now being served from the public/build directory rather than the dev server.

Common Pitfalls

Forgetting to build: The most common mistake is pushing code to a production server without running npm run build. Your styles will simply fail to load because the production server doesn't have the Vite dev server running.
Committing build files: You should generally exclude the public/build directory from your Git repository via your .gitignore file. These files are generated artifacts, not source code.
Incorrect Permissions: Ensure your web server user (like www-data) has read permissions for the public/build directory, or your users will receive 403 or 404 errors when trying to load your site's CSS.

Recap

We’ve transitioned from the "hot-reloading" world of local development to the static, optimized world of production. By using npm run build, we create high-performance assets, and by utilizing the @vite directive, we let Laravel handle the heavy lifting of linking those files correctly. This ensures your Task Manager app is as fast as it is functional.

Up next: Task Manager: Deployment Preparation