Laravel Preflight Checks Laravel Package

Product Decisions This Supports

• Release go/no-go gating as a product reliability lever. The package turns "is this environment actually ready?" from a tribal checklist into an enforced, repeatable gate with pass/fail output and exit codes. Wiring it into CI or a post-deploy step gives you a binary answer before traffic reaches a new environment. That directly reduces botched deploys, unplanned on-call escalations, and the roadmap slips those cause — a delivery-predictability play, not a developer-convenience play.
• Build vs. buy, resolved toward "buy the frame, build the checks." The realistic alternative is one to three days of bespoke Artisan commands or shell scripts wired into the pipeline, plus indefinite ownership and no shared vocabulary across teams. At this scope, adopt the framework and invest your effort encoding your own failure history as custom checks. The framework is commodity; your checks are the differentiator and the thing worth reviewing after every incident.
• Framework upgrade planning. 0.6.0 is a compatibility-only release adding Laravel 13 and PHP 8.5 support, with no stated API changes. If a Laravel 13 or PHP 8.5 move is on your 12–18 month roadmap, this is evidence the maintainer tracks upstream rather than pinning to older majors — so it won't become migration debt you have to strip out before you can upgrade.
• Environment parity and onboarding as a speed metric. A committed preflight suite is documentation that executes. Rebuilt staging, a second region, a client-hosted instance, and every new engineer get verified identically — shrinking the recurring, largely invisible tax of environment debugging on delivery speed.
• Named use cases to scope the pilot around: release readiness before a production cut, smoke checks immediately after provisioning, and a cheap sanity gate for teams running several small Laravel apps where per-app bespoke tooling never gets funded.
• Adoption framing: treat this as a pilot, not a standardisation mandate. The signal is thin — 3 stars, 0 dependents, pre-1.0, small-agency maintainer. The defensible position is "adopt narrowly on one service, prove value against a baseline, then decide."

When to Consider This Package

Adopt when:

• You run one or more Laravel apps with a pipeline you can hook into: a CI step, deploy script, container entrypoint, or post-provision hook.
• You have recurring configuration-drift incidents ("this env var exists everywhere but prod") and no standardised gate today.
• The team is small enough that dedicated release-verification tooling would never get funded, but large enough that a silent misconfiguration is expensive.
• You want checks versioned in the repo beside code, rather than living in a wiki or one person's memory.
• You're planning a Laravel or PHP bump and prefer dependencies already tracking upstream support.

Look elsewhere or wait when:

• Version stability is a hard requirement. This is 0.x — SemVer offers no backward-compatibility guarantee, and a minor bump can rename a check class or change a config key. Pin exactly and read changelogs. If your org requires 1.0+ for anything on the deploy path, this doesn't qualify yet.
• You want hosted, continuous monitoring with alerting and history. Uptime probes, scheduled health checks, and on-call routing are a different product category (Oh Dear, Forge/Envoyer health checks, your observability stack). This is a point-in-time check, not a monitoring service.
• Your failure modes are deeply domain-specific — billing-provider reachability, per-tenant data invariants, third-party SLA probes. Custom commands fit better; the framework earns little if none of your checks are generic.
• You need vendor support or near-zero maintenance. Single-maintainer, agency-backed, no SLA. Weigh bus factor for anything critical, and keep the integration non-blocking by default so a broken dependency can't halt a 2 a.m. hotfix.
• Your stack predates the supported matrix. Confirm which older Laravel/PHP versions 0.6.0 actually supports before assuming it drops in; a widened composer.json constraint without CI coverage is worse than an honest exclusion.

How to Pitch It (Stakeholders)

To executives: We deploy more often than our verification process has kept up with. This is a small, free, MIT-licensed open-source library that puts a standard pre-release check in front of every deploy — confirming the environment is genuinely configured before traffic reaches it. Integration is a few lines of pipeline configuration, not a project. Cost is effectively zero; the failure class it addresses (site down after a "routine" release) is expensive, embarrassing, and preventable. It already tracks Laravel 13 and PHP 8.5, so it won't become migration debt at our next upgrade. Recommendation: pilot on one service as a non-blocking advisory step, measure deploy-related incidents and rollbacks for a quarter against baseline, then decide on standardisation. Frame the ask as a one-quarter, one-service trial — not an org-wide commitment.

To engineering: It's a thin, opinionated way to codify the checks we already do by hand: install via Composer, get an Artisan command that runs an extensible set of check classes and returns clear pass/fail output plus non-zero exit codes, and wire it into CI. Three things to hold onto. First, it's 0.x — pin to 0.6.0 exactly, read every changelog, and assume roughly one genuinely breaking minor a year. Second, keep it off the critical path initially: advisory for one to two weeks, promote to blocking only after it demonstrates a true positive, and always keep a documented bypass for hotfixes. Third, prove every check fails on a deliberately broken environment before trusting it — a preflight suite that goes green on a broken environment is worse than no suite, because it manufactures false confidence. Author our domain-specific checks in a project-owned directory rather than editing vendor code, so the exit stays cheap if the package is abandoned; the framework is replaceable with an internal Artisan command at modest cost. 0.6.0 is compatibility-only and low-risk from 0.5.1. The real deliverable isn't the dependency — it's the team agreeing on what "ready to deploy" means and naming an owner for each check. Review the suite after every production incident and add a check for anything that could have caught it.