- What does owenvoke/laravel-zero-docker actually do?
- It is a Laravel Zero command that generates a Dockerfile for your Laravel Zero application, targeting the Box PHAR build workflow. The output is a plain, checked-in Dockerfile and optional docker-compose scaffolding that you own from the moment it is generated. It is a scaffolding accelerator rather than a runtime dependency, so nothing from the package ships inside your production image.
- How do I install laravel-zero-docker in a Laravel Zero project?
- Install it as a dev dependency with composer require --dev owenvoke/laravel-zero-docker. It exposes a generator command that emits the Dockerfile into your project, typically on a feature branch so you can review the diff before committing. Because it is require-dev only, it never reaches the built image.
- Do I need Box to use this package?
- Yes. The generated container setup assumes your Laravel Zero CLI compiles to a PHAR with Box, and the build stage expects that PHAR as the runtime artifact. If your project does not use Box, this package is the wrong fit and you should hand-roll the image instead.
- Can I use this with a full Laravel web application or a non-Zero PHP CLI?
- No. It is designed for exactly one application shape: a Laravel Zero CLI that compiles to a PHAR with Box and needs a container image for distribution, CronJob execution, or embedding in a CI runner image. For full Laravel web apps, Laravel Sail or the official PHP images are the right starting point.
- Does the generated Dockerfile use multi-stage builds and a non-root user?
- The template follows the multi-stage Box to PHAR to slim runtime pattern, but you should verify the details in the generated file rather than assume them. Check for a non-root USER directive, pinned base images, and the correct COPY --from=builder path for your PHAR output. Treat hardening the generated file as part of the task, not something the generator finishes for you.
- Will the generator command overwrite my existing Dockerfile?
- The command writes a Dockerfile into your project, so check the available --force and --path style options before running it against an existing setup. The safest approach is to run it on a branch and diff the output against whatever you currently ship. Because the artifact is a single build-time file, any accidental overwrite is trivially revertable in version control.
- Can I remove the package after generating the Dockerfile?
- Yes. The architectural coupling is intentionally shallow: the command emits a plain Dockerfile and compose scaffolding that you own from that point on. After generation you can drop the dev dependency without touching anything that runs in production. This also makes a fork-and-own fallback cheap if upstream maintenance stalls.
- How do I customize the Dockerfile for Alpine, extra PHP extensions, or private Composer credentials?
- Customization happens on the generated artifact rather than through runtime configuration, either by editing the Dockerfile directly or by overriding the package stub if you want repeatable generation. Add extensions in the relevant build stage, switch base images deliberately, and inject Composer auth through build secrets or CI credentials rather than baking tokens into layers. Many teams normalize the first hardened output into an internal template and stop regenerating.
- Does it support multi-arch builds and pinned base image digests?
- The template can carry single-arch assumptions, so plan to review base image references and add digest pinning plus buildx support yourself. These are reviewed-and-owned risks rather than surprises, because they are visible in the generated Dockerfile immediately. Before standardizing, validate your Laravel Zero, PHP, and Box version matrix and confirm both build stages have the extensions your app needs.
- Is laravel-zero-docker actively maintained, and is it safe to depend on in production?
- The package has thin field validation, with roughly twenty-eight stars and almost no dependents, and it is maintained by a single author. Runtime risk is essentially zero since it is dev-only tooling, so the real concerns are supply chain and maintenance maturity, both mitigated by the permissive MIT license that makes forking cheap. Pin the version, review the generated file, and assume a fork-and-own fallback rather than relying on long-term upstream support.