Weave Code
Laravel Self Diagnosis Laravel Package
beyondcode/laravel-self-diagnosis
Run a series of checks to verify your server meets Laravel's requirements. This package provides an artisan command and web interface to diagnose PHP version, extensions, folder permissions, and other environment issues before deployment. Catch problems early and ship with confidence.
Perform various self diagnosis tests on your Laravel application.
Frequently asked questions about Laravel Self Diagnosis
- What is beyondcode/laravel-self-diagnosis used for?
- It is a pre-flight readiness utility that runs a configurable list of pass/fail checks against your Laravel environment, such as PHP version, required extensions, writable paths, .env presence, app key and database connectivity. You get an Artisan command and, by default, a web route that renders the results. It is meant to catch environment problems before deployment, not to act as monitoring or a health endpoint with an SLA. It adds no migrations, persistence, or request-path behavior.
- How do I install laravel-self-diagnosis?
- Install it with Composer using composer require beyondcode/laravel-self-diagnosis. The service provider is auto-discovered, so no manual registration is normally needed. Publish the config file with the package's vendor:publish tag so you can choose which checks run and how the route is exposed. Setup is typically an afternoon task rather than a sprint.
- How do I run the Laravel self-diagnosis checks?
- Run the package's Artisan command to execute every configured check and print the results in your terminal. If the web route is enabled, you can also load it in a browser to see the same pass/fail output. A common pattern is to wire the command into a post-deploy smoke step so a failing environment blocks the release.
- Does laravel-self-diagnosis support Laravel 13?
- Version 3.1.0 extends the tested compatibility matrix through Laravel 13.x. Because that release arrived as an automated compatibility pull request, verify that composer.json actually widens the illuminate/* and laravel/framework constraints to admit ^13.0 rather than only adding a CI matrix entry. Also read the PHP floor off the resolved Laravel 13 requirement instead of inferring it from the changelog.
- How do I secure or disable the self-diagnosis web route?
- The package introspects and renders environment detail, including PHP version, extension inventory and filesystem layout, to anyone who can reach the page. Gate the route behind middleware or authorization, or disable it entirely in the published config, and confirm it is not registered by default outside local. Treat the access policy as a task with an owner rather than an afterthought.
- Can I add my own custom checks to laravel-self-diagnosis?
- Yes. Custom checks are plain classes or closures that you add to the configured check list, which makes it straightforward to validate domain-specific preconditions such as cache reachability or required storage buckets. Keep a throwing check contained so a single failure is reported as that check's result instead of breaking the whole run. This extensibility is the main reason the package fits neatly as a peripheral utility.
- What checks does laravel-self-diagnosis include by default?
- The default list covers PHP version, required PHP extensions, writable folders, .env file presence, application key, storage symlink and database connectivity. Which checks actually run is controlled by the published config, so you can trim the set to what matters for each environment. Environment-specific checks are usually added on top of the defaults.
- Is it safe to run laravel-self-diagnosis in production?
- Running the Artisan command inside a deployment or post-deploy smoke step is low risk and is the intended production use. Exposing the web route publicly is the real concern, since it discloses environment detail; gate it with middleware or leave it disabled outside local. Note that extension and ini state often differ between CLI and FPM, so results from a CLI run are not automatically proof that the web SAPI passes.
- Is this a health check or monitoring tool?
- No. It is an opt-in verification checklist you execute before or after a deploy, not observability, continuous monitoring, or a health endpoint with an SLA behind it. It stores nothing and runs no background work, so it cannot track trends or alert you. Treat it as a pre-flight readiness gate and keep real monitoring in a dedicated tool.
- How is beyondcode/laravel-self-diagnosis maintained, and what should I check before upgrading?
- It is a single-maintainer package with MIT licensing, a healthy star count and zero recorded dependents, so the blast radius if it breaks is small but external battle-testing is limited. The 3.1.0 headline is a Laravel Shift compatibility PR, and a second PR in that release carries only an opaque maintenance-style title, so read the diff before bumping. Confirm whether checks, route middleware or config schema changed, and whether composer constraints were genuinely widened. The package is also easy to remove later, since it is one provider registration and one published config file.
Weaver
How can I help you explore Laravel packages today?