Runway Laravel Package

Technical Evaluation

Architecture fit. Runway is a Statamic addon that maps Eloquent models to Statamic "resources," letting database tables be edited in the Control Panel and queried through Antlers/Blade and GraphQL like native collections. For an org already on Statamic, this is the canonical way to avoid duplicating data between flat-file content and an application database. It is config-driven and does not fork core, so the coupling is to Statamic's public extension points rather than to internals.

Integration feasibility. Standard Composer install with auto-discovered service provider, published config, and per-resource blueprints. v9.7.0 adds two capabilities that reduce custom code: (1) orderable resources, which removes the need for hand-rolled drag-and-drop sorting controllers for any model with an order column, and (2) a config switch to disable static cache warming of Runway URIs, which matters for sites where the URI surface is large or where warming is redundant with an existing invalidation strategy. The nested-JSON fix in title_field/title_format closes a real correctness gap in how resources are labeled in the CP and in listings.

Technical risk. Moderate-low. The package tracks Statamic major versions and this is a minor release within the v9 line — no breaking changes or deprecations are signaled. The residual risks are structural rather than release-specific: schema drift (renaming a column or table silently breaks a resource mapping), behavior coupling to Statamic majors, permission/authorization mapping to Laravel policies, multi-site/localization semantics, and the cost characteristics of cache warming on large URI sets. The existence of the cache-warming opt-out is itself an admission that the default is not universally safe, so it should be evaluated, not assumed.

Key questions.

• Which Statamic major and Laravel/PHP versions does v9.7.0 require, and what is the published policy for the next Statamic major?
• Is the cache-warming flag opt-in or opt-out by default, and if disabled, what replaces it for invalidation correctness?
• Does orderable support require a schema change (an integer order column), and how are ties/duplicates and reordering writes handled?
• How are nested JSON title fields stored and indexed, and does the fix in #844 change rendered output for existing resources?
• What is the release cadence, maintainer depth, and commercial support/sponsorship option for business-critical reliance?
• How are resource permissions expressed — Statamic roles, Laravel policies, or both?

Integration Approach

Stack fit. Assumes a Laravel + Statamic application (PHP 8.2+, current Laravel LTS). Runs alongside existing collections and entries without conflict; resources are additive.

Migration path. Adopt incrementally rather than as a big-bang. Start with one read-mostly table that currently has an awkward admin story, ship it as a single resource, and only then expand. For orderable resources, add the order column and backfill in the same migration, then enable ordering per resource. For cache warming, set the new flag per environment — leave warming on in staging to observe cost, evaluate turning it off in production only after confirming an alternate invalidation path.

Compatibility. Pin the addon to the same Statamic major as the application and verify Laravel/PHP constraints at lockfile time. Treat the #844 nested-JSON fix as a behavior change for verification purposes even though it is labeled a fix: any resource whose title_field or title_format uses dot notation should be re-checked in the CP, in listings, and in any template that renders the title.

Sequencing.

1. Upgrade the addon in staging and run the existing test suite plus a CP smoke pass.
2. Verify blueprints, routes, and GraphQL schemas still resolve.
3. Explicitly re-test resources with nested JSON title fields against expected output.
4. Enable orderable resources for a single low-risk resource; confirm writes, ties, and reorder persistence.
5. Tune the cache-warming flag per environment with before/after measurements of deploy time and cache hit behavior.
6. Roll to production behind the normal release process.

Operational Impact

Maintenance. Active third-party addon with a steady PR cadence and a named primary maintainer. The recurring cost is not patch releases but the Statamic major upgrade treadmill — plan for a v9→v10 migration on the same horizon as the next Statamic major, and budget it explicitly rather than treating it as routine dependency hygiene.

Support. Community/GitHub-issue driven. If any resource becomes business-critical (pricing, inventory, customer-facing data), evaluate sponsorship or a commercial support arrangement, and ensure at least two internal engineers can operate the package.

Scaling. Database-backed resources generally scale better than flat-file content for large or frequently-updated datasets, and they keep a single source of truth. Watch three things: N+1 queries in CP listings (eager-load relationships in the resource definition), the cost of static cache warming as the URI count grows, and the write amplification of drag-and-drop reordering on large tables.

Failure modes. Schema drift breaking a resource mapping after an unrelated migration; cache-warming storms or slow deploys on large URI sets; duplicate or null order values producing unstable sorting; JSON title parsing regressions resurfacing in edge cases; addon/core version skew after a Statamic upgrade; permission gaps exposing resources to roles that should not edit them.

Ramp-up. Low for Laravel developers — the mental model is "Eloquent model plus a blueprint," and a first resource is roughly a one-to-two-day task including configuration. Content editors need a short orientation on resources versus entries, since the CP surface looks similar but the underlying data behaves differently (no revisions or flat-file versioning by default). Document the config surface — especially the new cache-warming flag and the ordering convention — in the internal runbook.