Using Livewire and Inertia in the Same Laravel App

Developers can build some pages in a Laravel product with Livewire and others with Inertia. Livewire lets them build interactive components with PHP and Blade, Laravel’s templating language. Inertia connects Laravel routes and controllers to page components written in JavaScript frameworks such as React, Vue, or Svelte. Both use Laravel on the server, but they build page interfaces in different ways.

Give each stack its own routes or product areas, and use Laravel to share business rules. For example, Livewire can handle administrative forms while Inertia powers a customer-facing area with richer JavaScript interactions. Laravel’s starter kits present the two as distinct starting choices. Using both is an architectural choice; Laravel does not document a one-click integration recipe.

Livewire and Inertia handle page updates differently

A Livewire page renders Blade components on the server. When a user interacts with a component, Livewire sends Laravel an update request. Laravel runs the component logic and returns updated content. This approach suits forms, tables, and other interactions that PHP and Blade handle on the server. Laravel describes its Livewire starter kit as an option for developers who primarily use Blade.

With Inertia, Laravel handles routes, controllers, middleware, and data fetching, while a JavaScript framework renders the page component. An Inertia response names that component and supplies the data it needs. Inertia calls this data props. By default, Inertia connects Laravel to JavaScript pages without a separate frontend application and API. Its overview describes how the server and client work together.

Give each route one page model to own it. Before putting a Livewire component inside an Inertia page, or an Inertia page inside a Blade layout, check the exact package versions and setup. The documentation does not establish either arrangement as a standard integration pattern.

Give each stack its own routes

Choose a stack for each product area instead of making every page work the same way. Livewire can suit an internal admin area with searchable tables and edit forms. Inertia can suit a customer workspace that uses a JavaScript component library or richer interactions in the browser.

Give each URL to one stack. For example, Laravel routes for /admin pages can return Livewire components, while routes for /workspace pages can return Inertia pages. Routes can use different paths, but developers need to know which stack handles each route and where its layout and frontend code live.

Plan how users move between the areas. Start by testing a regular link that loads a new page. Check how the actual routes handle sign-in redirects, validation errors, browser back and forward navigation, and shared layouts. Livewire’s wire:navigate provides SPA-like navigation within Livewire pages. Its navigation documentation does not describe it as a way to move between Livewire and Inertia pages.

Share Laravel rules, not assumptions about UI state

Have both stacks use the same Laravel business rules to create an order or change an account setting. Put the rules in a service or action, then call them from each route or component. This keeps the behavior consistent when both interfaces offer the same operation.

Laravel policies determine whether a user may perform an operation. Check authorization on the server each time the operation runs. In Livewire, client requests supply public properties and action parameters. Treat those values as untrusted: validate them and authorize changes before writing to the database. Livewire’s security guidance explains these risks. Inertia can share authorization information with pages, allowing the interface to hide or show controls. That display logic does not replace server-side authorization.

Protect authentication and tenant boundaries on both the initial page request and later component or update requests. Inertia’s Laravel setup uses HandleInertiaRequests middleware for tasks such as sharing data with pages. Livewire documents its separate update endpoint and middleware options in its installation guidance. Check how these features work with the Laravel and package versions installed in the project.

Keep frontend assets and lifecycles deliberate

Set up the frontend for each stack. Inertia starts JavaScript and finds page components, as described in its client-side setup. Livewire 3 can inject its frontend assets and bundles Alpine, a small JavaScript framework for browser interactions. Do not load multiple Alpine instances on pages that use Livewire. Livewire’s installation documentation warns that duplicate instances cause problems.

A shared Vite build may suit the project. Decide which scripts and styles each page loads instead of assuming one asset layout fits every route. Also account for Livewire navigation: with wire:navigate, DOMContentLoaded does not fire on every visit, and scripts in the document head generally run only on the first page load. Code that relies on these events needs to follow Livewire’s documented lifecycle.

Use both when each has a clear job

Use Livewire when PHP and Blade make a page straightforward to build. Use Inertia when a page benefits from React, Vue, or Svelte while keeping Laravel’s routing and backend conventions. Use both when different areas have distinct needs and those benefits justify maintaining two component models and frontend lifecycles.

If developers use both stacks to build the same kinds of forms and interactions, maintaining the boundary adds overhead without a clear product benefit. Laravel and the package documentation describe each stack separately; they do not provide a universal recipe for using both. Test the route split and navigation in the project. Check the middleware and asset setup there too. The documentation does not guarantee that these choices will work together.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com