Docking Laravel Package

Getting Started

This package provides Docker images (FPM and Octane variants) for running Laravel applications in containerized environments. Start by pulling the latest image:

docker pull <vendor>/laravel-fpm:1.4.3
docker pull <vendor>/laravel-octane:1.4.3

First place to look is the docker-compose.yml / Dockerfile shipped in the repo — that defines the expected build arguments (PHP version, Node, extensions) and volume mounts for your Laravel app. Run a container against a sample app and confirm the boot sequence:

docker run -p 8000:8000 <vendor>/laravel-fpm:1.4.3
docker logs <container_id>

The first meaningful use case is running a standard Laravel app with SQLite or MySQL, hitting the app in the browser, and confirming logs stream to stdout (new in 1.4.3). For Octane users, verify the Octane worker boots under the updated laravel/octane dependency.

Implementation Patterns

Local dev via Docker Compose — override the base image in your compose file and mount your app source. Keep the base image read-only and let your app code live on a bind mount for hot reload. The FPM image typically pairs with Nginx; the Octane image can serve directly via Swoole/RoadRunner.

Octane in production — pin to the latest tag (:1.4.3 or :latest) since 1.4.3 bumps laravel/octane. Run Octane with --workers=N sized to CPU count, and consider a docker-compose sidecar pattern with Nginx in front. Watch for Octane’s in-memory state — no reliance on $_ENV mutations across requests.

Logging integration — since 1.4.3, both images pipe application logs to stdout/stderr. In production, forward container logs to your aggregator (Loki, Datadog, CloudWatch) — do not rely on files inside the container. Typical pattern:

logging:
  driver: "json-file"
  options: { max-size: "10m", max-file: "3" }

SQLite workflows — the container now prints its UID/GID on boot. Use this to align host permissions on your SQLite file before the app tries to write:

docker run <vendor>/laravel-fpm:1.4.3  # note printed UID:GID
sudo chown 1000:1000 ./database/database.sqlite

CI integration — use the FPM image as a PHP runner for test suites (docker run --rm -v $PWD:/app <image> php artisan test). The stdout log streaming simplifies capturing failures in CI job output.

Gotchas and Tips

Octane version drift — the 1.4.3 bump to latest laravel/octane means you should re-run your Octane smoke tests. Config cached from older Octane versions can silently be ignored; always php artisan octane:reload (or restart the container) after deploys.

SQLite UID/GID on mounted volumes — bind-mounted files retain host ownership. The printed UID/GID is what the container’s www-data (or app user) runs as — chown accordingly, or your SQLite file will appear writable but fail on WAL mode switches.

Logs go to stdout, not storage/logs — if you have tooling that tails storage/logs/laravel.log, it will now be a symlink to /dev/stderr (or empty). Update file-based log shippers accordingly.

Docker log driver backpressure — high-traffic Octane apps can flood docker logs and bloat the JSON log file. Set max-size/max-file in your compose logging config; otherwise disk fills silently.

Extension points — build a child image (FROM <vendor>/laravel-fpm:1.4.3) to add packages via docker-php-ext-install rather than mutating the base image at runtime. For Octane tuning, override octane:start arguments in your entrypoint or config.

Debugging startup failures — since logs stream to stdout only after the app boots, crashes before Laravel initializes still surface via docker logs (container runtime output), so always check docker logs <id> before assuming the image is broken.

Tag pinning — pin to :1.4.3 in production; :latest will silently move when Octane versions bump, and Octane’s wire protocol can shift between minor versions.