Weave Code
Docker Nginx Php Laravel Laravel Package
systemsdk/docker-nginx-php-laravel
A ready-to-use Docker environment for Laravel development, bundling Nginx, PHP-FPM, MySQL, Redis, and common tooling. Spin up isolated, reproducible stacks with configurable PHP versions and simple Docker Compose commands for local development and CI.
Docker environment required to run Laravel (based on official php and mysql docker hub repositories)
Frequently asked questions about Docker Nginx Php Laravel
- Do I install systemsdk/docker-nginx-php-laravel with Composer?
- No. Despite the vendor/package style name, this is a Docker Compose reference environment distributed as a GitHub repository, not a Composer library. Nothing is added to your application's dependency graph and there is no service provider, facade, or config publish step. You adopt it by cloning, forking, or adding it as a submodule and placing your Laravel codebase in the app directory. That means your team takes ownership of a small infrastructure codebase rather than consuming a versioned, upgradable artifact.
- What do I need installed to run this Laravel Docker environment?
- You need Docker Engine or Docker Desktop with Compose v2 on every developer machine and on your CI runners. The stack is started with standard docker compose commands rather than an installer, so there is no PHP, Nginx, or MySQL requirement on the host. On CI you will typically use Docker-in-Docker or a socket-mounted daemon. Because the Laravel app lives inside the project structure, expect to reconcile UID/GID mapping for bind mounts so file permissions stay sane on Linux hosts.
- Which services are included in the Laravel Docker stack?
- The bundle ships Nginx, PHP-FPM, MySQL, Redis, and MailHog, plus Xdebug and supervisor-managed queue and cron workers. That combination gives you a production-shaped local stack instead of relying on artisan serve and a local MySQL install. MailHog catches outgoing mail and the worker containers mean queued jobs and scheduled tasks run the same way they would on a server. Everything is wired together with Docker Compose so the whole environment comes up with a single command.
- Can I choose which PHP version the environment uses?
- Yes, configurable PHP versions are one of the main reasons teams pick this over simpler local stacks. You can point the PHP-FPM image at a specific PHP minor to match production, which matters when your application depends on version-specific behaviour or extensions. The exact supported PHP and Laravel matrix should be verified against the repository before standardising, and you should confirm how quickly new PHP minors are added upstream. Pin the version explicitly rather than letting it float so developer environments do not drift apart.
- How does this compare to Laravel Sail for local development?
- Sail is the first-party option and is tightly integrated with Laravel's own tooling, so it wins on familiarity and default support. This project differentiates itself with multi-PHP-version support, MailHog for mail capture, and supervisor-managed queue and cron workers out of the box. If your team already standardises on Sail, running a second local-stack standard is a real recurring cost and you should confirm you actually need those extras. Choose third-party only when the specific features solve a problem you have today.
- Is this Docker environment suitable for production deployment?
- No. The scope is local development and CI, and the Compose setup is single-host with no orchestration, scaling, or secrets management story. Treating it as production infrastructure is scope creep that the project does not claim to support. State that boundary explicitly in your internal docs so nobody proposes it for a real deployment. Production-like is a claim rather than a guarantee, since php.ini, opcache, worker topology, and database minor versions will differ from your servers.
- How much work is it to adopt this stack in an existing Laravel application?
- The work is reconciliation rather than installation, so budget one to three engineer-days for a pilot plus CI wiring. You will need to align the exact PHP minor and extension set such as intl, bcmath, gd or imagick, pdo_mysql, and zip, plus MySQL major version against production and the Node asset-build toolchain. Assume five or more days if the app carries anything unusual like Oracle or SQL Server drivers, Imagick, FFmpeg, or Octane. Host architecture also matters for any image that is not published multi-arch.
- How do I keep my fork in sync with upstream changes?
- Adoption is a copy, fork, or submodule, so every upstream pull is a merge rather than a version bump. That means your fork accrues local commits and drift over time unless you have a documented rebase ritual. Without that ritual the fork typically decays within a couple of quarters. Also decide whether base image tags are pinned, in which case someone owns a bump cadence for CVE remediation, or floating, in which case dev environments silently drift.
- Does it work on Apple Silicon and other arm64 machines?
- It depends on whether the base images you configure are published as multi-arch. If an image is amd64-only, Docker will fall back to emulation, which is slow, or fail outright on arm64 hosts. Check the nginx, php-fpm, and mysql tags you pin before rolling the stack out to a mixed-hardware team. If multi-arch images are not available, plan to build them yourself and publish to your own registry.
- Does this setup support Laravel Octane, Swoole, or RoadRunner?
- It is built around Nginx plus PHP-FPM, so Octane, Swoole, and RoadRunner are not part of the default stack. Running Octane means adding a persistent application server container and rewriting the Nginx upstream configuration, which is real custom work. Because the project is a reference environment you fork, that customisation is yours to maintain across upstream merges. If Octane is on your roadmap, evaluate whether a platform team's container baseline or Sail is a better starting point.
Weaver
How can I help you explore Laravel packages today?