Introduction Most Docker setups for Laravel applications are… fine. They work locally, they run php artisan serve, and that’s about it. But when you start building real-world Laravel & Filament applications used in production, those setups quickly become a liability: slow builds bloated images security issues poor separation between development and production I’ve personally run into these issues multiple times before refining this setup. 👉 This article focuses on the core ideas and architecture. Filament Mastery. In this article, I’ll walk through the key concepts behind a Docker setup I use in production for Laravel & Filament projects. This includes: multi-stage builds optimized dependency installation frontend asset compilation non-root execution for better security environment-specific configuration (dev vs production) A typical Dockerfile often looks like this: FROM php:8.4-fpm COPY . . RUN composer install RUN npm install Simple… but problematic. Main issues: installs dev dependencies in production no asset compilation strategy runs as root large and slow images no separation of concerns 👉 This is fine for learning, but not for production. Instead of a single container doing everything, I rely on multi-stage builds and clear separation of responsibilities. Typical structure: a Composer stage to install PHP dependencies a Node stage to build frontend assets a final PHP-FPM image focused only on runtime 👉 The goal is simple: keep the runtime image as small, secure and predictable as possible. One of the biggest improvements comes from moving as much work as possible to build time. In my experience, this means: installing dependencies during build (not at runtime) compiling assets once shipping only the final artifacts 👉 The container becomes immutable and easier to reason about. Instead of a single-stage Dockerfile, the idea is to split concerns: # Composer stage (dependencies) RUN composer install --no-dev # Node stage (assets) RUN npm ci && npm run build # Final image COPY built assets + vendor only 👉 This is intentionally simplified, but it reflects the core idea. With this approach: builds are faster thanks to caching images are significantly smaller attack surface is reduced development and production concerns are clearly separated In production environments, these differences quickly become critical. This article only covers the Docker image itself. In a real production setup, you also need: a proper Docker Compose architecture a CI/CD pipeline to build and validate images deployment strategies 👉 I’m progressively documenting this production setup (Docker, Compose, CI/CD and more) here: https://filamentmastery.com/articles/production-ready-docker-setup-for-laravel-filament/ Docker setups are often underestimated in Laravel projects. But in my experience, investing in a clean, production-ready setup early saves a lot of time later, especially when your application starts scaling.