Laravel Starter Kit Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel starter kit rather than a drop-in Composer package: adoption means scaffolding a new service from the template or cherry-picking its conventions, not running composer require inside an existing app. It fits teams standardizing greenfield Laravel services on a batteries-included baseline (auth, RBAC, menus, media, generators) deployed as containers. v1.7.2 is a patch release confined to the production container path, which confirms Docker/Compose as the supported production deployment model.

Integration feasibility. High for greenfield services already on Docker. The release removes a real blocker: the prior vendor stage used composer:2, which lacks bcmath and exif, both required by Laravolt — production images built from earlier versions would fail at runtime. v1.7.2 pins that stage to laravoltdev/image:php8.5-prod, which ships the required extensions. There are no application-code changes, so upgrading is a Dockerfile and docker-compose.prod.yml sync, followed by an image rebuild.

Technical risk. Low to moderate, concentrated in operations rather than application code.

• PHP 8.5 runtime. The prod image is now explicitly 8.5-based. Verify the Laravel framework constraint and every third-party dependency against 8.5, and confirm the hosting platform, CI runners, and any PHP extension builds support it. If 8.3/8.4 variants are not published, teams on older runtimes cannot consume this fix.
• Build-time symlink semantics. Moving laravolt:link into a build RUN changes behavior from runtime to image-build time. If storage is a volume mount, or the root filesystem is read-only, or a CI layer cache is stale, the public/storage link may be missing or incorrect despite a successful build.
• New configuration surface. AUTORUN_LARAVOLT_LINK=false is now required knowledge. Any environment that omits it, or overrides the compose file with true/unset, will hit the entrypoint failure this release is fixing — a container-won't-start outage during rolling deploys.
• Base-image supply chain. Reliability and CVE patching now depend on laravoltdev/image being maintained. Pin by digest where possible.
• Scope. The fixes are Docker-only; non-container consumers gain nothing from this patch.

Key questions. Which Laravel and PHP versions are officially supported — is 8.5 mandatory or merely the default? Is laravoltdev/image published with a security-patch cadence and multiple PHP tags? What is the intended behavior when public/storage is a volume mount? Is there an upgrade guide from v1.7.1, and does the project treat Dockerfile changes as acceptable in patch releases going forward? What is the backport/support window?

Integration Approach

Stack fit. Laravel with a Blade/Livewire-style UI, Docker Compose for local and prod, PHP 8.5 in the production image. Strong fit for containerized teams; poor fit for shared hosting, non-Docker deployments, or organizations pinned to PHP 8.2/8.3.

Migration path. Treat this as template adoption, not a package upgrade. For greenfield work, scaffold directly from the v1.7.2 tag and inherit the corrected Dockerfile and Compose file. For existing v1.7.1 users, diff Dockerfile and docker-compose.prod.yml against v1.7.2 and apply the three changes, then rebuild to confirm bcmath/exif are present and the storage symlink exists in the image layer.

Compatibility. Validate the Laravel framework constraint, all third-party packages, and any additional extensions the app needs (intl, gd, redis, pdo_mysql/pdo_pgsql) against the new base image. Confirm the deployment platform accepts the image architecture and does not impose its own entrypoint assumptions.

Sequencing. (1) Pin to the v1.7.2 tag; (2) reproduce the build in CI and run smoke tests; (3) assert extensions and symlink presence in the built image; (4) deploy to staging using the prod Compose file; (5) inspect entrypoint logs and verify public/storage; (6) promote to production with a v1.7.1-derived rollback image tagged and ready.

Operational Impact

Maintenance. Application-code maintenance stays low, but the upgrade discipline changes: Dockerfile edits now arrive in patch releases, so every x.y.z bump needs a lightweight review rather than an auto-bump. The laravoltdev/image tag becomes a dependency to track for PHP and CVE updates.

Support. Community/OSS with no commercial SLA. Internal ownership is required for base-image patching and PHP version transitions, plus a contingency plan if image publishing stops.

Scaling. The app scales as a stateless Laravel container. The build-time symlink is a fixed image layer and does not affect horizontal scaling. Build duration increases modestly versus composer:2 because the base image is larger — this affects CI throughput more than runtime.

Failure modes. (a) Runtime fatals if anyone reverts to composer:2 or another image missing bcmath/exif; (b) container start failure on redeploy when AUTORUN_LARAVOLT_LINK is unset or true and the symlink already exists — the highest-severity mode here; (c) broken asset serving if a storage volume mount invalidates the build-time link; (d) opaque dependency errors from PHP 8.5 incompatibility; (e) drift when the Dockerfile is updated but the Compose file is not, or vice versa.

Ramp-up. Low for engineers familiar with Laravel and Docker; the starter kit's conventions (menus, RBAC, generators) take a few days. Add roughly half a day for the production Docker path and the new autorun flag, and record both the flag and the base-image upgrade procedure in the runbook.