Laravel Site Protection Laravel Package

Product Decisions This Supports

• Private launch sequencing. Lets you ship a site to a real domain before it is ready for public traffic — pre-announcement holding pages, investor/client previews, soft launches — without taking on the cost of building accounts, invites, or an allowlist system. The product decision it unlocks is "launch the URL now, open the doors later," which is usually a scheduling win rather than a technical one.
• Build vs. buy for a throwaway gate. The alternative is a hand-rolled middleware plus a Blade form plus session handling — a few hours of engineering plus the review and test overhead that comes with anything touching access to a site. At 45 stars under MIT, this package is a buy the small thing decision: cheap to adopt, cheap to remove.
• Deferring the auth investment. A shared password is a legitimate intermediate state between "public" and "we have a real identity system." Adopting it is an explicit decision to postpone SSO/roles/audit until there's a user model worth building around — useful when the roadmap for accounts is still unsettled.
• Agency and stakeholder review workflows. For client sign-off on staging, or a single review link shared with a handful of people, per-user accounts are overkill and per-person provisioning is friction. One password, rotated per review cycle, is often the better product trade.
• Where it constrains the roadmap. Behind a shared gate you lose per-user analytics, segmentation, and any behavioural signal — everyone is one visitor. If the launch plan depends on measuring engagement during the gated period, this is the wrong tool. Same for SEO: a password wall in front of indexable content is a deliberate, temporary trade.

When to Consider This Package

Adopt when most of these hold:

• Laravel codebase, and the gate needs to cover the whole site or a route group rather than specific resources.
• The gate is short-lived (days to a few weeks) and the blast radius of a leaked shared password is acceptable.
• You have no auth layer today and don't want to stand one up for a single preview.
• Staging/pre-production, client review, a holding page, or an event/microsite before public announcement.
• You are willing to pin the version, read the (small) source, and fork if the maintainer goes quiet — 45 stars means a small maintenance surface, not a guarantee.

Look elsewhere when:

• You need identity: per-user access, revocation of one person, roles, audit trails, MFA. Reach for Laravel Breeze/Fortify/Jetstream, or put the gate in front of the app entirely with Cloudflare Access, an ALB auth rule, or oauth2-proxy. Laravel's built-in HTTP basic auth middleware is also a zero-dependency option if a browser prompt is acceptable.
• The gate is meant to be permanent production infrastructure, or a compliance/SOC 2 control. A shared password is not an access control you can evidence.
• You need branded, localised, or otherwise custom gating UX that fights the package's defaults — at that point the build is smaller than the override.
• You're serving cached or CDN-fronted pages and can't guarantee the gate is enforced before the cache — verify this explicitly; a password form that the edge serves around is worse than no gate.

How to Pitch It (Stakeholders)

To executives: this is a small, free, MIT-licensed Laravel package that puts one shared password in front of the site. It buys us the ability to put a real URL in front of clients and partners this week instead of waiting on an accounts system, at roughly the cost of an afternoon. It is a launch-timing tool, not a security product — no per-person logins, no audit trail — and we should expect to replace it when we build real authentication.

To engineering: middleware plus a password form, session-based unlock, configuration-driven credential. The integration surface is small enough to read end-to-end before merging. Pin the version, keep the password in the secret store rather than a committed config file, mount it on a route group so removal is a one-line change, confirm rate limiting on the submit endpoint, and confirm it sits in front of any response caching/CDN.

Risk framing: low integration cost, low lock-in — it's middleware, so ripping it out is trivial. The real risk is maintenance: a 45-star package with a small maintainer base. Mitigate by vendoring or forking, and treat it as a bridge with a known expiry date rather than a permanent layer.