Laravel Blockade Laravel Package

Product Decisions This Supports

• Build vs. buy on a non-differentiating surface — unchanged, now better evidenced. Release 1.1.0 adds dark mode via prefers-color-scheme, a new SVG illustration, and PostCSS-built CSS. That is presentation polish, not capability. It confirms the package's center of gravity is styling a holding page, which is exactly the part we would write in-house. The decision it supports is still "build a 1–2 day internal middleware on top of Laravel's native maintenance mode," not "add a dependency."
• Launch and rollout gating. A named maintenance/WIP state unlocks product decisions like pre-launch "coming soon" pages for marketing, gating a partially shipped module behind a branded holding page, or dark-launching a route group for internal users only. Framing this as a capability rather than a package lets you scope it to whichever surfaces actually need it (public site vs. authenticated app vs. partner API).
• Maintenance-window policy and brand/UX consistency. Whether the org wants scheduled, communicated downtime versus always-on degradation is a product/ops decision. A config-driven page makes "we will show a friendly 503 during migrations" a deliberate choice with a customer-facing experience. The new dark-mode support raises a small but real product question: does our holding page need to honor the user's system theme? For a page users see for seconds, usually no — but it's now an explicit checklist item rather than an implicit gap.
• Roadmap trade-off on dependency risk. Adopting an unmaintained package creates a standing tax: PHP/Laravel upgrade blockers, security-review exceptions, and a future migration project. 1.1.0 does not reduce that tax — it adds to it slightly, since upgrading now requires running php artisan blockade:install to publish new assets, i.e. published, versioned files living in our repo that can drift from the package. That cost lands on the roadmap whether or not the feature is ever revisited.
• Segmentation of the bypass mechanism. Who gets past the wall — QA IPs, internal staff, a secret token URL, a cookie — is a product and security decision (access control, not just messaging). Useful to settle now even if the implementation is trivial. Nothing in 1.1.0 touches this.
• Scope discipline on "while we're in there." The most instructive thing about this release is that a four-year-dormant package resurfaced to ship cosmetics rather than Laravel compatibility, scheduling, or auth-aware bypass. That's a useful signal for how we prioritize our own version: ship the boring correct thing (native artisan down + thin view), don't grow a styling surface we then have to keep current.

When to Consider This Package

Consider it only if all of the following hold:

• You are on a Laravel version this package actually supports. 1.1.0 is a presentation release — it carries no framework-compatibility signal, and the last functional release predates Laravel 9. Verify against your framework version before anything else.
• You need a view-driven, heavily branded maintenance page — and specifically want the new dark-mode/illustration treatment — and would rather stand it up in an afternoon than a sprint.
• The blast radius is small and reversible: a single marketing site or an internal tool, not a revenue-critical path.
• You are prepared to vendor/fork it, pin it, and own the code — treat it as sample code you adopt, not a dependency you rely on. This now includes owning the published CSS assets and re-running blockade:install on upgrade.
• Your security posture tolerates an unreviewed, low-visibility package in the request pipeline (middleware sits in front of every request — that is a meaningful trust boundary for a 12-star repo). Note that publishing CSS/assets does not make the middleware path any more reviewed than it was.

Look elsewhere — or build — if any of these are true:

• You are on Laravel 8+ and the native php artisan down already covers you: secret/token bypass, custom rendered view, redirect, custom status code, and Retry-After are all built in. This is the default recommendation.
• You need authenticated bypass (SSO/staff-only), per-tenant or per-region maintenance state, scheduled windows, or automated toggling from CI/deploy hooks — none of which a config-flag middleware gives you for free.
• You need auditability, an SLA, CVE monitoring, or a security review sign-off. Zero dependents and a stale release mean no downstream pressure to fix issues.
• Downtime should be handled at the edge (CDN/load balancer returning 503 with a static page) rather than in application code — often the better answer for full outages, since the app may be the thing that's down.
• You need it to survive the next two Laravel majors without a fork.
• New: you are unwilling to absorb an asset-publishing step into your deploy/upgrade runbook. A cosmetic release that mandates a manual artisan command is friction we can trivially avoid by rendering our own view.

Practical next step (unchanged): spike the native artisan down path first. If it falls short, the gap is almost certainly presentation or bypass logic — both cheaper to write in-house than to inherit. 1.1.0 is a good visual reference for the presentation layer; take the design cues (layout, dark-mode media query) and leave the code.

How to Pitch It (Stakeholders)

To executives: We re-evaluated the community maintenance/holding-page package after its 1.1.0 release. The new version adds dark-mode styling, a new illustration, and a PostCSS asset build — cosmetic improvements only. It does not add framework compatibility, access-control, or scheduling capability, and it introduces a required blockade:install asset-publish step on upgrade. Recommendation stands: do not adopt. Laravel already ships this capability natively, and the branded-page gap is roughly one to two engineer-days of in-house work. This keeps an unmaintained component out of our request pipeline and avoids an upgrade blocker come the next framework major.

To engineering: We're still not taking the dependency. 1.1.0 is a styling release — dark mode via prefers-color-scheme, a new SVG, PostCSS build, and published CSS assets that must be installed with php artisan blockade:install. Nothing about our decision changes: use the framework's built-in maintenance mode and, if we need a custom view or bypass rules, write a thin middleware we own. Treat 1.1.0 as a design reference — steal the responsive/dark-mode treatment and the illustration approach — not code to install. If we do implement in-house, spend the extra hour on the bypass path and its tests, since that's the part with access-control implications.

The one-line version: the new release made it prettier, not safer or more current — right problem, wrong artifact; we'll build the twenty lines ourselves and own them.