# Laravel + Livewire

PHP product applications with a cohesive UI, auth and queue toolset.

Language: PHP | Reviewed: 2026-10-10 | Evidence: documentation-reviewed

Core guidance checked: 2026-10-13. See /research-freshness.json for review scope. These recipes and selected dependency combinations need qualification in the actual project.

## Application role
Components: web
UI: server
Deployment: server

## Use cases
- SaaS
- Administrative and business applications
- Server-driven interactive products

## Fit
- PHP team or Laravel ecosystem fit is strong.
- Integrated auth, queues and concrete agent inspection tools reduce assembly work.

## Choose something else when
- The UI fundamentally requires an offline/client-state architecture; use the Inertia alternative if Laravel still fits.
- A hosting plan cannot operate needed queue workers or scheduled jobs.

## Agent workflow
- Read README, dependency manifests, lockfiles, runtime pins and the maintained project workflow before changing anything. Preserve an existing stack unless reconsidering it is part of the request.
- Use this guide to select tools by requirement. Resolve compatible versions from official and installed-version documentation; record the actual lockfile and runtime versions.
- Create a plan for schema changes, identity, authorization, external effects and deployment. A library choice does not complete its integration.
- Run relevant checks after configuration. Exercise the real interface, failure paths and packaged artifact on the intended target. Report commands, versions, results and untested behavior.
- On failure, retain the command and diagnostic, fix the failing prerequisite and resume there. Do not regenerate over existing work or suppress failures to make a check green.

## Best practices
- Use policies and gates for permissions; a starter's authentication flow does not supply product authorization.
- Preserve the selected starter's test conventions and verify Livewire behavior in a real browser.
- Supervise queue workers and schedule execution explicitly. Verify retries and avoid duplicate external effects.
- Use Laravel Boost during development with the project's installed documentation; keep production exposure separate.

## Tools

### UI: Official Livewire starter kit + Blade/Tailwind

One supported starter establishes coherent UI/auth integration.

Limits and integration: Starter includes Flux; distinguish its free components from paid Pro assets.


- https://laravel.com/framework/docs/13.x/starter-kits
- https://fluxui.dev/pricing

Alternatives: Official React/Vue/Svelte Inertia kits for heavier client interactions

### Database and migrations: PostgreSQL + Eloquent + Laravel migrations

Conventional ORM and migrations with a production relational store.

Limits and integration: Use constraints; production-engine integration tests; never use migrate:fresh against retained data.


- https://laravel.com/framework/docs/13.x/database
- https://laravel.com/framework/docs/13.x/migrations

Alternatives: SQLite for local/small deployments; existing MySQL where operationally established

### Authentication: Starter-kit Fortify auth

Existing authentication flow plus resource-level authorization.

Limits and integration: Policies remain application work; managed identity adds external terms/cost.


- https://laravel.com/framework/docs/13.x/starter-kits
- https://laravel.com/framework/docs/13.x/authorization

Alternatives: WorkOS starter variant for managed identity requirements

### Authorization: Laravel policies and gates

Existing authentication flow plus resource-level authorization.

Limits and integration: Policies remain application work; managed identity adds external terms/cost.


- https://laravel.com/framework/docs/13.x/starter-kits
- https://laravel.com/framework/docs/13.x/authorization

Alternatives: Existing explicit resource-level authorization implementation; identity providers still require policies

### Queues: Laravel database queue + supervised workers

Simple starting infrastructure with explicit scale-up options.

Limits and integration: Use after-commit dispatch, idempotent jobs, finite retries and worker restarts. Horizon requires Redis.


- https://laravel.com/framework/docs/13.x/queues
- https://laravel.com/framework/docs/13.x/horizon

Alternatives: Redis + Horizon for queue dashboards/balancing; SQS for an established managed queue

### Tests: Pest or PHPUnit from starter; Dusk for key browser flows

Application and browser verification complement each other.

Limits and integration: Use a dedicated test database and install Dusk only in development.


- https://laravel.com/framework/docs/13.x/testing
- https://laravel.com/framework/docs/13.x/dusk

Alternatives: Keep the existing test runner rather than changing syntax for its own sake

### Lint, static analysis and security: Pint + Larastan/PHPStan + Composer audit

Formatting, static checks and dependency advisory checks expose different failures.

Limits and integration: Install a compatible Larastan version and configure its extension; no audit substitutes for authorization tests.


- https://laravel.com/framework/docs/13.x/pint
- https://github.com/larastan/larastan
- https://getcomposer.org/doc/03-cli.md#audit

Alternatives: Existing equivalent tooling if already maintained

