Laravel Elasticsearch Laravel Package

Product Decisions This Supports

• Search infrastructure roadmap / cluster upgrade timing. The headline change is Elasticsearch 8 support in mailerlite/laravel-elasticsearch 12.0.0. This is the decision that matters: if your platform roadmap includes an Elasticsearch 7 → 8 upgrade (or you're provisioning new clusters), this package version is what unblocks it. Without ES8-capable client support, ES8 adoption would require either a fork, swapping packages, or holding your cluster on a version that is past end-of-life.
• Build vs. buy for search. A maintained Laravel binding to the official Elasticsearch PHP client is a "buy/borrow" decision versus hand-rolling an HTTP client, index management, and query builder conventions. The ES8 bump is a signal that the maintenance burden of doing this in-house would have landed on your team right now.
• Feature bets enabled downstream. ES8 brings dense-vector/kNN search, better aggregations, and (importantly for PMs) security enabled by default. If semantic/hybrid search or per-tenant auth is on the roadmap, ES8 is a prerequisite, and this release makes it reachable from Laravel.
• Risk/roadmap hygiene. This is a major version bump (11.3.0 → 12.0.0) driven by a dependency major. Treat it as a scheduled upgrade project, not a composer update. Budget for regression testing of existing index/query code and for connection-config changes (ES8 defaults to TLS + auth, which breaks naive local/dev configs).
• Scope realism for the release itself. The remainder of the changelog is housekeeping (Renovate bot config, dependency pinning, GitHub Actions bumps). Do not plan work around it — no new product-facing features shipped here.

When to Consider This Package

Adopt when:

• You run a Laravel/PHP application and already operate (or plan to operate) an Elasticsearch 8.x cluster.
• You need first-class full-text search, filtering, aggregations, or log/analytics-style querying beyond what SQL LIKE and database full-text indexes can reasonably do.
• You want the official Elasticsearch PHP client's semantics without writing your own Laravel service provider, config, and query ergonomics.
• Your team is comfortable owning Elasticsearch operations (cluster sizing, index/mapping design, reindex/recovery, monitoring) — the package is a client binding, not a hosted search product.

Look elsewhere or re-evaluate when:

• You only need basic search. Laravel Scout with the database driver, Meilisearch, or Typesense gives you far more product value per unit of operational cost for typo-tolerant, low-latency app search. Elasticsearch is a heavy answer to a light question.
• You are on OpenSearch (or plan to be, for licensing reasons). ES8-era official clients and OpenSearch diverge; confirm compatibility explicitly before assuming this package works against an OpenSearch cluster.
• You need ES7 support maintained in parallel. The major version bump strongly implies the ES8 client upgrade is not backwards-compatible with the 7.x client. If you must support both clusters across environments during migration, verify — the release notes do not state a support matrix, and this should be confirmed in code/tests before you commit.
• You need managed vector search with SLAs — a hosted vector DB or a managed Elasticsearch service may be the better buy than self-operated ES8.
• You need active, human-driven maintenance. The changelog is dominated by bot-authored dependency PRs plus one community contribution. That's not disqualifying (dependency automation is good hygiene), but it means you should not assume fast turnaround on bugs you file. Validate the release cadence and open-issue responsiveness against your support expectations.

Verification items before committing: confirm the supported Elasticsearch/PHP/Laravel version matrix, whether ES7 is dropped, and whether the package's test suite actually runs against a live ES8 cluster.

How to Pitch It (Stakeholders)

For executives (one paragraph): Our Laravel search integration now supports Elasticsearch 8. This removes a blocker on our search infrastructure roadmap — we can upgrade clusters to a supported version instead of staying on an end-of-life release, which reduces security and support risk. It requires a planned upgrade rather than an automatic update: it's a major version change, so we should schedule a short migration with regression testing. No new product features ship with this release; the value is keeping our search stack current and unblocked, at effectively zero incremental licensing cost.

For engineering (the operational ask): Version 12.0.0 is a major bump whose substantive change is Elasticsearch 8 support via the underlying official client; the rest is dependency and CI housekeeping. Plan the upgrade as a tracked migration: audit current index/query usage, adjust connection config for ES8's TLS-and-auth-by-default posture, run the suite against a real ES8 cluster, and stage a rollback path. Confirm the ES7 support status and the Laravel/PHP compatibility matrix before we commit. Sequenced correctly, this is a contained infrastructure upgrade that buys us ES8's vector/kNN capabilities for future search work.