Statamic Meilisearch Laravel Package

Technical Evaluation

Architecture fit. statamic-rad-pack/meilisearch is a Statamic addon distributed as a Composer package; it plugs into Statamic's search abstraction and ships a service provider plus publishable config, so it sits cleanly inside a standard Laravel application without introducing a new runtime, sidecar, or build step. The architectural cost is concentrated in one place: Meilisearch becomes a stateful dependency that must be provisioned, secured, backed up, and kept in sync with content. That is a well-understood trade for teams that have outgrown Statamic's built-in local driver, but it is a genuine expansion of the operational footprint, not a library-only addition.

Integration feasibility. Low-to-moderate. Installation is a composer require plus config publish and a search-driver entry; the real work is index design (which collections, which fields, which fields are searchable/filterable/sortable), and a backfill of existing content. v4.1.0 is a narrow release — a single change adding Laravel 13 support — which strongly implies a constraint-widening in composer.json rather than behavioural change. Absent the diff I cannot confirm whether code changes accompanied it, so treat that as an assumption to verify.

Technical risk.

• Framework-version adjacency. Laravel 13 support is only useful if the surrounding stack supports it. Statamic core, other addons, and any custom search extensions must all be Laravel 13-compatible; adopting the addon ahead of the rest of the stack delivers no benefit and adds risk.
• Support-matrix ambiguity. A "supports Laravel 13" line does not state whether Laravel 11/12 remain supported, whether the PHP floor moved, or whether Laravel 13 support arrived with deprecations. Downstream, this determines whether the upgrade is a no-op patch or a forced migration.
• Ecosystem lag. New Laravel majors typically see a tail of addons that lag by weeks. If this package is the first Laravel 13-ready dependency in the tree, it becomes the constraint that blocks or unblocks the whole upgrade.
• Search is user-facing. Indexing bugs surface as empty results or stale content rather than exceptions, which makes them easy to ship and hard to detect.
• Maintainership. Single-maintainer addon under the rad-pack umbrella; bus factor and release cadence should be weighed for anything on the critical search path.

Key questions for the maintainer / to resolve internally.

1. Does v4.1.0 change only the illuminate/* / laravel/framework constraint, or are there code changes? Is it a drop-in from v4.0.0?
2. Are Laravel 11 and 12 still supported, or is this an implicit floor raise? What is the new minimum PHP version?
3. Which Statamic major/minor is required for Laravel 13, and is that combination covered in CI?
4. Which Meilisearch server versions are tested and supported? Any index-schema or settings changes between v4.0.0 and v4.1.0?
5. Is indexing synchronous or queue-driven, and what does the package do when Meilisearch is unreachable — throw, or degrade gracefully?
6. What is the supported upgrade path and deprecation policy for v5, if one is planned?

Integration Approach

Stack fit. Assumes a Statamic site on Laravel with a reachable Meilisearch instance. The addon is the search layer only; it does not change content modelling or routing. Fit is best where search is a first-class product surface (large catalogues, faceted filtering, typo tolerance) and weakest where search is incidental — for a small site, the built-in driver remains the lower-risk choice and this package is unnecessary infrastructure.

Migration path. Two distinct paths, with very different effort:

• v4.0.0 → v4.1.0: expected to be a lockfile-level bump. Update in a branch, run the application test suite, confirm the composer constraint resolves, and verify search behaviour against a seeded index. If no Laravel 13 upgrade is in flight, this release can be deferred indefinitely without cost.
• Adopting the addon, or migrating from another driver: requires standing up Meilisearch, defining indexes and field-level searchable/filterable/sortable attributes, performing a full reindex, and validating result ordering against current behaviour. Budget for ranking-tuning iteration; this is where the schedule slips, not the install.

Compatibility. Verify three axes before merging: (a) Laravel and PHP versions of the host app versus the package constraint; (b) Statamic core version compatibility; (c) Meilisearch server version versus what the package's client expects. Record all three in the upgrade notes — future upgrades are gated on this matrix, not on the addon's own changelog.

Sequencing.

1. Read the v4.0.0→v4.1.0 diff and confirm the change is constraint-only.
2. Snapshot the current composer.lock and record the resolved dependency tree.
3. Upgrade in a branch on staging with a production-shaped index; run functional search assertions, not just unit tests.
4. Upgrade Meilisearch server and addon as separate changes — never in the same deploy.
5. Only then pursue the Laravel 13 application upgrade, using this release as an unblocker rather than a driver.
6. Production rollout behind a reversible deploy; keep the prior release deployable until search metrics are flat.

Operational Impact

Maintenance. Low code churn, non-zero infrastructure churn. The addon itself needs attention only around Laravel majors and Statamic releases; Meilisearch needs a patching cadence, version upgrades, and periodic index maintenance. Ownership should be explicit: whoever owns the Laravel upgrade cycle should also own this dependency, since the two move together.

Support. Community-maintained, GitHub-issue-based support with no vendor SLA in evidence. Acceptable for a non-critical search surface; for a revenue-critical search experience, plan for the possibility of forking or pinning and carrying patches internally, and confirm the licence terms permit that.

Scaling. The addon scales with the application tier and adds no meaningful per-request overhead beyond a network call to Meilisearch. Meilisearch itself scales independently but is operationally opinionated: index size is bounded by RAM for best performance, full reindexes are CPU- and I/O-heavy, and index growth is driven by content volume. Two practical levers: run indexing through queue workers so content saves are not blocked by index latency, and design for zero-downtime reindex (build a new index, then swap) so that schema changes and backfills do not degrade live search.

Failure modes.

• Meilisearch unavailable → search requests error or return empty. Confirm whether the package fails open or closed, and add a health check plus an alert on search error rate.
• Index drift → content published but not indexed, or deleted content still returned. Usually caused by failed queue jobs or workers not running. Needs a reconciliation job and a freshness metric.
• Full reindex timeout → large backfills exceeding job or HTTP timeouts partway through, leaving a partially populated index. Mitigate with chunked, resumable indexing.
• Upgrade-induced schema mismatch → new searchable/filterable attributes not applied to the live index after a version bump, producing silently wrong filters. Always apply settings explicitly post-upgrade rather than assuming they persist.
• Version-skew between client and server → Meilisearch API changes breaking the addon's client calls. Pin the server version and upgrade it deliberately.
• Laravel 13 partial adoption → upgrading this package while the rest of the tree lags leaves an unresolvable composer graph; the failure appears at install time, which is at least loud.

Ramp-up. Low for developers: configuration is declarative and the mental model (indexes, searchable attributes, drivers) is familiar to anyone who has used Algolia or Elasticsearch. The steeper curve is on the operations side — API keys and tenant-token scoping, snapshots and restore procedures, dump/import for environment refreshes, and index-swap mechanics. Budget roughly a day of engineering to get a first index live and validated, and a corresponding half-day of runbook writing so that a Meilisearch outage or an index drift incident is recoverable by someone who did not build the integration.

Assessment of this release. v4.1.0 is a compatibility-enablement release, not a functional one. It warrants a version bump for teams actively tracking Laravel 13, and no action at all for everyone else. It carries no migration burden and no deprecation risk on its face, but it also does not resolve the open questions above — particularly whether v4.0.0's supported matrix is preserved. Recommend adopting it opportunistically alongside other Laravel 13-ready dependencies, and treating it as a green light for the framework upgrade rather than a reason to start one.