Meilisearch Laravel Package

Technical Evaluation

Package: statamic-rad-pack/meilisearch — a Meilisearch search driver for Statamic's search abstraction layer. Release under review: v4.1.0 (minor). Sole change: Laravel 13 compatibility (PR #49).

Architecture fit. This is a thin adapter, not a framework. It plugs into Statamic's existing Search driver contract, so the integration surface is a service provider, a config block, and an indexer. That is a favourable shape for us: the coupling is to Statamic's search interface (stable, documented) rather than to internals, and the driver is swappable at the config level. If we already run Statamic, the architectural decision is really "do we want a hosted/external search engine" — this package is the cheap part of that decision, not the expensive part.

Integration feasibility. Low effort. Composer install, config publish, env credentials, index build via Statamic's CLI. No schema migrations in our database, no changes to content models. The real work is standing up and operating a Meilisearch instance, plus deciding index granularity (per-site, per-collection) and rebuild cadence.

Technical risk.

• Ecosystem timing (primary risk). Supporting Laravel 13 is table stakes for the package, but it only matters if Statamic core, our other addons, and our hosting runtime are also Laravel 13-ready. A driver being early does not make the platform early. Adopting this release as a reason to move to Laravel 13 would be inverting the dependency.
• Maintainer concentration. Single-maintainer community addon (Duncan McClean / Rad Pack). Well-regarded in the Statamic ecosystem, but bus-factor is 1 and there is no commercial support contract. Acceptable for search; not acceptable for anything on the critical write path.
• Version-skew risk. The package pins Meilisearch client versions; server-side Meilisearch has its own release cadence and occasional breaking changes. Compatibility is three-way: Statamic ↔ package ↔ Meilisearch server.
• Minor-version semantics. v4.0.0 → v4.1.0 with a single additive compatibility change is a clean, low-risk signal. No deprecations, no config changes, no migration. This is the cheapest possible release to consume.

Key questions.

1. Is Statamic core (our pinned version) actually Laravel 13-compatible today, or does this release run ahead of the platform?
2. What is the minimum supported Meilisearch server version, and does it match what our platform team will operate?
3. What is the documented fallback when Meilisearch is unreachable — does Statamic degrade to the local driver, return empty results, or throw?
4. Do we need external search at all, or does Statamic's built-in driver meet our relevance and latency requirements at current content volume?
5. Who owns index rebuilds and relevance tuning after launch — application team or platform?
6. Is there a paid support or sponsorship path with the maintainer, and do we need one?

Integration Approach

Stack fit. Clean, provided we are on Statamic 4/5+ and a Laravel version the package supports. The driver is declarative: register the driver in config/search.php, point it at Meilisearch, run the index command. Nothing about our application code changes — search calls stay behind Statamic's facade. That containment is the main reason this is a low-blast-radius integration.

Migration path. Recommended sequence, independent of the Laravel 13 headline:

1. Stand up Meilisearch in a non-production environment (container is sufficient for evaluation).
2. Install the package at the current v4 line, publish config, point at the dev instance.
3. Rebuild indexes from existing content; benchmark recall and latency against the current driver on a representative content sample.
4. Run both drivers in parallel in staging; switch config/search.php per environment rather than per code branch, so rollback is a config change and a redeploy — not a revert.
5. Promote to production with the old driver config retained and documented as the rollback lever.

Compatibility. Treat the matrix as a gate, not a formality:

Sequencing. Because v4.1.0 is additive and carries no breaking changes, it should not be sequenced as a project. Fold it into the next routine dependency bump if and only if the Laravel 13 upgrade is already in flight; otherwise defer. Do not let a search driver's release note drive a framework upgrade.

Operational Impact

Maintenance. Low but non-zero. The package itself is small and changes rarely — a handful of releases per year. Ongoing work is dominated by the service, not the code: Meilisearch upgrades, index schema changes when content models change, and periodic relevance tuning. Budget for that explicitly; teams routinely underestimate it.

Support. Community-only. Realistic posture: acceptable risk for a read-path search feature with a working fallback; not acceptable if search is a revenue-critical path (e.g. product discovery). If it is revenue-critical, either buy support upstream via sponsorship or accept that our own team owns the fork.

Scaling. The driver is not the constraint — Meilisearch is. Scaling questions belong to the search engine: index size, memory footprint, replica count, and rebuild throughput. Full reindexes on large content sets are the usual pain point; plan for incremental indexing and off-peak rebuild windows from day one. The adapter adds negligible overhead.

Failure modes. Enumerate and design for these before launch:

• Search backend unavailable → does the page 500, render empty results, or fall back? Decide and test. Silent empty results are worse than a visible degraded state.
• Index drift → content changed but index did not (failed webhook/job). Needs a freshness check and a scheduled reconciliation.
• Credential rotation → search-only vs admin keys; admin keys must never ship to app servers if the app only queries.
• Version skew after an upgrade → a Meilisearch server upgrade breaking the client contract mid-week. Mitigate with pinned images and a staging triad test.
• Rebuild contention → reindex load starving query latency; isolate or throttle.

Ramp-up. A developer can be productive in an afternoon — install, config, index, query. The slower ramp is operational literacy: how Meilisearch indexes and ranks, what the settings knobs do, and how to diagnose "why is this result missing." Assign one named owner for search quality rather than distributing it; search tuning degrades badly when nobody owns relevance.

Recommendation. Adopt v4.1.0 only as a rider on an already-planned Laravel 13 upgrade; otherwise hold at v4.0.x with no functional loss. The release itself is low risk and requires no assessment change beyond the compatibility note. Proceed with the package for search, contingent on (a) a confirmed fallback behaviour, (b) a pinned and tested three-way version matrix, and (c) a named operational owner.