Mellisearch Laravel Package

Technical Evaluation

Architecture fit statamic-rad-pack/meilisearch is a Statamic addon that slots into Statamic's search abstraction, registering a meilisearch driver alongside the built-in local/template drivers. It is not a general-purpose Laravel Scout driver — it is Statamic-specific. That distinction matters for positioning: this package is only viable if the content/search surface is Statamic-driven. Indexes are declared in config/statamic/search.php, populated via Statamic's search index commands, and queried through Statamic's Search::index() facade. The runtime dependency chain is therefore three-deep: our Laravel version → supported Statamic version → supported addon version. v4.1.0 extends the top of that chain (Laravel 13), but the addon cannot be adopted on Laravel 13 unless the pinned Statamic release also supports it.

Integration feasibility Low mechanical effort, moderate verification effort. Composer install, config publish, environment variables (MEILISEARCH_HOST, MEILISEARCH_KEY, index prefix), index definition, and an initial index build. The work is not the install — it is validating relevance behaviour: which fields are searchable, which are filterable/sortable, and how Statamic's field-level searchability settings map onto Meilisearch's index schema. Meilisearch's typo tolerance and ranking rules differ materially from local/template search, so result quality must be evaluated against real content before sign-off.

Technical risk

• Version-chain risk (primary). Laravel 13 support landing here is necessary but not sufficient. If the corresponding Statamic core release is not yet stable, we would be running an unsupported combination. Verify the Statamic release that ships Laravel 13 support and confirm this addon declares it as a constraint.
• Upstream velocity. Statamic majors track Laravel majors; addon majors track Statamic majors. Budget for a coordinated bump roughly annually, not opportunistically.
• External service dependency. Meilisearch becomes a hard dependency for search-backed UI. This is a new failure domain introduced into the request path.
• Maintainer concentration. A single-maintainer RAD Pack addon is a real support-surface consideration. Assess against the vendor's track record and whether a commercial support path exists.
• Minor-version safety. v4.0.0 → v4.1.0 is a semver minor with one PR. No config changes, no deprecations, no migration steps. Upgrade risk is effectively zero on the current Laravel version; the change only expands the supported matrix.

Key questions

1. Which exact Statamic version pairs with Laravel 13, and is it GA or pre-release?
2. What is the addon's PHP floor, and does it match our fleet (8.2/8.3/8.4)?
3. Which Meilisearch server versions are supported, and is Meilisearch Cloud acceptable under our data-residency posture?
4. Do we need filterable/sortable attributes beyond what Statamic's config exposes — and if so, does the addon permit index-settings customisation?
5. What is the escape hatch if we need to revert to local search under incident conditions?

Integration Approach

Stack fit Requires a Laravel + Statamic application with PHP at or above the addon's declared floor. Meilisearch runs as a separate service (self-hosted container or Meilisearch Cloud). Fit is strongest for content-heavy, read-dominant Statamic sites where search relevance is a product feature rather than a checkbox. Fit is poor for multi-tenant applications needing per-tenant search scoping, or for apps where the searchable corpus lives outside Statamic (Eloquent models), since this addon does not address that.

Migration path Two distinct paths, with different risk profiles:

• Addon upgrade (v4.0.0 → v4.1.0): trivially safe. composer update statamic-rad-pack/meilisearch. No index rebuild required, no config republish, no data migration. Ship it in the next routine dependency window.
• Net-new adoption: stage through a non-production environment first. Stand up Meilisearch, publish config, define indexes, run the initial index build, then compare result quality side-by-side against the current driver on a representative query set. Cut over behind a feature flag or environment toggle rather than a hard switch.
• Laravel 13 migration: treat as blocked until Statamic core GA on Laravel 13. Sequence as: Statamic upgrade → addon upgrade → index rebuild → smoke test.

Compatibility Composer constraints in the addon should be checked against our composer.json before any upgrade PR — specifically the illuminate/*, statamic/cms, and PHP constraints. Where constraints conflict, the resolution is to align Statamic first; the addon will follow. Keep the addon on a caret constraint (^4.1) so patch releases land automatically, and pin the Statamic minor to avoid unplanned search-abstraction changes.

Sequencing

1. Confirm Statamic/Laravel/PHP compatibility matrix and record it in the dependency register.
2. Provision Meilisearch in staging; configure indexes and searchable/filterable/sortable attributes.
3. Build index; run a relevance evaluation against a fixed query set with expected results.
4. Instrument search latency and error rate; define thresholds.
5. Roll out to production behind a toggle; monitor for one release cycle.
6. Decommission the previous driver configuration only after the soak period.

Operational Impact

Maintenance Ongoing surface is: scheduled index rebuilds (or event-driven sync), config drift between environments, and annual version-chain bumps. The index is derived state — it must be reproducible from the CMS. Establish a documented rebuild command and confirm it is idempotent. Budget a recurring line item for the Statamic/Laravel/addon triple upgrade each year, and a smaller one for Meilisearch server upgrades, which have their own breaking-change cadence (v1.x minors have historically introduced behavioural changes in ranking and settings).

Support Two support boundaries, not one: the PHP addon (vendor/maintainer) and the Meilisearch server (self-supported if self-hosted, vendor if Cloud). Incidents will not always be attributable to the right boundary quickly — build a triage runbook that distinguishes "index wrong" from "service unreachable" from "query semantics changed after upgrade". If self-hosting, the Meilisearch server is our operational responsibility; that is a meaningful on-call addition, not a footnote.

Scaling Scales well for read-heavy workloads: Meilisearch is designed for low-latency query serving and handles concurrency far beyond what a typical Statamic site generates. The scaling pressure points are elsewhere — index build time and memory during full rebuilds on large content sets, and write-path contention if content editors publish frequently. Both are addressable with incremental indexing and off-peak rebuild scheduling. Cost is driven by index size in RAM; model this early for large corpora, since Meilisearch is memory-resident.

Failure modes

• Search service unavailable: search UI degrades. Decide explicitly whether this is a hard failure (error page) or soft (fallback to local driver or empty-state with a message). Soft degradation is strongly preferred; it makes a Meilisearch outage a non-incident.
• Index drift / staleness: content published but not indexed. Mitigate with event-driven indexing plus a scheduled reconciliation rebuild, and surface index lag as a metric.
• Silent relevance regression: the highest-risk mode, because it produces no errors. Typically triggered by a Meilisearch server upgrade changing ranking rules, or by a field-level searchability config change. Guard with the pinned query-set evaluation as a post-deploy check.
• Partial rebuild interruption: a failed rebuild leaving a half-populated index. Prefer blue/green index swaps or a full-rebuild-then-swap pattern.
• Configuration divergence: staging and production pointing at different indexes or using different settings. Keep index settings in version control, not in the Meilisearch dashboard.

Ramp-up Low for a Laravel developer already familiar with Statamic — the integration is config plus a command, achievable in under a day. The real ramp is conceptual: understanding Meilisearch's ranking rules, typo tolerance, and the searchable/filterable/sortable distinction, and knowing how those interact with Statamic's field configuration. Allocate evaluation time for whoever owns search relevance, not just implementation time for whoever wires it up. For teams new to both Statamic search and Meilisearch, assume two to three days to a confident first production cutover including relevance tuning.