Fortify Laravel Package

Technical Evaluation

Architecture fit. orchid/fortify is not a library — it is a reference template that maps Laravel Fortify's headless auth endpoints onto Orchid Platform Screen/Layout classes. The architecture is therefore two-layered: Fortify owns the backend (actions, guards, throttling, 2FA state), Orchid owns the surface (forms, theming, routing conventions). Fit is only correct when both of those are already in the stack. If Orchid Platform is not installed and pinned, the package has no value; if the team is not prepared to own the copied code, the package has negative value.

Integration feasibility. High in principle, non-trivial in practice. The value is concentrated in one file — the service provider that rebinds Fortify::loginView(), registerView(), resetPasswordView(), twoFactorChallengeView() to Orchid Screens — plus a routes file and a directory of auth Screens. That is a legible amount of code to read. The realistic cost to a working /admin/login is measured in hours; the remaining flows (reset, verification, 2FA) are mechanical if the first one lands. The failure modes are known and diagnosable: route collisions between Fortify's /login and Orchid's /admin/*, guard mismatches between config/fortify.php and config/platform.php, and view bindings that only fail at request time.

Technical risk. Concentrated on the authentication boundary, which is the worst place for it:

• Unmaintained surface. Zero stars, zero dependents, no CI, no test suite, no triage. Recent releases are dependency bumps only (0.0.12 is a single "Updated dependencies" PR). This is a template, not a supported dependency.
• Version drift. Orchid's Screen/Layout API has moved across majors; templates characteristically lag. The failure mode is rendering, which frequently only shows in staging.
• 2FA lockout. Recovery-code surfacing and an admin-side reset path are not optional. This is a support incident waiting to happen, not a bug ticket.
• Two auth stacks. Fortify plus Orchid's native auth plus anything Breeze-shaped produces divergent password-reset behaviour and intermittent guard bugs that are miserable to reproduce.
• No upstream safety net. Whatever coverage exists on the auth flow is coverage the adopting team writes.

Key questions a TPM must force answers to before funding work:

1. Does the pinned Orchid version already cover the requirement — particularly 2FA? If yes, the business case collapses to zero, and that is the best outcome.
2. Has the team committed to one authoritative guard, and does it match on both Fortify and Orchid configs?
3. Who owns this code after adoption, and can at least two engineers trace login → 2FA → session end to end?
4. Is SSO on the roadmap? Fortify does not do SAML, OIDC, or social login. This package must not appear in any deck as solving it.
5. What is the review budget for an unaudited template sitting on the most security-sensitive surface in the product?

Integration Approach

Stack fit. This is an Orchid-only play. All value is the Orchid-specific glue; on any other Laravel app the template is inert. The correct mental model is copy, don't require — clone to a throwaway branch, read, port the pieces needed, and own every line. It is explicitly not a composer require you track upstream.

Migration path. Sequence the flows rather than porting them all at once, because each one is independently verifiable and independently valuable:

1. Login + logout. The proof point. A valid user must land inside the panel. If this fails, an hour is spent instead of a sprint.
2. Password reset. Requires password_reset_tokens and a broker in config/auth.php.
3. Email verification. Signed URLs must point at an Orchid route, not /email/verify — otherwise gating the panel on verified permanently locks users out.
4. 2FA last. It touches session state (login.id), recovery codes, and the challenge redirect, and it is where lockout risk concentrates.

Compatibility. Pin Orchid, Fortify, and Laravel explicitly. Treat any Orchid major upgrade as a planned migration, not a routine bump. Resolve the route-collision decision up front and explicitly: either set fortify.prefix to admin so everything lives under the panel, or keep Fortify's routes and have the panel redirect to them. Running both unmodified yields redirect loops or a login 404 — the day-one failure.

Sequencing and customisation surface. Keep Fortify's backend and replace only the surface. Behaviour belongs in Fortify actions (CreateNewUser, AttemptToAuthenticate, ResetUserPassword, UpdateUserProfileInformation), post-login destinations in Fortify::redirects(), and throttling in RateLimiter::for('login', ...). Everything else in the template is presentation and can be edited freely. Fold 2FA enrolment into Orchid's existing Profile screen as a subclass rather than replacing it wholesale — that preserves upstream profile behaviour and avoids a full-screen fork.

Testing. Because views are rebound, tests asserting view names will break. Assert routes and Screen classes instead, and write feature tests for exactly the flows you would otherwise be trusting upstream on: throttled login, successful 2FA challenge, recovery-code consumption, password-reset token expiry. There is no CI in the repo; this coverage is authored locally or not at all.

Operational Impact

Maintenance. Permanent, small, and non-zero. The package saves roughly two to three days of screen-building and creates an ongoing ownership obligation. Because it is a template, upstream releases will not carry your changes — you are forked in practice whether or not you fork in git. Budget for periodic dependency review and for re-reading the Orchid Screen API on every major upgrade.

Support. The realistic support load is concentrated in two areas: 2FA lockouts (recovery codes not surfaced, secrets orphaned during any migration off Orchid's native 2FA) and guard/session anomalies that only reproduce in staging. A support runbook is a prerequisite, not a nicety — at minimum an admin-side 2FA reset (column wipe or console command) and a documented debugging order: route:list | grep -E 'login|two-factor', then guard parity between Fortify and platform configs, then dd() inside the loginView callback to confirm which Screen resolves, then session driver parity between environments.

Scaling. Auth traffic is low-volume and the scaling story is unremarkable — this is not a throughput concern. The scaling risk is organisational: multiple Laravel apps standardising on "first-party apps authenticate through Fortify actions" will find the Orchid admin panel the awkward exception. This template is the plausible path to bring that app class into the standard, or the concrete artifact to justify formally exempting it. That is a platform-standardisation decision, not a per-app one, and it should be made once.

Failure modes to plan for. Route collision (redirect loop or login 404); guard mismatch (correct credentials, bounced back to login); view binding resolving to a Screen that throws in build() — visible only on /login, easy to miss until you log out); verified middleware with no wired verification route (permanent lockout); 2FA with no recovery-code path (support incident); unpublished Orchid assets (auth screens that look right locally and broken in production). Each has a cheap pre-flight check; none has an upstream safety net.

Ramp-up. Low ceiling, meaningful floor. The template is readable — the service provider is the whole integration — so a mid-level Laravel engineer grasps the pattern quickly. But the auth boundary demands that at least two engineers can trace login → 2FA → session end to end before shipping, and that the flow be reviewable by someone other than its author. Enable features in config/fortify.php only as corresponding Screens exist; a flag with no screen is a 500 the first time a user hits that path. If the team cannot absorb permanent ownership of auth code, this trade is not favourable, and the correct answer is to stay on Orchid's native auth and revisit when the pinned version closes the gap.