Padlock Laravel Package

Product Decisions This Supports

• Pre-launch and preview environment protection. A lightweight shared-secret gate on staging, UAT, demo, and preview deployments lets product, design, and sales-engineering circulate links without standing up full auth or exposing unfinished work to the open internet.
• Build vs. buy (vs. "just use basic auth"). The decision is usually between hand-rolling a middleware + config + env-var password check (a few hours of engineering plus permanent maintenance), relying on host-level basic auth (fragile across PaaS/CDN setups, poor UX for non-technical reviewers), or adopting a small, single-purpose package. This package competes on the third option: narrow scope, low integration cost, no vendor contract.
• Roadmap and platform-upgrade sequencing. v4.0.0 tracks Laravel 12 and drops Laravel 11. That makes the package's support matrix a direct input to your framework upgrade plan: any service still on Laravel 11 is pinned to 3.x and will stop receiving package updates, so the upgrade ticket and the framework upgrade ticket should be scheduled together rather than separately.
• Scope containment for internal tooling. Because the package's role is a coarse gate rather than an identity system, it is a good fit for low-sensitivity, short-lived, or internal surfaces — and a useful forcing function to keep "temporary protection" from quietly becoming the production authentication story.
• Vendor/maintenance risk tracking. A dependency bump release is a cheap health signal. Regular framework-version tracking with named maintainers is a positive input when scoring third-party dependencies; a package that lags two Laravel majors is a flag.

When to Consider This Package

Consider it when most of the following hold:

• You are on Laravel 12 (v4.0.0 requires it; Laravel 11 is no longer supported — see the caveat below).
• You need coarse, all-or-nothing access to a set of routes — one shared password, not per-user accounts.
• The protected surface is non-sensitive or short-lived: staging, demos, internal dashboards, pre-release review links.
• You want minimal footprint: no database tables, no admin UI, no user management, config-and-env-var setup.
• Your team has explicitly accepted that the gate is a speed bump, not a security boundary, and the blast radius if the password leaks is acceptable.

Look elsewhere when:

• You need real identity. Per-user accounts, roles/permissions, SSO/SAML, MFA, session revocation, or audit logging are all out of scope. Reach for Laravel's own auth scaffolding, Breeze/Jetstream, or a hosted IdP (Auth0, WorkOS, Cognito).
• You are compliance-bound. SOC 2 / ISO 27001 / HIPAA controls around authentication, password rotation, and access review are unlikely to be satisfiable by a shared secret.
• You are still on Laravel 11 or earlier. Stay on 3.x — it will not receive framework-alignment updates, and you should have a dated plan to move to Laravel 12. If the upgrade is blocked for other reasons, budget for forking or replacing this dependency.
• You need fine-grained or per-environment policy (e.g. different credentials per tenant, IP allowlisting, time-boxed access with expiry). Prefer dedicated middleware you control, or a platform-level feature (Vercel/Netlify/Cloudflare Access, an ALB with auth).
• You want a maintained-by-many dependency. This is a small, single-maintainer project; if that is a procurement blocker, the fallback is a ~50-line middleware you own.

How to Pitch It (Stakeholders)

For executives (one paragraph). We are evaluating a small Laravel package that puts a password gate in front of non-public parts of our application — the kind of thing that keeps unfinished work off the open web and lets reviewers into a staging build without an account. It is cheap to adopt and cheap to remove. The new 4.0.0 release is a maintenance release: it moves the package onto Laravel 12, the framework version currently receiving fixes, and formally drops Laravel 11. That is good news on dependency health, and it comes with one planning consequence — any service we leave on Laravel 11 will be frozen on the previous version of this package, so this becomes a small, concrete line item in our framework upgrade plan rather than a separate initiative. It is not an authentication or access-control system and should not be positioned as one.

For engineering (the practical summary). v4.0.0 is a compatibility-only release — Laravel/Laravel Zero 12.x support, Laravel 11 dropped. No functional changes and no new configuration surface, so the integration surface stays the same. Practical implications:

1. Pin deliberately. ^3.0 on Laravel 11 apps, ^4.0 only once the app is on Laravel 12. Do not widen constraints to "make Composer happy" — a mixed constraint will resolve to 3.x and mask the fact that you are on an unsupported branch.
2. Treat it as a gate, not auth. Scope it to staging/demo/internal routes, keep the secret in env/secret manager (never in a committed .env or a hardcoded fallback), and make sure protected routes are not also reachable via a hostname or CDN path that bypasses the middleware.
3. Sequencing. Fold the constraint bump into the Laravel 12 upgrade PR rather than opening a separate dependency ticket; if the framework upgrade is not scheduled, note the maintenance risk explicitly and set a review date.
4. Escape hatch. The total logic is small. If maintainer responsiveness or the version-drop cadence becomes a problem, in-house replacement is a contained afternoon of work — which is exactly why the build-vs-buy call here is low-stakes.