mattbromley/inertia-statamic
Inertia.js adapter for Statamic that lets you build Vue or React frontends on top of Statamic content. Share CMS data as Inertia props, render entries and pages through Inertia responses, and keep the smooth SPA experience while authoring in Statamic.
Architecture fit. The package sits at the intersection of three moving parts: Statamic's content/routing layer, Laravel's HTTP kernel, and Inertia.js's server-side adapter (inertiajs/inertia-laravel). The adapter's job is to resolve Statamic routes (collections, taxonomies, globals, custom routes) into Inertia responses with serialized props, so that a Vue/React/Svelte front end renders the page instead of Antlers. Architecturally this is a clean, well-understood pattern — it is essentially the standard Inertia "monolithic SPA" model with Statamic as the content source rather than a headless API. For a Laravel-native team already using Inertia (Breeze, Jetstream, or an existing Inertia app), the conceptual fit is strong; there is no new runtime, no separate API contract, and no additional service to deploy.
The trade-off is that you are swapping Statamic's Antlers rendering pipeline for component-based rendering. Anything that depends on Antlers rendering — tag-based templating, addon-provided tags, Live Preview HTML injection, and some form/search addons — no longer works out of the box and must be reimplemented in JavaScript against Statamic's content API. That is a real architectural commitment, not a drop-in.
Integration feasibility. Feasible but not turnkey. Installation is Composer-based and the surface area is likely small (a service provider, a response/middleware class, and configuration). The practical work is in wiring: configuring which routes are Inertia-managed, ensuring Statamic's route cache and static cache don't conflict with Inertia's asset versioning, and reimplementing any Antlers-dependent behaviour as page props. A PoC on a single collection route should take days, not weeks; a full site migration is a multi-sprint effort driven by template rewriting, not by the adapter itself.
Technical risk. High, and almost entirely supply-chain rather than technical:
Key questions.
Stack fit. Best fit is a Laravel + Statamic + Inertia + Vue/React team, ideally already running Inertia somewhere in the application (auth screens, dashboards). In that case the adapter extends an existing mental model rather than introducing a new one, and the Statamic Control Panel continues to run untouched as the editorial surface. Poor fit for teams with heavy Antlers investment, a large addon estate that renders server-side, or a strong preference for Statamic's static-cached, CDN-first delivery model — Inertia's initial HTML payload and prop serialization make aggressive static caching harder to reason about.
Migration path. Do not retrofit an existing Antlers site wholesale. Recommended path:
<head> handling.Compatibility. Pin everything: Composer lock for the adapter, Statamic, Laravel, and inertia-laravel; lock the npm side for @inertiajs/vue3/react and your bundler. Explicitly define the Node runtime for asset builds and, if used, Inertia SSR. Verify PHP version support against your hosting target. Because there is a single release, treat the pinned commit as the contract and diff any upgrade deliberately.
Sequencing. (1) Fork/upstream diff and code review — one to two days. (2) PoC on a scratch route — about a week. (3) Version pinning and CI harness with E2E smoke tests. (4) Pilot section in production behind a route-level flag. (5) Addon/feature gap closure. (6) Full rollout. Budget the majority of effort in steps 4–5; the adapter itself is a small fraction of the work.
Maintenance. This is the dominant cost. Expect to own the package rather than consume it: subscribe to both this repository and the upstream, review diffs on every Statamic/Inertia upgrade, and be prepared to patch locally. Realistically allocate a small but recurring engineering budget (a few days per quarter) plus a larger spike whenever Statamic ships a major. If the team cannot commit to that, do not adopt.
Support. No vendor, no SLA, no documented support channel from the package itself. Recourse is GitHub issues on a 4-star repo, the Statamic Discord/Discussions, and reading the source. Internal documentation, a runbook, and a named owner are mandatory. The MIT license gives you the right to fork and fix — plan on exercising it.
Scaling. Inertia does not add a runtime service in the default (non-SSR) mode, so horizontal scaling is the same as any Laravel app: stateless PHP workers behind a load balancer. Watch two things: (1) prop payload size — serializing large content trees (nav trees, related entries, taxonomy terms) on every request is easy to do accidentally and inflates response size and memory; measure and cache aggressively. (2) Static caching and CDN behaviour — Statamic's static cache writes full HTML documents, and Inertia's initial page load embeds a data-page JSON blob. That can work, but invalidation and per-user variation (editors vs. anonymous) must be designed explicitly, or you risk serving editor-context pages from cache. If you enable Inertia SSR, you add a Node process to the deployment topology and must handle its failure and version-skew modes.
Failure modes.
Ramp-up. Two mental models must be learned together: Statamic's content/routing conventions and Inertia's page/prop lifecycle. A Laravel developer familiar with Inertia ramps in days; a Statamic/Antlers developer moving to component rendering needs weeks, and the content team needs retraining on preview and editing workflows. Budget for internal documentation and a reference page that demonstrates props, routing, and Head/SEO handling, since third-party tutorials for this specific adapter are essentially nonexistent.
How can I help you explore Laravel packages today?