Conduit Docker Laravel Package

Product Decisions This Supports

• Build vs. buy on deployment tooling. This package owns end-to-end Laravel Docker deployment — image build through container startup, including PHP extension compilation. That is work a platform team would otherwise hand-roll in CI pipelines and per-repo Dockerfiles. Adoption is a "buy" decision that removes recurring maintenance, not a one-off script.
• Roadmap sequencing around deployment latency. The v2.2.0 change sets the practical envelope: up to 15 minutes (900s) for build and 5 minutes (300s) for container startup. Treat ~20 minutes as the cold-path worst case when planning anything that depends on deploy speed — per-PR preview environments, hotfix-to-production turnaround, or demo/sandbox provisioning.
• Feature scoping on PHP extensions. The timeouts were raised specifically to let extension compilation complete. This tells you the package is viable for apps with non-default extensions (image processing, intl, custom PECL builds) — a common blocker for simpler deploy tooling. If your roadmap includes such dependencies, this is a differentiator; if not, you are paying a latency tax for capability you don't use.
• CI cost and runner sizing. A 15-minute build ceiling is a budgeting input: runner minutes per deploy, concurrency limits, and whether builds need a larger instance class. Worth modeling before committing to deploy frequency targets.
• Consolidation play. If multiple Laravel services deploy via divergent bespoke pipelines, a single package-defined path is a standardization decision that reduces incident surface and onboarding time.

When to Consider This Package

Consider it when:

• The team has no dedicated platform/DevOps owner and needs repeatable Docker-based Laravel deploys without building a pipeline from scratch.
• The application requires compiled PHP extensions that managed or PaaS-style hosts won't accommodate.
• Deploy frequency is modest (per-merge or per-release, not per-commit) and a multi-minute build is tolerable.
• You want one deployment contract across several Laravel services.

Look elsewhere when:

• Deploy latency is a product requirement — sub-minute iteration, ephemeral per-PR environments, or rapid rollback loops.
• A managed platform already covers your needs (Forge, Vapor, Laravel Cloud, or a container platform with a Laravel buildpack). Buying this package on top duplicates a solved problem.
• Your workloads are serverless, static, or non-container by design.

Watch for:

• The new 900s/300s values are a ceiling, not a target. If real builds approach them, that signals a caching gap rather than a need for a larger timeout — a second bump would be a warning sign, not a fix. Ask for build-time telemetry (p50/p95) before and after this release.
• This release is a configuration change, not a feature. Confirm it actually produces end-to-end success on your workload before treating the deployment story as validated — "should enable" is not "does enable."

How to Pitch It (Stakeholders)

To executives: This package gives us a standardized, maintained path for shipping Laravel applications as Docker containers, including the PHP extension compilation that usually forces custom engineering. The tradeoff is time: a full deploy can take up to roughly 20 minutes in the worst case. That is acceptable for release-cadence deployments and not acceptable for rapid-iteration workflows, so the decision hinges on which of those we need. It replaces bespoke pipeline maintenance with a dependency we track and upgrade.

To engineering: v2.2.0 raises the build timeout to 900s and container startup to 300s to let extension compilation finish, which is intended to make end-to-end deploys succeed. Two asks: (1) instrument build and startup durations so we know our real p50/p95 against those ceilings — if we are close to 900s, we have a caching problem to fix, not a timeout to raise; (2) verify the end-to-end path on our own application before we remove any existing fallback pipeline. This is an incremental reliability fix with no breaking changes, so it is low-risk to adopt, but it does not by itself prove the deployment path works for us.