Laravel + Livewire
PHP product applications with a cohesive UI, auth and queue toolset.
Laravel · Livewire · Blade · PostgreSQL
Complete guide (Markdown) · Structured record (JSON)
Original source review: 2026-10-10. Core guidance rechecked: 2026-10-13. Check scope. 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.
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.
Authentication: Starter-kit Fortify auth
Existing authentication flow plus resource-level authorization.
Policies remain application work; managed identity adds external terms/cost.
Authorization: Laravel policies and gates
Existing authentication flow plus resource-level authorization.
Policies remain application work; managed identity adds external terms/cost.
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.
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.
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.
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.
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.
Licensing and hosting: Laravel framework MIT; self-hostable
Framework use does not mandate a hosting subscription.
Check each optional asset/package/service license separately.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
- Flux Pricing and Component Tiers
- Laravel Database: Getting Started
- Laravel Database Migrations
- Laravel Authorization
- Laravel Queues
- Laravel Horizon
- Testing Applications
- Laravel Dusk
- Laravel Pint
- Larastan README
- Composer CLI: Audit
- Laravel Deployment
- AI Assisted Development
- Laravel Framework MIT License
- Laravel Mail
- Laravel file storage
- Laravel broadcasting