Weave Code
Laravel Preflight Checks Laravel Package
kirschbaum-development/laravel-preflight-checks
Run preflight checks in Laravel before deploys or critical operations. Define custom checks to validate config, environment, and dependencies, then get clear pass/fail results so problems surface early instead of in production.
Preflight Checklist before deployment or development
Frequently asked questions about Laravel Preflight Checks
- How do I install laravel-preflight-checks in a Laravel application?
- Install it with Composer using kirschbaum-development/laravel-preflight-checks; the service provider is auto-discovered, so no manual registration is needed. There is no sidecar, hosted service, or external account involved, which keeps the install reversible by removing the Composer requirement. After installing, publish the package config and define the check set you want to run. Before adopting, review the transitive dependency footprint against your licence and security policy.
- What checks does laravel-preflight-checks run by default?
- The package is built around discrete check classes covering environment and dependency basics such as PHP version, required extensions, .env keys, database, cache and queue connectivity, and storage writability. Because checks are individual classes, you can select the subset that matches your application instead of running everything. Confirm the exact default set against the version you install, since 0.x minors can change behaviour.
- How do I write a custom preflight check in Laravel?
- Add a check class that validates one condition and returns a pass or fail result, then register it in your preflight set alongside the built-in checks. Keep each check narrowly scoped to a single failure mode with a clear message, so a red result points directly at one fix. The custom checks that encode your own incident history are the real asset here, not the commodity defaults.
- Does laravel-preflight-checks support Laravel 13 and PHP 8.5?
- Version 0.6.0 widens support to Laravel 13 and PHP 8.5, and the 0.5.1 to 0.6.0 delta is compatibility-only with no feature or deprecation entries. Verify the CI matrix actually runs green on those targets rather than trusting a widened composer.json constraint that resolves but fails at runtime. Pin a version you have tested against your own stack and re-run the suite after every upgrade.
- Can I run preflight checks non-interactively in CI/CD with meaningful exit codes?
- Confirm this before wiring the package into a pipeline: the Artisan entrypoint must run unattended and exit non-zero when a check fails, otherwise it cannot gate a build. Test it against a deliberately broken environment and assert the process exit code, not just the printed output. If exit codes are not dependable in your installed version, keep the suite as a reporting step or wrap the command in a script that enforces failure.
- How do I configure which preflight checks run before a deployment?
- Publish the package config and declare the check set to execute for each context, whether local, CI, or a container entrypoint. The same check definition runs identically in all three, so one definition serves development and delivery. Treat that config as code and review changes to it like any other deploy control.
- What does the output look like, and can I capture it in a pipeline log?
- The Artisan entrypoint reports clear pass/fail results per check, which is what makes a failure actionable rather than just noisy. Capture the output in your CI logs so a red result can be traced to a specific check and owner. Check whether your installed version offers machine-readable output before assuming you can parse it; where an exit code will do, prefer that over parsing human-readable text.
- Is laravel-preflight-checks stable enough for production use at version 0.6.0?
- It is at 0.6.0 with very few stars and no dependents, so there is little external validation and SemVer gives no backward-compatibility guarantee across minors. A 0.7.0 release could rename check classes or config keys, so pin the version and read the changelog before upgrading. The technical risk is low and the coupling is minimal, but treat it as process tooling with a named owner rather than a platform bet.
- How do I test that my preflight checks actually fail on a broken environment?
- Run the suite against a known-good staging environment first and record the real output. Then break something on purpose, such as a missing .env key, a storage permission, or a database connection, and confirm the relevant check goes red. That second observation is the acceptance test, and a check that goes green on a broken environment is worse than having no gate at all.
- What are the alternatives to laravel-preflight-checks for deployment validation?
- Alternatives include bespoke Artisan commands, CI-only shell scripts, and general health-check or smoke-test tooling; the differentiator here is a reusable check API wired into Laravel's Artisan entrypoint. Before adopting anything, ask which of your historical incidents the suite would have caught, since that decides whether it earns its place. Also agree a fallback for the next Laravel major in case the package is effectively single-maintainer.
Weaver
How can I help you explore Laravel packages today?