jordanpartridge/conduit-docker
Conduit Docker brings simple Docker orchestration to Laravel apps, with ready-made containers and configuration to spin up local and production environments fast, without hand-writing compose files or wiring PHP, database, and queue services yourself.
The v2.2.0 release is a tuning release, not a feature release: build timeout is now 900s and container startup timeout is now 300s, specifically so PHP extension compilation has room to finish inside the image build. That tells you what this package is for — it wraps the build-and-run lifecycle of a Laravel app in Docker, and the two knobs you will actually touch day-to-day are how long the build may take and how long the container may take to become healthy.
Start here:
php artisan vendor:publish or the config file shipped in config/) and locate the build timeout and startup timeout values. Confirm they read 900 and 300 after upgrading — if you have a previously published config, package defaults will not apply to you (see Gotchas).intl, gd, imagick, pcntl, swoole, redis) and deploy it end-to-end. That is precisely the scenario this release claims to unblock — it is the shortest path to validating the upgrade.If your app has no compiled extensions and builds in under two minutes, this release changes nothing for you operationally; upgrade for consistency, not for capability.
Keep extensions in the builder stage. The single most effective pattern with a 15-minute build budget is a multi-stage Dockerfile where build-essential, php-dev, and pecl live only in the builder stage, and the runtime stage copies the compiled .so files plus enabled ini stubs. You get the compile-time headroom without shipping a toolchain and without inflating the runtime image (and its startup time — which is now capped at 300s, not unbounded).
Treat the timeouts as budgets, not targets. A build that lands at 12 minutes is a build that will land at 16 minutes the day someone adds a dependency. Use the new headroom to measure your real build time, then add caching until you are comfortably inside it.
CI/CD wiring. The package timeout is only one of several stacked limits. When you deploy from CI, verify the enclosing job/step timeout is greater than the package build timeout, or you will get a CI-level cancellation that looks identical to a package timeout in the logs. Mirror the same reasoning for container orchestration: if your platform's readiness probe or rollout deadline is shorter than 300s, the platform kills the container before the package's own startup wait expires.
Long-running processes. If you run queue workers, Horizon, or a scheduler alongside the web container, those containers also get the startup window. Anything that boots slowly (warm-up caches, connecting to a slow broker) now has more room, but also now fails later and less visibly — make sure your process manager logs startup progress.
Rolling deploys. A 300s startup allowance means a rolling update can legitimately take several minutes per replica. Size maxSurge/maxUnavailable and your deploy step's own timeout accordingly, otherwise the orchestrator reports failure while the package is still patiently waiting.
Published configs shadow new defaults. The most likely reason this release "doesn't work" for you: you published the config in an earlier version, so your file still carries the old timeout values. Diff your published config against the package's shipped config after every upgrade, and consider omitting keys you don't intend to override so package defaults flow through.
A timeout fix is a symptom, not a cure. If a 15-minute build is what makes your deploy succeed, your build is almost certainly recompiling extensions on every run. Check layer ordering (copy composer.json/composer.lock and install before copying source), enable BuildKit cache mounts for the package manager and compiler cache, and consider a prebuilt base image that already carries your extensions. Extensions that never change should be compiled once, not per deploy.
OOM masquerades as a timeout. PHP extension compilation is memory-hungry. A container memory cap or a CI runner with limited RAM will produce a build that hangs and then dies at the timeout boundary, and the log tail will show nothing useful. If raising the timeout changed nothing, check memory before you touch the clock again.
Startup timeouts hide readiness bugs. A 300s window will happily absorb a container that is technically up but not actually serving — migrations retrying, cache warming, a hung queue connection. Instrument the startup path so a slow boot is visible rather than merely tolerated.
Debugging truncation. When a build is killed at the timeout, the interesting output is often the last few lines. Capture build logs to a file or artifact rather than relying on streamed console output, and run the same build locally with the package's timeout values so the failure reproduces outside CI.
Extension points to prefer. Rather than raising timeouts monotonically every time a build gets slower, lean on the package's hooks for custom build steps and health/readiness checks. Custom build steps let you do expensive one-time work explicitly; readiness checks let you distinguish "still compiling" from "actually broken" without widening the global startup window.
How can I help you explore Laravel packages today?