Aura Starter Kit Laravel Package

Technical Evaluation

What this is. bluestarsystem/aura-starter-kit is a Laravel application starter kit consumed at project-creation time via laravel new my-app --using=bluestarsystem/aura-starter-kit. It is scaffolding, not a runtime library — there is no Composer dependency to bump, and therefore no upgrade channel. v0.3.0 is the first release with a substantive authenticated-user surface: a /settings area covering profile, password, and two-factor enrollment (QR code, manual secret, recovery codes, confirmation step), plus a registered-but-disabled email verification screen and a GitHub Actions pipeline running 24 tests with an asset build step.

Architecture fit. The kit sits on Laravel Fortify for authentication actions and adds server-rendered settings views on top. The re-prompt for password on the 2FA page is deliberately aligned with Fortify's own endpoint enforcement, which is the right instinct — it means the UI does not weaken a control the backend imposes. The email verification decision (route registered, feature flag off, one-line enable) is a good ergonomic choice for teams that want to defer that decision without a refactor. For greenfield Laravel services that need first-party auth with 2FA and don't want to hand-roll it, the fit is strong. For existing applications, the fit is close to zero as an installable artifact — it is a reference implementation to be ported.

Integration feasibility. High for greenfield: one command, then delete what you don't want. Low-to-moderate for brownfield: adopting the settings surface means manually porting routes, controllers, views, migrations, and the asset pipeline, and reconciling with any existing auth customization. The absence of a published compatibility matrix in the release notes (PHP version, Laravel major, Fortify version, Node/Vite version, supported databases) is the single biggest blocker to a confident feasibility call and must be resolved before adoption.

Technical risk.

• Pre-1.0 churn. v0.3.0 signals an unstable public surface. Expect breaking changes to routes, view names, and settings layout between minor versions.
• Vendor concentration. A single-namespace package with no stated maintainer roster or governance implies bus-factor risk on a security-sensitive surface.
• Known scope gap: passkeys. Fortify ships WebAuthn support; this kit does not implement the browser ceremony. That is honestly disclosed, but it means a team adopting this kit inherits a visible feature gap relative to what Fortify advertises, and must fund the JavaScript work themselves.
• Thin test surface. 24 tests for an auth-and-2FA settings area is a signal of intent, not of coverage. The CI pipeline builds assets before testing, which is good practice, but the notes do not indicate static analysis, linting, or coverage reporting.
• Security-relevant UX decisions. Displaying the TOTP secret in plaintext for users who cannot scan is standard and acceptable, but it widens the shoulder-surfing/screen-share exposure window and should be paired with an explicit warning in the UI. Recovery-code storage, session invalidation on password change, and rate limiting/lockout on the password re-prompt are all unaddressed in the notes and are the questions I would ask first.

Key questions for the maintainer.

