Introduction
In the previous article, I showed how to build a production-ready Docker image for Laravel & Filament.
But in real-world applications, a single container is never enough.
Running a production application means dealing with multiple concerns:
- web server
- PHP runtime
- database
- cache
- background workers
- scheduled jobs
And this is where things usually start to get messy.
The problem with "simple" setups
Most Docker Compose examples look like this:
- one container
- maybe a database
- everything else mixed together
It works.
Until it doesn’t.
From my experience, this approach quickly leads to:
- poor observability
- difficult debugging
- no real scaling strategy
- fragile deployments
A simple rule I follow
Over time, I ended up following one principle:
👉 one container = one responsibility
It sounds simple, but it completely changes how you design your architecture.
A production-oriented architecture
Instead of one container doing everything, I split responsibilities:
-
app→ PHP-FPM runtime -
web→ reverse proxy (Nginx) -
db→ PostgreSQL -
redis→ cache & queues -
horizon→ queue workers -
scheduler→ scheduled jobs
Each service is isolated.
Each service can scale independently.
Each service can fail independently.
👉 This is what makes the system predictable.
A common trap: the "public volume"
One mistake I’ve seen (and made) multiple times is how static assets are handled.
A typical setup uses:
public:/var/www/app/public
Looks fine.
But in practice:
- old assets can persist between deployments
- new builds may not be reflected
- deployments become inconsistent
👉 This kind of issue is subtle… and painful in production.
Another key point: bootstrap vs runtime
In many setups, migrations and initialization tasks run inside the main container.
I prefer separating concerns:
- runtime containers → long-running processes
- bootstrap → one-time tasks (migrations, setup)
👉 In real production systems, this is often handled in CI/CD pipelines instead.
Why this matters
This kind of architecture gives you:
- better isolation
- clearer debugging
- safer deployments
- real scalability
It’s not the simplest setup.
But it’s much closer to what you actually need in production.
Going further
In this article, I intentionally kept things focused on concepts and architecture.
👉 I cover the full Docker Compose setup (with real configuration, volumes, healthchecks, and production patterns)
https://filamentmastery.com/articles/production-ready-docker-compose-for-laravel-filament/
Series
This article is part of a series on production-ready Laravel & Filament setups:
- Docker image (multi-stage build)
- Docker Compose architecture
- CI/CD pipelines
- deployment strategies
I’ll be covering each part progressively.
If you’ve already built similar setups, I’d be curious to hear how you structure your containers in production.
