# Laravel + Livewire

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

Laravel · Livewire · Blade · PostgreSQL

[Complete guide (Markdown)](/stacks/laravel-livewire-postgresql/guide.md) · [Structured record (JSON)](/stacks/laravel-livewire-postgresql/record.json)

Original source review: 2026-10-10. Core guidance rechecked: 2026-10-13. [Check scope](/research-freshness.json). Dependency combinations and setup need project-specific qualification.

## Use cases

- SaaS

- Administrative and business applications

- Server-driven interactive products

## Choose it when

- PHP team or Laravel ecosystem fit is strong.

- Integrated auth, queues and concrete agent inspection tools reduce assembly work.

## Consider another path 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.

## Working 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 by job

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

One supported starter establishes coherent UI/auth integration.

Starter includes Flux; distinguish its free components from paid Pro assets.

- [https://laravel.com/framework/docs/13.x/starter-kits](https://laravel.com/framework/docs/13.x/starter-kits)

- [https://fluxui.dev/pricing](https://fluxui.dev/pricing)

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

Conventional ORM and migrations with a production relational store.

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/database)

- [https://laravel.com/framework/docs/13.x/migrations](https://laravel.com/framework/docs/13.x/migrations)

### Authentication: Starter-kit Fortify auth

Existing authentication flow plus resource-level authorization.

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/starter-kits)

- [https://laravel.com/framework/docs/13.x/authorization](https://laravel.com/framework/docs/13.x/authorization)

### Authorization: Laravel policies and gates

Existing authentication flow plus resource-level authorization.

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/starter-kits)

- [https://laravel.com/framework/docs/13.x/authorization](https://laravel.com/framework/docs/13.x/authorization)

### Queues: Laravel database queue + supervised workers

Simple starting infrastructure with explicit scale-up options.

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/queues)

- [https://laravel.com/framework/docs/13.x/horizon](https://laravel.com/framework/docs/13.x/horizon)

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

Application and browser verification complement each other.

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/testing)

- [https://laravel.com/framework/docs/13.x/dusk](https://laravel.com/framework/docs/13.x/dusk)

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

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

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

- [https://laravel.com/framework/docs/13.x/pint](https://laravel.com/framework/docs/13.x/pint)

- [https://github.com/larastan/larastan](https://github.com/larastan/larastan)

- [https://getcomposer.org/doc/03-cli.md#audit](https://getcomposer.org/doc/03-cli.md#audit)

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

A conventional process model is a practical default.

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

- [https://laravel.com/framework/docs/13.x/deployment](https://laravel.com/framework/docs/13.x/deployment)

### Agent tooling: Laravel Boost development dependency

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

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](https://laravel.com/framework/docs/13.x/ai)

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

Framework use does not mandate a hosting subscription.

Check each optional asset/package/service license separately.

- [https://github.com/laravel/framework/blob/13.x/LICENSE.md](https://github.com/laravel/framework/blob/13.x/LICENSE.md)

- [https://fluxui.dev/pricing](https://fluxui.dev/pricing)

### Transactional email: Laravel Mail

Mailables and queue integration keep delivery in application conventions

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](https://laravel.com/framework/docs/13.x/mail)

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

Storage disks support private local or S3-backed files

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](https://laravel.com/framework/docs/13.x/filesystem)

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

Private channels integrate realtime application events

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](https://laravel.com/framework/docs/13.x/broadcasting)

Build with the stack’s strengths

## 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

### 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.

[laravel.com →](https://laravel.com/docs/13.x/migrations)
[laravel.com →](https://laravel.com/docs/13.x/queues)
[laravel.com →](https://laravel.com/docs/13.x/session)
[laravel.com →](https://laravel.com/docs/13.x/authentication)
[laravel.com →](https://laravel.com/docs/13.x/broadcasting)
[laravel.com →](https://laravel.com/docs/13.x/cache)
[laravel.com →](https://laravel.com/docs/13.x/scheduling)
[livewire.laravel.com →](https://livewire.laravel.com/docs/4.x/components)
[livewire.laravel.com →](https://livewire.laravel.com/docs/4.x/security)

For an existing application

## Keep the contracts while you change the stack.

These are documented options and proposed checks. Inspect the actual source application before adopting a transition.

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.

[laravel.com →](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.

[laravel.com →](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.

[laravel.com →](https://laravel.com/docs/13.x/authentication)
[laravel.com →](https://laravel.com/docs/13.x/session)
[livewire.laravel.com →](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.

[laravel.com →](https://laravel.com/docs/13.x/broadcasting)
[laravel.com →](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.

[laravel.com →](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.

[laravel.com →](https://laravel.com/docs/13.x/scheduling)
[laravel.com →](https://laravel.com/docs/13.x/queues)

[Read the migration workflow →](/rewrite/guide.md)

## Setup

- 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.

- 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.

- Configure .env database/mail/queue settings and confirm application key generation; do not commit secrets. Run php artisan migrate against the intended development database.

- Run npm install then npm run build; run composer run dev. Configure a supervised queue worker and scheduler separately for production.

- 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.

- 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.

- 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

Run these in the configured application; they are instructions, not recorded passes.

```
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)

---

Canonical page: https://stack.menu/stacks/laravel-livewire-postgresql/