Runway Laravel Package

Technical Evaluation

Architecture fit. Runway is a Statamic addon (Rad Pack / Duncan McClean) that surfaces Laravel Eloquent models as first-class Statamic "resources" — usable in the Control Panel, Antlers/Blade, GraphQL and REST. That is a strong architectural fit where the system of record is already a relational database and we do not want to duplicate domain data into Statamic's flat-file content layer. Existing Laravel domain models (e.g. products, venues, people) can be exposed without a bespoke CP build. The v9.7.0 additions are directionally aligned with that fit:

• Orderable resources (#854) closes a long-standing parity gap with Statamic collections — drag-and-drop ordering in the CP against an order/sort column. This materially reduces editorial custom-build effort for catalogue-style resources.
• Nested JSON fields in title_field / title_format (#844) allows display titles derived from JSON columns (e.g. localized {"en": "...", "de": "..."} payloads or EAV-style attributes). Useful, but it implicitly endorses flexible-schema storage, which carries data-quality risk.
• Disabling static cache warming of Runway URIs (#850) is an operational knob more than a feature: it decouples URI warm-up from deploy/rebuild cycles, which matters at scale.

Integration feasibility. Low-to-moderate. Standard Composer install and config publish, resource classes registered via config, and a migration for any new order column. No service rewrite required. The two new capabilities are opt-in and additive, so a brownfield integration is feasible in slices.

Technical risk.

• Major-version line. v9.x implies a Statamic/Laravel/PHP floor that must be verified against our current matrix before committing; an upgrade from an earlier Runway major is a migration project, not a patch.
• Behaviour of the cache-warming flag is unstated in these notes. If warming was previously implicit and the new option defaults to enabled, existing installs are unaffected; if it defaults to disabled, static-cache coverage silently regresses on upgrade. This must be confirmed in the config/upgrade guide, not assumed.
• Orderable resources likely require a schema change and will interact with static caching — reordering must invalidate warmed URIs, or the CP and front end will disagree.
• Nested JSON titles shift validation responsibility onto us: no schema enforcement means malformed payloads surface as blank or broken titles in the CP.
• Supply-chain. Single-maintainer addon with a small contributor base; acceptable for a commercial dependency but should be logged in the risk register with a fallback plan (direct Eloquent + custom CP screens).

Key questions.

1. What are the exact Statamic, Laravel and PHP constraints for v9.7.0, and does our stack satisfy them today?
2. Does the new cache-warming option default to current behaviour? What is the documented upgrade note?
3. Does orderable support require a migration, and what column naming/convention does it expect? Is ordering scoped per-site/per-resource?
4. How does reordering interact with static caching and with any queued/CDN purge we run?
5. Are nested JSON title fields read-time resolved only, or is there an indexing/performance cost per request?
6. Support model: community-only, or is there a commercial support path for production incidents?
7. GraphQL/REST exposure — are the new capabilities reflected in the API schema, or are they CP-only?

Integration Approach

Stack fit. Best suited to a Laravel monolith or modular monolith where Eloquent is already the system of record and Statamic supplies the CP, routing and content API. Poor fit if content is author-owned flat files with no database backing, or if the team intends to move to a headless CMS — Runway ties delivery to the Laravel runtime.

Migration path. Two distinct journeys: (a) adopting Runway — start read-only, one low-risk resource, then expand; (b) upgrading Runway — pin the current version, read the v9 upgrade guide in full, branch-upgrade in staging, and reconcile any config changes (especially the warming flag) before touching production.

Compatibility. Do not treat v9.7.0 as a drop-in without a verified matrix covering Statamic version, Laravel version, PHP version and database driver (JSON column semantics differ meaningfully between MySQL, MariaDB and Postgres — directly relevant to #844). Confirm GraphQL/REST addon compatibility if we expose Runway data through the API.

Sequencing.

1. Pin and record the current versions; obtain the official compatibility matrix.
2. Spike in a staging branch: register one existing Eloquent model as a Runway resource, read-only, no front-end routing.
3. Enable front-end routing/URIs and measure static-cache warm time with warming both on and off.
4. Add orderable support to a single resource: migration, CP ordering, cache invalidation verification.
5. Adopt nested JSON titles only where the underlying data is already validated — otherwise defer.
6. Roll out resource-by-resource with a documented rollback (feature-flag resources via config so they can be disabled without a deploy).

Operational Impact

Maintenance. Modest and mostly configuration-level, but it is a live dependency on a fast-moving major line — budget a recurring review each Statamic major. Our own surface area is resource definitions, a config file, and any migrations for ordering; that is small and reviewable.

Support. Community support via GitHub issues and the Statamic Discord; response times are not contractual. For anything business-critical, plan internal ownership: someone must be able to read the addon source and patch or fork it. Treat the maintainer as a single point of failure in the risk register.

Scaling. Runway is DB-bound, so scaling follows the database: index the columns used in title_field, ordering and route resolution; be alert to N+1 queries when listing resources in Antlers or the CP. Static cache warming of Runway URIs can become a material cost at high resource counts — the new opt-out (#850) is the primary lever, but disabling warming trades build time for first-request latency and origin load. Validate with production-scale row counts, not fixtures.

Failure modes.

• Upgrade breaks CP or front-end routing due to a Statamic version mismatch — mitigate with a pinned version and staged upgrade.
• Silent static-cache regression after enabling/disabling warming — mitigate with a post-deploy smoke check on representative URIs.
• Ordering drift between CP state and cached front end — mitigate by verifying invalidation and adding a CDN purge hook.
• Malformed JSON in title columns rendering blank titles — mitigate with validation at write time and an alert on empty-title counts.
• Database outage now surfaces as a CMS outage, not just an application outage — this is the key blast-radius change and should be reflected in the incident runbook.

Ramp-up. Low for a Laravel-fluent engineer (a day or two to a working resource); moderate for content/editorial staff who must learn a CP that behaves slightly differently from native collections (ordering, publishing, revisions semantics may not map one-to-one). Budget a short enablement session and a written "what Runway does and does not support" note for editors before the first resource ships.

Caveat: this assessment is derived from the v9.7.0 release notes only — no source review, compatibility matrix, or upgrade guide was available. The open questions above should be closed before sizing the work.