- Is prolix/maintenance-bundle a Laravel package?
- No. Despite being installable via Composer, it is a Symfony bundle built around HttpKernel request listeners and console commands, so it does not plug into Laravel's service container or middleware stack. Laravel developers should use the built-in php artisan down command instead, which already serves a 503 response and supports secret bypass tokens.
- Can I install LexikMaintenanceBundle in a Laravel application?
- You can run composer require, but it will not work as intended because Laravel has no Symfony bundle registration or kernel event priority model. There is no middleware or service provider shipped with this package. Use php artisan down, a custom middleware, or a reverse-proxy rule instead.
- How do I put a Laravel app into maintenance mode without this bundle?
- Run php artisan down, optionally with --secret to allow a bypass URL, --retry to set the Retry-After header, and --render to serve a custom Blade view. Bring the app back with php artisan up. This is native, maintained by the Laravel team, and requires no third-party dependency.
- Which Symfony versions does this maintenance bundle support?
- Support depends on the release you install, so check the package's composer.json and CI matrix before adopting it. Recent releases target maintained Symfony branches, but you should confirm alignment with your LTS version, PHP 8.0+ requirement, and Twig if you want a custom page. Do not assume Symfony 7 compatibility without verifying.
- How does IP whitelisting work in the Lexik maintenance bundle?
- You list trusted IP addresses in the bundle configuration, and requests from those addresses bypass the 503 response while everyone else sees the maintenance page. Confirm whether your version supports CIDR ranges, header-based rules, or session-based admin bypass, because the README does not guarantee all of these. Test the allowlist in staging before relying on it during an incident.
- Can I customize the 503 maintenance page and response headers?
- Yes. The bundle lets you point to a custom Twig template for the maintenance page and configure the HTTP status code and Retry-After header. Keep the page lightweight and self-contained because it must render even when your application dependencies are degraded. Verify that any CDN or WAF in front of the app does not cache the 503 response.
- Does the maintenance flag work across multiple servers or containers?
- By default the lock is typically file-based on the local filesystem, which means each node needs the flag or you risk inconsistent behavior behind a load balancer. Confirm whether the flag backend is pluggable to Redis, a shared cache, or a database before using it in a multi-node deployment. If not, set maintenance at the reverse-proxy or CDN layer instead.
- Are healthchecks and load-balancer probes blocked during maintenance?
- They can be, because the listener short-circuits requests at the kernel level and does not automatically exempt probe paths. If your load balancer treats a 503 as unhealthy, you may lose the instance entirely during maintenance. Explicitly allowlist probe paths or handle healthchecks at the proxy layer.
- Is the maintenance page served before or after the security firewall?
- That depends on the kernel event priority the bundle registers, which can shift between Symfony major versions. In many setups the listener runs early and blocks all users, including logged-in admins, unless they match the IP allowlist. Verify the behavior in your own app and document how admins can bypass maintenance.
- Is prolix/maintenance-bundle production-ready and actively maintained?
- It is a small, low-risk utility, but it has low adoption, few dependents, and single-maintainer stewardship, so treat it as a replaceable dependency. Wrap lock and unlock calls behind your own interface or command so you can swap in a cache-flag solution or proxy rule later. Pin the version, watch releases, and avoid coupling business logic to the bundle.