Laravel Zero Docker Laravel Package

Product Decisions This Supports

• Choosing a distribution model for CLI products. When a roadmap item is an internal tool, ops CLI, migration runner, or scheduled-job binary built on Laravel Zero, this package closes the "last mile" from working app to shippable image: it generates a Dockerfile that compiles the app to a PHAR with Box and packages it into a runnable container. Containers win whenever the target host should not need PHP, Composer, or a matching extension set.
• Build vs. buy for packaging work. The realistic alternative is hours to a day of engineering time writing a multi-stage Dockerfile, wiring Box, and iterating on image size and runtime dependencies. Adopting this turns that into a scaffold-and-review task. With MIT licensing and a dev-only footprint, the decision is "adopt as a starting point," not "build from scratch."
• Roadmap sequencing and de-risking. It unblocks container-based delivery now, so feature work on the CLI is not gated behind packaging. It also de-risks adjacent roadmap items: running the CLI as a Kubernetes CronJob, baking it into a CI runner image, or shipping to customer-managed environments.
• Standardization across a CLI portfolio. If you have several Laravel Zero tools—or expect to—this becomes a candidate reference pattern for a house standard: same base image, same non-root user, same build stages across all CLI images. The package is the starting point; the internal template is the deliverable.
• Cost and effort estimation. It gives a PM a credible, low-cost estimate for packaging work: a short timeboxed pilot plus hardening, rather than an open-ended infrastructure project. That makes it easier to prioritize packaging alongside feature delivery.
• Exit clarity and reversibility. Because the output is a checked-in Dockerfile you own, this supports a "spike, then own the artifact" decision: evaluate in a timebox, keep the generated file, and drop the dependency. The adoption decision is cheap and reversible—which is itself the product argument.

When to Consider This Package

Consider it when:

• You are already on—or committing to—Laravel Zero for a console app and need container distribution.
• Your team has limited Docker/Box depth and wants a known-good multi-stage starting point rather than a blank file.
• You have a small number of images, no strict platform-engineering mandate, and are comfortable vendoring and owning the generated Dockerfile.
• You want the PHAR-then-image pattern (small runtime layer, no build toolchain in the final image) without re-deriving it.
• Your vendor policy tolerates a single-maintainer, low-adoption utility for a build-time concern.

Look elsewhere—or hand-roll—when:

• You need a maintained, CVE-patched runtime base image. This is a generator, not a supported image; patching remains your job.
• You need multi-arch builds, reproducible or digest-pinned images, SBOM and scanning wired into CI, or distroless/hardened runtimes—write the Dockerfile explicitly with Buildx and own it.
• Your app is full Laravel rather than Laravel Zero (use Sail or official PHP images), or you need non-Docker artifacts (Windows binaries, Homebrew, static binaries)—Box plus a CI matrix is the answer, not this.
• You require proven adoption and maintenance guarantees: 28 stars, zero dependents, and a single maintainer mean you should treat it as documentation with executable defaults, not a dependency. Assume PHP/Box version drift and budget a compatibility pass.
• You are not on Laravel Zero, or you need a Dockerfile only once for a throwaway service—copy the pattern from the repo and skip the dependency entirely.

How to Pitch It (Stakeholders)

For executives: This is a low-cost accelerator for a narrow, well-understood problem—turning a Laravel Zero CLI app into a container image. It costs nothing (MIT), carries no runtime risk because it is a dev-time code generator, and produces an artifact we own and can maintain independently. The exposure is maintenance maturity, not money or lock-in, and we can exit at any time by keeping the generated Dockerfile. Recommendation: fund a one-day timeboxed spike on our next CLI deliverable, measure the setup hours saved, and decide on standardization after that.

For engineering: It gives us the multi-stage Box → PHAR → slim runtime pattern as a scaffold instead of a from-scratch exercise. Treat the generated output as a reviewed template, not gospel: pin PHP and Box versions, verify non-root execution, trim the runtime layer, confirm entrypoint and signal handling for CronJob or queue-style usage, and add Buildx, image scanning, and tagging in CI. Plan for version drift—the package is single-maintainer with no dependents—but because the Dockerfile is checked in, drift is a maintenance task, not an outage. Rollout path: inventory Laravel Zero CLIs and Box usage, pilot the package as a dev dependency, generate and harden the Dockerfile, add CI build plus smoke test, image scan, and SBOM, then publish an internal template with pinned versions and a documented fork/fallback path. Because it is not a runtime dependency, rollback is straightforward: revert to the prior Dockerfile or fork the generator.