Laravel Starter Kit Laravel Package

Product Decisions This Supports

• Build vs. buy vs. scaffold. This is a Laravel starter kit, not a dependency you install and upgrade — it is a fork-and-own baseline. The decision it informs is "do we spend 2–4 engineer-weeks wiring auth, user/role management, admin scaffolding, and menus ourselves, or start from a maintained baseline and spend that budget on domain features?"
• Roadmap sequencing. Because the boilerplate is pre-built, the first milestone can be domain logic rather than platform plumbing. That typically pulls a "foundations" epic forward by a sprint or removes it entirely.
• Deployment target commitment. v1.7.2 is the release that makes the containerized production path credible: the prod Dockerfile now builds on laravoltdev/image:php8.5-prod (carrying the bcmath/exif extensions Laravolt actually requires) instead of the plain composer:2 image, which could not satisfy those runtime requirements. If your platform strategy assumes a deployable container image, this release is what lets you put that in a quarterly commitment instead of a spike.
• Environment parity / release engineering. Moving laravolt:link from an entrypoint hook to a build-time RUN (with AUTORUN_LARAVOLT_LINK=false) removes a class of "works locally, fails on deploy" incidents and makes image builds deterministic. That is a reliability decision, not just a Dockerfile tweak: it lowers the on-call surface for the first production deploy.
• Use-case fit. Strongest for back-office and internal-tool products — admin dashboards, RBAC-gated CRUD apps, multi-role internal portals, and MVPs where time-to-first-demo is the dominant constraint. Weakest for API-only/headless products, where most of the delivered value (Blade admin UI, menus, form builders) is dead weight.

When to Consider This Package

Adopt when:

• Your team is on a supported Laravel/PHP line and is comfortable owning forked scaffolding — you will not receive upstream upgrades as a composer dependency; you merge them by hand.
• The product's first 6–12 months are dominated by admin surfaces, roles/permissions, and CRUD, where the starter kit's opinions match your own.
• You are deploying containers and can pin the base image; v1.7.2 fixes the prod image's missing bcmath/exif, but PHP 8.5 in production is still a bleeding-edge choice — verify extension coverage and pin the tag rather than tracking latest.
• You need a demo or pilot in weeks, not quarters.

Look elsewhere when:

• You need a library with a support contract or upgrade path — this is scaffolding you own; the maintenance burden transfers to you the moment you fork.
• You are API-only, or your frontend strategy is Inertia/Livewire/SPA-first, which makes much of the shipped UI surface irrelevant.
• You are not containerized (shared hosting, Laravel Vapor/Serverless) — this release's substantive changes are Docker-only and deliver you nothing.
• You cannot tolerate a patch release that is exclusively build/packaging work: the fact that prod Docker builds needed correction in a patch suggests the container path is young. Validate it in a staging deploy before betting a launch date on it.
• You need vendor-backed security responsiveness; budget for your own dependency and upgrade cadence.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can either build our application's authentication, user and role management, and admin interface from scratch — several engineer-weeks of work that ships no customer-facing value — or start from a Laravel starter kit that already provides them, and spend that time on the features customers actually pay for. The trade-off is ownership: once we adopt it, the code is ours to maintain, so we should treat it as a one-time accelerator, not a supported vendor product. The latest release (v1.7.2) is a maintenance patch that repairs the production container build — it now uses a PHP image with the extensions the framework actually requires, and it moves a link-generation step into the build so deploys don't fail on an existing symlink. Net effect: the containerized deployment path is now usable, which is what we needed before committing a launch date to it.

For engineering (short): v1.7.2 is a patch with no API or feature changes — three items, all build/packaging: (1) prod Dockerfile vendor stage switched from composer:2 to laravoltdev/image:php8.5-prod to get bcmath/exif; (2) laravolt:link moved to a build-time RUN with AUTORUN_LARAVOLT_LINK=false, preventing the entrypoint hook from failing on an existing symlink; (3) Compose prod env aligned to the same flag. No breaking changes, no deprecations. Action: pin the new base image tag, rebuild and smoke-test the prod image in staging, and confirm our own extension requirements are covered before we treat PHP 8.5 as our production runtime. Since we forked, note this in our merge log — future upstream fixes to the Docker layer will need to be cherry-picked manually.