This post lays out the trade-offs honestly, including where the open-source option — Viglet Turing ES — fits and where it doesn't.

The options at a glance​

The real decision axes​

1. Pricing model — per-document SaaS vs. self-host​

SaaS search bills scale with your content volume and query traffic. For a large AEM repository (hundreds of thousands of pages, public traffic), that line item grows every year. Self-hosting Turing ES on infrastructure you already run flips it to a fixed cost — you pay for compute, not per record.

If your content set is small and traffic is spiky, managed SaaS may genuinely be cheaper and less operational work. Be honest about your scale.

2. Data residency​

With Algolia and Coveo, your indexed content lives in their cloud. For regulated industries — finance, healthcare, education, government — AEM author content leaving the building is often a non-starter. Turing ES, Lucidworks, and raw Solr/ES all index inside your perimeter.

3. Connector quality (the part everyone underestimates)​

A search engine is only as good as how cleanly it ingests AEM. The hard parts: real-time sync on publish, tags → facets, multi-language paths, author and publish environments, and cascade re-indexing when a shared fragment changes. Turing ES handles these through Dumont DEP: OSGi event listeners, infinity.json traversal, automatic tag facets, and dependency-tracked cascade re-indexing — out of the box.

Raw Solr/Elasticsearch give you the engine but none of this — you build the AEM pipeline yourself, which is usually months of work.

4. Semantic search + RAG without a second vendor​

The 2026 reality is that "search" now includes conversational, grounded AI answers. With SaaS you often add a separate AI tier (and a separate bill). Turing ES bundles faceted search, vector/semantic search, and RAG with your choice of LLM (OpenAI, Ollama, Anthropic, Gemini) in one Apache-2.0 platform — answers are grounded in your AEM content with citations, on your own infrastructure. See the RAG guide.

When to pick which​

• Choose Algolia if you want zero-ops, your content set is modest, and data residency isn't a constraint.
• Choose Coveo if you're a large enterprise already invested in their ecosystem and want a fully managed AEM connector with a budget to match.
• Choose raw Solr/Elasticsearch if you have a search engineering team and want maximum control — and are prepared to build the AEM pipeline.
• Choose Viglet Turing ES if you want self-hosted enterprise search with a first-class AEM connector, facets, semantic search, and RAG built in — under an open-source license, with optional commercial support.

Try it​

Indexing AEM into Turing ES takes about 15 minutes — there's a step-by-step guide using the WKND reference site.

• ⭐ Turing ES on GitHub (Apache 2.0)
• 📘 AEM Connector docs
• 💬 GitHub Discussions

Viglet Turing ES is open-source enterprise search with semantic navigation and generative AI — an alternative to Algolia, Coveo, and Lucidworks for teams that want to keep their content on their own infrastructure.

Most teams reach for a SaaS layer — Algolia, Coveo, or Lucidworks — and pay per document and per query, while their content leaves their infrastructure. This guide shows the open-source alternative: indexing AEM into Viglet Turing ES, an Apache-2.0 enterprise search platform you self-host, with semantic navigation and generative AI built in.

What you'll build​

By the end you'll have AEM pages flowing into a Turing ES search index, with:

• Faceted search — AEM tags become filterable facets automatically
• Real-time sync — pages re-index the moment they're published in AEM
• A query API — REST, GraphQL, or SDK, ready for any front end
• (Optional) RAG — grounded, citeable AI answers over the same content

The architecture in one picture​

Turing ES doesn't crawl AEM directly. A dedicated connector — Viglet Dumont DEP — sits between them: an OSGi bundle inside AEM emits events, and the Dumont connector fetches the content and indexes it into Turing ES.

Three components, each documented in full:

Step 1 — Run Turing ES​

The fastest path is Docker:

docker pull ghcr.io/openviglet/turing-ce:latest
docker run -p 2700:2700 ghcr.io/openviglet/turing-ce:latest