1. What is the supported PHP/Laravel/Fortify/Node matrix, and is there a stated policy for tracking Laravel majors?
2. What is the license, and what are the contribution and release-cadence expectations?
3. What is the upgrade story for teams that have already diverged — changelog granularity, upgrade notes, or nothing?
4. Is 2FA opt-in per user or enforceable per organization, and is there an admin-side reset path?
5. Are recovery codes hashed at rest, single-use, and regenerable? Is the TOTP secret encrypted with the app key (Fortify's default) and confirmed before activation?
6. Does password change invalidate other sessions and remember-me tokens?
7. Is the disabled email-verification route gated server-side, or only hidden in the UI?
8. What is the coverage of the 24 tests against the auth paths specifically, and does CI run any static analysis?
9. Is passkey support on the roadmap with a target version, or indefinite?

Assessment. Worth a timeboxed spike for greenfield Laravel work, contingent on answers to questions 1, 2, and 5. Not advisable as a retrofit into an existing codebase, and not advisable where passkeys are a near-term compliance or product requirement without budgeting the WebAuthn ceremony work separately.

Integration Approach

Stack fit. Laravel with Fortify, server-rendered Blade settings views, and a Vite-based asset pipeline. Teams currently on Breeze, Jetstream, or raw Fortify will recognize the shape immediately; this kit is closest in scope to a trimmed Jetstream with the team/billing surface removed and the 2FA flow made explicit. Teams on Inertia/React/Vue front-ends should assume view-layer work is required rather than expecting a drop-in.

Migration path. Three viable patterns, in order of preference:

1. Greenfield scaffold. Run the laravel new --using command, pin to a specific tag (v0.3.0) rather than a branch, and record the originating tag plus the commit SHA in an ADR. From that moment the code is yours.
2. Reference implementation. Scaffold a throwaway application, then diff its auth layer against your existing app and port only what you need — typically the settings routes, 2FA views, and the recovery-code handling.
3. Fork and track. Fork the kit into an internal template repo with your organization's CI, linting, and security policy applied, and periodically re-diff against upstream releases. This is the right answer for organizations that will create more than two or three Laravel services.

There is no fourth path where you composer update your way to v0.4.0. Plan for that explicitly so it does not surprise anyone at the first Laravel major release.

Compatibility. Unverified as of this assessment. Before committing, confirm: PHP and Laravel version constraints, the pinned Fortify version, Node and Vite versions required by the CI asset build, supported database drivers for the shipped migrations, and whether the 2FA implementation relies on any extension not enabled by default (GD or Imagick for QR generation is the common one). Each of these is a one-line answer from the maintainer and a hard blocker if absent.

Sequencing.

1. Spike (1–2 days). Scaffold in a sandbox, run the suite locally, walk the full auth journey manually: register, verify, enable 2FA, log out, log in with code, consume a recovery code, change password, confirm session invalidation.
2. Security review (2–3 days). Focus on the questions in the previous section — secret handling, recovery-code storage, rate limiting, session invalidation, route gating.
3. Decision gate. Adopt, adopt-with-fork, or use as reference only. Record the rationale.
4. Hardening (if adopting). Layer in your own static analysis, dependency scanning, coverage thresholds, and secret-scanning in the CI pipeline. The shipped workflow is a floor, not a ceiling.
5. Passkey work item. Scope the WebAuthn ceremony as a separate, estimated backlog item. Do not let "Fortify supports it" create a false expectation in product planning.
6. Template publication. Publish the pinned, hardened version internally with a README covering the divergence policy and the upgrade cadence you have committed to.
7. Ramp-up. Two or three engineers through the spike before broad enablement, so the knowledge is not concentrated in one person.

Operational Impact

Maintenance. The dominant operational fact is that starter kits do not receive upstream patches. Once scaffolded, every Laravel major, every Fortify security advisory, and every PHP version bump is your team's responsibility to reconcile against a codebase you now own. Budget a recurring line item — realistically one to two engineer-days per Laravel major release and a defined on-call path for Fortify security advisories, which need a same-week response regardless of your normal cycle. Assign a named owner for the auth surface; auth code with no owner decays badly.

Support. No vendor SLA. Support is the public issue tracker, which for a small-namespace package means response times are unbounded. For anything touching 2FA, that is not a sufficient escalation path, so your internal runbook needs to cover: how to disable 2FA for a locked-out user, how to regenerate recovery codes, how to rotate the app encryption key given encrypted TOTP secrets, and how to roll back a settings-area deploy. Write these before you need them.

Scaling. Auth is not a throughput bottleneck. QR generation happens once per enrollment; TOTP verification is a cheap HMAC comparison per login. The scaling considerations are the standard Laravel ones: shared session store once you run more than one app node, and a shared rate-limiter backend (Redis) so the password re-prompt and login throttles are enforced consistently rather than per-node. Recovery-code lookups should be indexed. None of this is unusual, but none of it is addressed by the kit either.

Failure modes. In rough order of likelihood and blast radius:

• Fortify upgrade breaks the custom 2FA views. The kit's settings views and Fortify's actions are coupled by convention, not contract. Pin Fortify, read its upgrade notes, and treat a minor bump as a code change requiring review.
• Recovery-code lockout. Users lose the secret and the codes, and there is no self-service path. This will generate support tickets from day one; a documented admin-assisted reset is mandatory, not optional.
• Asset build failure blocks CI. The workflow builds assets before testing, so a Node or Vite version drift takes down the whole pipeline rather than just the front-end job. Pin the Node version in the workflow.
• Dormant email-verification route. Registering the route with the feature off is convenient but creates a live endpoint that behaves differently from the UI. Verify it is gated server-side and that no verification prompt or dead link is rendered while the flag is off.
• Passkey expectation gap. Users who read Fortify's documentation will assume passkeys work. Disclose the gap in the README or you will absorb product questions that should have been answered upstream.
• Secret exposure on enrollment. The plaintext TOTP secret is visible on screen. Add explicit copy warning against screenshots and screen sharing, and ensure the confirmation step cannot be skipped.

Ramp-up. Low for engineers fluent in Laravel and Fortify — one to two days to be productive in the settings area. Customization work (new settings pages, alternative second factors, admin-side enforcement) requires reading Fortify's internals and understanding the 2FA ceremony, which is a further two to three days. The passkey gap adds a genuinely separate skill requirement: a WebAuthn browser ceremony is front-end work with its own pitfalls around origin binding and authenticator compatibility, and should be staffed as such rather than folded into a general auth ticket. Teams without a security reviewer should budget external review time for the initial adoption; the auth surface is the wrong place to learn by shipping.