Laravel Keycloak Laravel Package

Product Decisions This Supports

• Build vs. buy on auth UI: this package supplies a ready-made Inertia login page for a Laravel 13 / PHP 8.4 stack. The decision it informs is whether to hand-roll login/Inertia scaffolding or adopt the package and absorb a small, documented integration step. v0.5.1 adds no capability, but it does quantify that integration cost.
• Frontend integration budget: the release documents a concrete gotcha — if resources/js/app.ts assigns a default layout to all pages, the published Welcome/login page must be excluded by name (layout: (name) => (name === 'Welcome' ? null : AppLayout)). Setting layout: null inside the page itself does not work, because Inertia re-applies the default layout. Plan ~1 hour of frontend work plus a note in internal setup docs; without it, users hitting the login screen see the app's sidebar chrome.
• Adoption timing / upgrade posture: 0.5.1 is documentation-only — no code, no requirement changes (PHP 8.4+ with openssl, Laravel 13). Existing adopters need take no action; no migration, no regression risk. This is a zero-cost patch for anyone already pinned.
• Platform-floor as a gating constraint: PHP 8.4+ / Laravel 13 means this package is only usable on the newest stack. That is a roadmap input: if our fleet is not yet on Laravel 13, this is a forward-looking bet, not a near-term option — the opposite is also true, adoption here accelerates a framework upgrade.
• Maturity signal for roadmap: a pre-1.0 package spending a release on documentation polish (rather than features) suggests stabilization ahead of a 1.0. Useful for sequencing: piloting now is low-risk and positions us for a stable line later.
• Support-load forecasting: the documented failure mode is silent (page renders, just with the wrong chrome), which is exactly the class of bug that generates "looks broken" tickets. Budget a standing FAQ entry, or accept recurring support noise.
• Use cases this fits: internal admin tools and SaaS dashboards where the login page must sit inside an existing Inertia layout system, teams already standardized on Inertia + TypeScript, and greenfield apps on Laravel 13 that want auth UI without design work.

When to Consider This Package

Consider it when all of the following hold:

• The application is on Laravel 13 and PHP 8.4+ with the openssl extension available — this is a hard floor, not a soft preference.
• The frontend is Inertia-based (the release notes reference resources/js/app.ts and a Vue/TS-style AppLayout), and a default layout is already applied globally.
• You want a login screen that is published into your app and therefore yours to restyle, rather than a vendor-locked screen.
• You are comfortable adopting a pre-1.0 dependency for auth-adjacent UI, with the understanding that auth logic is still your responsibility to review.
• Your team can absorb a one-line layout exclusion and will document it, or you have no global default layout at all (in which case the gotcha does not apply).

Look elsewhere when:

• You are on Laravel 10/11/12 or PHP 8.2/8.3 — the package simply will not install.
• The frontend is Livewire, Blade-only, or a separate SPA (React Router/Next.js): the Inertia layout semantics at the heart of this release are irrelevant or actively confusing.
• You need a batteries-included auth product — registration, password reset, email verification, 2FA, social login, rate limiting, audit logging. This release covers a login page and its layout behavior; it does not evidence a full auth suite.
• Your organization requires 1.0+ / LTS-grade dependencies for anything touching authentication.
• You need security review artifacts (threat model, pen-test results, disclosure policy) — none are described here; the only technical detail offered is the openssl requirement.

How to Pitch It (Stakeholders)

To executives (one paragraph): This package gives us a pre-built login screen for our Laravel 13 / Inertia frontend, saving design and build effort on a page every user sees. The new 0.5.1 release contains no code changes — it is documentation only — so it carries zero upgrade risk and no migration work. The one substantive item is a documented setup step: if our app applies a default page layout globally, the login page must be explicitly excluded from it, otherwise the login screen shows up with our sidebar attached. That is a one-line frontend change and a permanent note in our setup guide. The main caveat is a hard platform floor (PHP 8.4+, Laravel 13) and pre-1.0 status, which makes this a fit for teams already on the newest stack, not a broad rollout.

To engineering (concise): Requirements unchanged: PHP 8.4+ with openssl, Laravel 13. Package code is untouched in 0.5.1; only the README changed. Action item if you adopt: in resources/js/app.ts, when a default layout is applied to all pages, exclude Welcome by name — layout: (name) => (name === 'Welcome' ? null : AppLayout). Setting layout: null inside the page does not work; Inertia substitutes the default layout regardless. Treat this as a documented integration constraint, not a bug, and add it to our onboarding checklist. No dependency bump required for existing installs, but note we are still on a 0.x line for auth-adjacent UI — keep the auth flow under our own review.