### Deployment: PHP-FPM web service + worker supervisor + scheduler on chosen host

A conventional process model is a practical default.

Limits and integration: Serve only public/; APP_DEBUG=false; persist uploads; reload workers after releases; paid platforms are optional.


- https://laravel.com/framework/docs/13.x/deployment

Alternatives: Laravel Cloud for managed operation; Forge for server management

### Agent tooling: Laravel Boost development dependency

Version-aware documentation and route/schema/log inspection provide concrete context.

Limits and integration: Tools can execute application code; use development credentials and honor maintained repository instructions. A README-only integration is an optional project policy; inspect installed Boost help before opting out of generated instructions.


- https://laravel.com/framework/docs/13.x/ai

Alternatives: Normal CLI/docs when MCP is unavailable

### Licensing and hosting: Laravel framework MIT; self-hostable

Framework use does not mandate a hosting subscription.

Limits and integration: Check each optional asset/package/service license separately.


- https://github.com/laravel/framework/blob/13.x/LICENSE.md
- https://fluxui.dev/pricing

Alternatives: Optional paid Flux Pro and managed services

### Transactional email: Laravel Mail

Mailables and queue integration keep delivery in application conventions

Limits and integration: Configure the selected mailer and verified sender; use queued mail where required, after-commit handling and failed-job monitoring. Provider acceptance is not inbox delivery.


- https://laravel.com/framework/docs/13.x/mail

Alternatives: Preserve an existing compatible project choice

### Uploads and object storage: Laravel Storage / Flysystem

Storage disks support private local or S3-backed files

Limits and integration: Configure filesystems.php; install the selected adapter only, authorize downloads and uploads, define size/type limits and retention. Ephemeral deploy disks are not durable shared storage.


- https://laravel.com/framework/docs/13.x/filesystem

Alternatives: Preserve an existing compatible project choice

### Realtime transport: Laravel broadcasting + Reverb when self-hosted sockets are required

Private channels integrate realtime application events

Limits and integration: Use the installed broadcasting setup; configure Echo, channel authorization, queued events and a supervised Reverb process. Verify TLS/proxy/scaling and reconnect; broadcast is not durable replay.


- https://laravel.com/framework/docs/13.x/broadcasting

Alternatives: Preserve an existing compatible project choice

## Architecture and developer workflow

Laravel combines conventional routes, middleware, authentication guards/providers and database migrations. Livewire components combine PHP behavior with Blade rendering. Recommendation: use these conventions for connected forms and business screens; keep server authorization and domain writes explicit instead of treating public component properties as trusted state.

Version scope: Laravel 13.x and Livewire 4.x documentation fetched 11 October 2026. These are documentation scopes, not proof of installed compatibility; inspect composer.lock, PHP version, queue/session/cache drivers and current Livewire component format before implementation.
Reviewed: 2026-10-11 | Evidence: documentation-reviewed

### Architecture boundaries

- Recommendation: keep a single domain writer and migration owner during shared-schema coexistence; let controllers, Livewire actions and queued workers call the same application operation with its authorization and transaction rules.
- Queue connections select backends while queue names select work categories. The documented choices include relational storage, Redis and SQS. Recommendation: choose a backend from recovery and operation requirements rather than assuming every Laravel application needs Redis.
- Recommendation: list HTTP PHP execution, queue workers, the scheduler and a selected broadcast server separately. Livewire component interactivity does not by itself establish multi-client event delivery; broadcasting has its own backend/client and queue configuration.

### Tools and feedback

- In a configured local Laravel project, php artisan make:livewire post.create creates a Livewire 4 component; --class retains the established class-based style and --mfc creates a multi-file component. Inspect existing conventions before choosing a format.
- php artisan make:job ProcessPodcast creates a queued job. Configure the selected connection and run php artisan queue:work --queue=high,default only after those queues and priorities match the application; supervise the production worker separately.
- php artisan migrate applies reviewed migrations. For missing database session/queue tables, the selected-version docs provide php artisan make:session-table and php artisan make:queue-table; check existing migrations first to avoid duplicate tables.
- Recommendation: verify behavior with real driver instances in a disposable environment, including timeout/retry interaction, denied Livewire actions, concurrent session writes and private broadcast authorization. Faking queue submission alone cannot exercise worker serialization or crash recovery.

### Translations to avoid

