Scout Lunr Laravel Package

Product Decisions This Supports

• Build vs. buy for site search. Gives a third option between "no search" and a managed SaaS contract (Algolia, Typesense Cloud, Elastic Cloud). Lunr is a static/client-side-capable full-text engine; running it behind a Cloudflare Worker with a native Laravel Scout driver means we can ship relevance-ranked search without standing up a cluster or signing a per-document/per-query pricing agreement.
• Feature scoping for search-driven roadmap items. Because it plugs into Scout, the same application code backs search-as-you-type, filtered listings, and "related content" surfaces. This lets us scope search work as a thin slice on top of an existing Eloquent/Scout setup rather than a standalone search platform epic.
• Cost and ops modeling. The cost curve is Worker invocations plus index storage/egress on Cloudflare, not seats, documents, or search operations. Useful for decisions where search volume is spiky or hard to forecast (launch traffic, seasonal catalogs, public-sector tender traffic).
• Vendor-footprint and data-residency decisions. Index and query path live on Cloudflare's edge, with the index built from our own data. Relevant where we're consolidating vendors, avoiding a new US-managed search SaaS, or need to reason about where query text and document content physically land.
• Prioritizing which products get search first. Best fit is read-heavy, modest-write corpora: documentation, knowledge bases, policy/legal reference material, internal tools, small-to-mid product catalogs. Poor fit is high-write feeds or per-tenant-isolated indexes at scale — that's a scoping input, not just a technical note.
• Buy-in on a "search abstraction" principle. Choosing a Scout driver deliberately keeps relevance and index infrastructure swappable. That's a decision worth stating explicitly now, because it caps the downside of betting on a 0.x package and sets expectations for future migrations.

When to Consider This Package

Adopt (pilot or production) when:

• The application is on Laravel 12 or 13 and PHP 8.2–8.5, and we're already using or willing to use Laravel Scout. The release explicitly targets this matrix, so an upgrade-blocked app gains nothing here yet.
• The corpus is bounded and read-heavy. Lunr indexes are built and shipped as artifacts; if the index is large and rewritten constantly, the reindex-and-distribute cost dominates and a server-side engine (Meilisearch, Typesense, OpenSearch) is a better shape.
• We already operate on Cloudflare, or are willing to. The Worker is deployed and configured separately from the package — that's a real operational commitment (deploy pipeline, secrets, monitoring, versioning of the worker alongside the app), not a composer require and done.
• Search requirements are full-text relevance and simple filtering. No faceting at scale, no geo, no vector/semantic retrieval, no per-user personalization, no A/B relevance testing, no search analytics.
• We can accept 0.x versioning: pin the exact version, read the changelog before each bump, and keep the Scout driver boundary clean so a swap is a config change plus a reindex, not a rewrite.
• We don't need a support contract or an uptime SLA covering the search path beyond what we build ourselves.

Look elsewhere when:

• Requirements include semantic/vector search, rich faceting, multi-language stemming beyond Lunr's plugins, or query-level relevance tuning with an analytics feedback loop. This package does not address those, and bolting them on defeats the low-ops premise.
• The corpus is large enough that shipping an index is impractical, or writes are frequent enough that reindexing is continuous. The Worker model actively fights you here.
• Search is revenue-critical and needs a vendor SLA, named support, or a managed control plane. A 0.1.x community package plus a self-deployed Worker is not that.
• Regulated workloads where the index cannot leave our own infrastructure, or where the vendor set is fixed.
• The team has no appetite for operating edge infrastructure. The "separate deployment" detail is where most of the total cost of ownership actually lives.
• We're on Laravel 10/11 or older PHP and have no near-term upgrade path.

Assessment of this release specifically: v0.1.1 is the package's formative release — it establishes the Lunr engine, the query builder, and a configurable Worker client, and pins a modern Laravel/PHP support matrix. There are no deprecations or breaking changes to plan around because there is no prior baseline; equally, there is no stability track record. Treat this as "credible enough to spike, not yet enough to standardize on." A two-to-three day timeboxed spike against a real corpus — measuring index build time, Worker cold-start latency, relevance quality on our actual queries, and reindex cost — should precede any roadmap commitment that names this package.

How to Pitch It (Stakeholders)

To executives: We have an option to add proper search to the product without buying a search SaaS contract or hiring for search infrastructure. It runs on Cloudflare's edge and plugs into Laravel the same way our existing database-backed search would, so the application work is small and the switching cost later is low. The trade-off is maturity: this is a 0.1.x community package with a component we deploy and operate ourselves. My recommendation is a short, cheap spike to validate relevance and cost on our real content, then a go/no-go — not a platform-level commitment today. If it works, we get search at roughly infrastructure-level cost with no new vendor relationship; if it doesn't, we've spent a few days and learned what our search requirements actually are.

To engineering: This is a Scout driver, so it slots into the existing Searchable model pattern — no bespoke query layer, no separate search service in the request path. The moving parts are (1) the package, (2) a Cloudflare Worker we deploy and version independently, and (3) the config published via vendor:publish. Two things I want your read on before we commit: the operational overhead of owning that Worker deploy (secrets, rollout, monitoring, keeping it in lockstep with app releases), and whether Lunr's index-build model holds up at our corpus size and write rate. Please pin the exact version — 0.x means the API can move — and keep everything behind Scout's interfaces so we retain the option to swap to Meilisearch or Algolia without touching product code. The spike should produce numbers on cold-start latency, reindex duration, and index payload size, plus an honest read on relevance for our top ~20 queries.

To the wider team: Search becomes something we can scope and ship as a feature rather than a program. It also stays reversible, which is the main reason it's worth evaluating now rather than waiting for a 1.0.