- Is mainlycode/health-bundle a Laravel package?
- No. Despite being evaluated as a Laravel/PHP candidate, this is a Symfony bundle: it depends on Symfony's kernel, Bundle extension classes and dependency-injection config tree, none of which exist in Laravel. Composer will install it into a Laravel project without error, but no route, controller or service will be registered. Using it in Laravel would mean writing an adapter, at which point you have rebuilt the feature yourself.
- What does the health check endpoint return?
- It returns a JSON document reporting a status per registered check plus an overall health verdict. On success the endpoint responds with a 2xx code, and when a check fails it returns a failure status code so load balancers and alerting can react. The overview does not spell out the exact failure payload, so audit the response body before exposing it outside your network.
- How do I install mainlycode/health-bundle?
- Install it with composer require mainlycode/health-bundle, then register the bundle in Symfony's config/bundles.php and configure the checks you want under config/packages. There is no bundle loader or service provider in Laravel, so the same Composer install will not wire up any route there. Check the PHP and Symfony version constraints in composer.json before installing.
- Does it work with Laravel 11, and which Laravel versions are supported?
- There is no Laravel compatibility statement and no service provider, so no version of Laravel is officially supported. The package is built as a Symfony bundle and expects a Symfony kernel to boot it. Composer may install it into a Laravel app, but nothing will register a health route or run a check. Treat Laravel support as absent rather than partial.
- How do I add custom checks for the database or cache?
- The bundle advertises pluggable checks for databases, cache and other backing services, which you register through its service configuration in a Symfony application. Because documentation is thin, read the source to confirm the check interface, timeout behaviour and what each check emits on failure. For Laravel, the equivalent is a custom check class registered with spatie/laravel-health or a closure inside your own health route.
- Can I use it for Kubernetes liveness and readiness probes?
- The HTTP status codes map cleanly onto probe expectations: success when checks pass and a failure code when they do not. However, the description does not state whether liveness and readiness are distinguished, nor what timeouts apply to blocking dependency checks. Verify both in the source before pointing Kubernetes at it, and keep probe timeouts shorter than your kubelet thresholds.
- Is it safe to expose the health endpoint publicly?
- No. Health endpoints are a well-known information-leak vector, and a failure response can expose stack traces, environment names, database hostnames or version numbers. Restrict the route at the network layer so only your load balancer or monitoring subnet can reach it. This package is also unvetted third-party code, so audit what it emits before deploying it anywhere internet-adjacent.
- Is mainlycode/health-bundle actively maintained and production ready?
- Adoption signals are close to zero: no stars, no dependents and a single-maintainer footprint. There is no visible security disclosure process, so realistic planning should assume you own the code from day one. The MIT licence lets you fork it, but it does not guarantee anyone upstream will ship a fix. For a Laravel application the build-versus-buy maths points firmly at building.
- What should Laravel developers use instead of this bundle?
- On Laravel 11 and later, enable the built-in route with withRouting(health: '/up') in bootstrap/app.php. If you need dependency probes for database, cache, queue or scheduler, use spatie/laravel-health and configure the checks explicitly. Both options are framework-native, carry no Symfony constraint, and avoid adding an unmaintained dependency for roughly twenty lines of code.
- How is the bundle configured per environment?
- In Symfony, configuration lives in config/packages/*.yaml through the bundle's extension config tree, which lets you enable or disable individual checks per environment. Laravel has no bundle extension contract, so that configuration cannot be reused there; environment-specific behaviour has to live in config/health.php or your own service provider. Keep thresholds and timeouts explicit rather than relying on defaults.