- Avoid switching queue consumers solely because both use Redis: Laravel payloads and Eloquent identifier rehydration are framework execution contracts. Recommendation: preserve old consumers or translate deliberately versioned payloads.
- Avoid worker timeout values longer than retry_after; Laravel warns this can allow the job to be processed twice. Avoid assuming unique-job locks make external effects exactly once; recommendation: use business idempotency.
- Avoid calling onOneServer a cross-stack scheduler lock. It uses a shared supported Laravel cache store; recommendation: explicitly retire the old scheduler for the transferred business category.
- Avoid trusting client-editable Livewire properties or hidden buttons for authorization. Avoid Cache::flush on a backend shared with other applications; the documented flush ignores the configured prefix.

### Architecture sources

- [Laravel 13 Database Migrations](https://laravel.com/docs/13.x/migrations): Schema migration and rollback commands.
- [Laravel 13 Queues](https://laravel.com/docs/13.x/queues): Connections versus queues, model serialization, after-commit dispatch, workers and timeout/retry_after interaction.
- [Laravel 13 HTTP Session](https://laravel.com/docs/13.x/session): Database session default, driver/table prerequisites and session-blocking requirements.
- [Laravel 13 Authentication](https://laravel.com/docs/13.x/authentication): Guard/provider architecture, sessions, logout and authentication configuration.
- [Laravel 13 Broadcasting](https://laravel.com/docs/13.x/broadcasting): Broadcast drivers, ShouldBroadcast/queue execution, private authorization and after-commit dispatch.
- [Laravel 13 Cache](https://laravel.com/docs/13.x/cache): Backend capabilities, atomic lock prerequisites and prefix-independent cache flush.
- [Laravel 13 Scheduling](https://laravel.com/docs/13.x/scheduling): Scheduler operation, timezones, overlap prevention and shared-store onOneServer locking.
- [Livewire 4 Components](https://livewire.laravel.com/docs/4.x/components): PHP/Blade components and make:livewire format options.
- [Livewire 4 Security](https://livewire.laravel.com/docs/4.x/security): Client-controlled properties/actions require validation and authorization.

## Transition options

Proposed designs and checks; these are not executed compatibility results.

### Data and schema

**Inspect the source:** Inventory table identifiers, casts/nullability, timestamps, constraints and side effects currently attached to writes. Migrations evolve the schema; Eloquent models do not automatically reproduce another runtime’s callbacks.

**During coexistence:** Recommendation: keep the existing writer authoritative, add compatible fields and move one domain operation at a time. Let one named migration runner own shared tables and keep old readers functional during the rollback window.

**Target design:** Laravel database migrations and the selected PostgreSQL schema, with application operations reused by controllers/Livewire/workers. Recommendation: delay destructive schema contraction until all old readers retire.

**Rollback:** Recommendation: restore the old writer before contracting fields; preserve additive schema and reconcile writes accepted by Laravel.

**Benefits and prerequisites**

- Recommendation: conventional schema and application ownership can make changes reviewable in one maintained application. Requires: Explicit writer transfer, tested value mappings and a single schema owner. Tradeoffs: Both runtimes remain constrained by the shared schema; reversal does not recreate deleted business data.

**Checks before transfer**

- Create and update a representative fixture through both allowed paths; compare IDs, nulls, timezone handling and unique/foreign-key failures.
- Apply the reviewed migration to a disposable restored copy and confirm both deployed versions still understand new writes.

- https://laravel.com/docs/13.x/migrations

### Jobs and schedules

**Inspect the source:** Record connection, queue, PHP job class, serialized model identifiers/relationships, timeout, retry_after, failures and delayed/running work. Model arguments may be re-fetched when the worker executes.

**During coexistence:** Recommendation: keep old consumers for old payloads; route new categories to isolated Laravel queues. Transfer producers and each schedule owner together. Account for ready, delayed, failed, retry and in-flight work before retiring the old backend.

**Target design:** ShouldQueue jobs on an intentionally selected database/Redis/SQS connection, with supervised workers and explicit attempts/timeouts. after_commit or afterCommit delays dispatch until commit; recommendation: use a durable outbox for a required recoverable commit-to-broker handoff.

**Rollback:** Recommendation: stop the new producer, keep consumers for accepted payload versions and reconcile external effects before restoring old queue routing.

**Benefits and prerequisites**

- Recommendation: a job category can move without rebuilding the entire backlog. Requires: Versioned payload fixtures, isolated queues and retained old consumers. Tradeoffs: Two queue systems may remain temporarily; serialized framework objects are not a portable cross-runtime API.

**Checks before transfer**

- Enqueue a model, alter/delete it before execution and verify the intended rehydration/failure behavior.
- Roll back the domain transaction and verify after-commit dispatch produces no job; kill after an external effect and prove retry cannot duplicate the business effect.
- Set worker timeout below the applicable retry/visibility boundary and verify a long job cannot have two concurrent effects.

- https://laravel.com/docs/13.x/queues

### Identity and authorization

**Inspect the source:** Capture guard/provider, account mapping, session driver, cookie/encryption configuration, remember-me behavior, expiry and logout. The current docs default to database sessions; the application may use another driver.

**During coexistence:** Recommendation: retain a named identity authority or qualified session exchange; share cookies only after full-format fixtures pass. Map old per-resource permissions into every Livewire/server action and keep concurrent session semantics explicit.

**Target design:** Laravel authentication guard/provider plus a selected session store and resource authorization. Session blocking needs a supported atomic-lock cache driver and is unavailable with cookie sessions.

**Rollback:** Recommendation: retain old session/exchange support until the cohort can return, while preserving every revocation and account mapping.

**Benefits and prerequisites**

- Recommendation: explicit session/account ownership can preserve user continuity during feature migration. Requires: Qualified identity/session mapping and common revocation rules. Tradeoffs: Lock-capable session coordination adds a store dependency; a shared database alone does not prove cookie compatibility.

**Checks before transfer**

- Login through the old application, access the Laravel feature and revoke/logout; both paths must deny future operations.
- Run concurrent requests that modify one session and verify required data is not lost.
- Modify a Livewire public identifier to another tenant’s record and directly invoke the action; the server must reject it.

- https://laravel.com/docs/13.x/authentication
- https://laravel.com/docs/13.x/session
- https://livewire.laravel.com/docs/4.x/security

### Realtime transport

**Inspect the source:** Capture client protocol, event name/payload, private/presence channel identity, authorization endpoint and queue connection. ShouldBroadcast dispatches broadcast work; event production and broadcast execution are separate concerns.

**During coexistence:** Recommendation: retain the old endpoint for old clients and bridge versioned domain events to the selected Laravel broadcaster. Route a stable room/user cohort including reconnects; designate one publisher per committed domain change.

**Target design:** Laravel broadcasting with an explicitly chosen supported driver and client integration, plus working queue workers when required. Defer transactional events until commit with the documented mechanism; recommendation: persist domain state for reconnect recovery.

**Rollback:** Recommendation: preserve old event names/endpoints and stop new publication before restoring the old publisher; reconcile already-visible state.

**Benefits and prerequisites**

- Recommendation: backend events can update multiple authorized clients. Requires: Configured broadcaster, workers and matching event/client contracts. Tradeoffs: Livewire alone does not remove those operational pieces; changing the broadcaster protocol may require a bridge or client rollout.

**Checks before transfer**

- Put clients on separate server instances and verify one committed event reaches all authorized recipients.
- Rollback the domain write and confirm no premature broadcast occurs.
- Revoke private-channel access, disconnect/reconnect and verify unauthorized delivery fails and the UI catches up from source state.

- https://laravel.com/docs/13.x/broadcasting
- https://laravel.com/docs/13.x/queues

### Caching and shared state

**Inspect the source:** Inventory cached values, serialization, TTLs and invalidation separately from locks, unique jobs, scheduler coordination and sessions. Laravel supports several cache stores with different capabilities.

**During coexistence:** Recommendation: version namespaces for changed representations and keep coordination on the same qualified central store. Move reconstructible values separately; never globally flush a shared backend during cutover.

**Target design:** Selected Laravel cache driver for disposable cached data; a supported central store for atomic locks across servers. Recommendation: use explicit dedicated stores/namespaces for distinct ownership boundaries.

**Rollback:** Recommendation: restore previous cache routing and rebuild from domain data; preserve lock/session store ownership until a separate qualified transition.

**Benefits and prerequisites**

- Recommendation: a cache backend can change independently of domain storage when contents are reconstructible. Requires: Verified invalidation, serialization and coordination inventory. Tradeoffs: Lock owners and dependent scheduler/session features may still prevent retiring the old backend.

**Checks before transfer**

- Warm both application versions, update authoritative data and verify both observe the required invalidation/TTL rule.
- Contend for a lock from two servers; only the intended owner may act.
- Clear only the migration’s disposable cache and verify other applications and coordination keys survive.

- https://laravel.com/docs/13.x/cache

### Delivery and recovery

**Inspect the source:** List scheduler definitions, timezones, overlapping task prevention, worker lifecycle and cache-backed coordination. Laravel schedules and old cron/Celery/Rails schedules may describe the same business action.

**During coexistence:** Recommendation: give each scheduled action one logical owner. Transfer it at an explicit boundary; Laravel onOneServer coordinates Laravel instances using a shared supported store and does not retire an external scheduler.

**Target design:** A documented Laravel scheduler invocation and supervised queue workers. Use withoutOverlapping/onOneServer only with their selected store and intended lock scope; recommendation: document missed-run and business idempotency policies separately.

**Rollback:** Recommendation: stop the Laravel schedule before restoring the old owner; reconcile accepted jobs and completed effects before replay.

**Benefits and prerequisites**

- Recommendation: explicit schedule and worker ownership can prevent accidental duplicate production during rollout. Requires: Schedule inventory, shared supported locking when needed and a coordinated old-scheduler retirement. Tradeoffs: A lock prevents concurrent starts within its scope, not every replayed business effect; coexistence still needs two operational inventories.

**Checks before transfer**

- Run the scheduled fixture across two Laravel servers and verify one enqueue, then confirm the old scheduler stays disabled for that category.
- Exercise timezone and long-running/overlap cases; restart the worker and scheduler and verify intended missed-run behavior.

- https://laravel.com/docs/13.x/scheduling
- https://laravel.com/docs/13.x/queues

Rewrite workflow: /rewrite/guide.md
Shared contracts and phases: /rewrite/contracts.json


## Setup
1. Start in a local development workspace with a supported PHP/Composer runtime, PostgreSQL, Node/npm and Git. Resolve actual package compatibility; Boost minimums do not define Laravel minimums.
2. Install installer if needed with composer global require laravel/installer; run laravel new product and choose Livewire, PostgreSQL and the desired test runner; enter product.
3. Configure .env database/mail/queue settings and confirm application key generation; do not commit secrets. Run php artisan migrate against the intended development database.
4. Run npm install then npm run build; run composer run dev. Configure a supervised queue worker and scheduler separately for production.
5. Add composer require laravel/boost --dev; inspect installed boost:install help and configure the selected integration. Honor generated guidance unless the repository explicitly chooses README-only instructions; inspect available installer options or configure MCP manually for that policy.
6. Add compatible Larastan as a dev dependency and configure phpstan.neon using its guide. For browser tests add laravel/dusk as a dev dependency then run php artisan dusk:install.
7. Prepare an authorized release: install locked production dependencies, build assets, review migrations, run php artisan optimize, and reload supervised services. Confirm backup/restore and rollback compatibility before production migration.

## Verification
Commands below require the selected tools and project configuration. Replace example paths, schemes and IDs; distinguish tests from builds and interactive startup. These are instructions, not recorded passes.

```text
php --version
composer check-platform-reqs
php artisan about
php artisan migrate:status
php artisan test
php artisan dusk
vendor/bin/pint --test
vendor/bin/phpstan analyse
composer audit
npm run build
```

## Open questions
- Which starter-kit features and paid UI components are actually required?
- Which identity and per-resource authorization policies must be supported?
- Which host, mail/storage providers, realtime capacity and worker/scheduler operation will own production?

## Sources
- [Laravel Starter Kits](https://laravel.com/framework/docs/13.x/starter-kits)
- [Flux Pricing and Component Tiers](https://fluxui.dev/pricing)
- [Laravel Database: Getting Started](https://laravel.com/framework/docs/13.x/database)
- [Laravel Database Migrations](https://laravel.com/framework/docs/13.x/migrations)
- [Laravel Authorization](https://laravel.com/framework/docs/13.x/authorization)
- [Laravel Queues](https://laravel.com/framework/docs/13.x/queues)
- [Laravel Horizon](https://laravel.com/framework/docs/13.x/horizon)
- [Testing Applications](https://laravel.com/framework/docs/13.x/testing)
- [Laravel Dusk](https://laravel.com/framework/docs/13.x/dusk)
- [Laravel Pint](https://laravel.com/framework/docs/13.x/pint)
- [Larastan README](https://github.com/larastan/larastan)
- [Composer CLI: Audit](https://getcomposer.org/doc/03-cli.md#audit)
- [Laravel Deployment](https://laravel.com/framework/docs/13.x/deployment)
- [AI Assisted Development](https://laravel.com/framework/docs/13.x/ai)
- [Laravel Framework MIT License](https://github.com/laravel/framework/blob/13.x/LICENSE.md)
- [Laravel Mail](https://laravel.com/framework/docs/13.x/mail)
- [Laravel file storage](https://laravel.com/framework/docs/13.x/filesystem)
- [Laravel broadcasting](https://laravel.com/framework/docs/13.x/broadcasting)

Keep the project README current and link the selected guidance; preserve existing project instructions.