Open http://localhost:2700/console and set the admin password on first run (TURING_ADMIN_PASSWORD env var). Create a Semantic Navigation (SN) Site — this is the index your AEM content will land in.

Step 2 — Configure the AEM source in Dumont​

In the Turing ES admin console, go to Enterprise Search → Integration and add an AEM instance. The key source fields:

That's it for the happy path. AEM tags are converted to facets automatically — no field mapping required.

Step 3 — Index your first content​

You have three ways to trigger indexing. For a first run, call the connector directly (the WKND reference site is perfect for testing):

curl -X POST http://localhost:30130/api/v2/aem/index/WKND \
  -H "Content-Type: application/json" \
  -d '{
    "paths": ["/content/wknd/us/en"],
    "event": "INDEXING",
    "recursive": true
  }'

The connector calls AEM's infinity.json to read the full JCR node tree, pulls jcr:content.tags.json for facets, traverses children, and sends each page through the Dumont pipeline into Turing ES.

For large content trees, switch from tree traversal to AEM's QueryBuilder discovery, which finds all pages in bulk and processes them in parallel:

dumont:
  aem.querybuilder: true
  aem.querybuilder.parallelism: 10

Step 4 — Real-time sync (production)​

For production, install the aem-server OSGi bundle inside AEM. It subscribes to AEM's replication and page events and notifies Dumont automatically:

Configure the bundle in AEM's Web Console (Host = your Dumont URL, Config Name = the source name). From then on, publishing a page in AEM re-indexes it within seconds — no cron, no full re-crawl.

Tip — cascade re-indexing. When a shared component or experience fragment changes, every page that references it can go stale. Turing/Dumont can track /content/* dependencies and automatically re-index dependents. Enable dumont.dependencies.enabled=true and run a Reindex All to populate the dependency graph.

Step 5 — Query it​

Your AEM content is now searchable through any of these:

# REST — faceted search
curl "http://localhost:2700/api/sn/wknd-search/search?q=adventure&rows=10&_setlocale=en_US"

# REST — autocomplete
curl "http://localhost:2700/api/sn/wknd-search/ac?q=adven&_setlocale=en_US"

// JavaScript / TypeScript SDK
import { TurSNSiteSearchService } from "@viglet/turing-react-sdk";

const search = new TurSNSiteSearchService("http://localhost:2700");
const results = await search.search("wknd-search", {
  q: "adventure", rows: 10, localeRequest: "en_US",
});

Or via GraphQL at http://localhost:2700/graphiql. The facets derived from your AEM tags come back with the results — wire them straight into a filter panel.

Step 6 (optional) — Conversational answers (RAG)​

Because Turing ES already holds your AEM content, turning on RAG gives you grounded AI answers with citations — over your own content, on your own infrastructure, with the LLM of your choice (OpenAI, Ollama, Anthropic, Gemini):

curl "http://localhost:2700/api/sn/wknd-search/chat?q=What+adventures+are+available+in+the+Alps"

This is the part SaaS search boxes can't match without shipping your content to a third party.

Why open-source for AEM search?​

• Your content stays in your infrastructure — no per-document SaaS pricing, no data egress, AEM author content never leaves the building.
• Tags → facets with zero mapping, real-time event-driven sync, and cascade re-indexing for shared components.
• Search + semantic + RAG in one platform under Apache 2.0 — not three separate vendor bills.

Next steps​

• 📘 AEM Connector — full reference (event listeners, QueryBuilder, custom extractors)
• 📗 Turing ES — AEM Integration
• 📙 Semantic Navigation and RAG guides
• ⭐ Star Turing ES on GitHub — it genuinely helps others find it
• 💬 Ask in GitHub Discussions

Viglet Turing ES is open-source (Apache 2.0) enterprise search with semantic navigation and generative AI. Self-host it, index Adobe AEM, WordPress, databases, file systems, and web content, and own your search stack end to end.