SWIRL Community: federated search and RAG that queries your sources live

The copy problem SWIRL refuses to accept

The README frames the target user through a contrast table. The usual way, it says, is to stand up a vector database, move and duplicate your data, build ETL pipelines, and then secure and audit a new copy. SWIRL's answer is to query the sources live, with the user's own permissions, and never create that copy. The audience this fits is an organisation whose knowledge is already governed somewhere else: SharePoint, Confluence, Drive, Jira, GitHub, tickets, docs. Those teams do not have a retrieval problem as much as a permission and duplication problem. A vector store forces a second access-control model that has to be kept in sync with the first. SWIRL pushes permission enforcement back to the source, which the README lists as a feature row: permissions enforced at the source. That is the whole pitch, and it is a narrower pitch than general AI search. If your corpus is a few thousand documents you own outright, a vector database is simpler and SWIRL buys you little.

What happens between the question and the cited answer

The flow described in the README has four visible stages. A user asks a question in the Galaxy UI. SWIRL federates that query out to the configured connectors, synchronously or asynchronously over its REST API, so each source is queried in place rather than crawled into a central index. The returned results are re-ranked using cosine vector similarity, which the README attributes to a spaCy large model plus NLTK, with duplicate detection and result mixers applied. Then, if you supplied an OpenAI key, it generates an answer with citations you can click through to the original source. Results are persisted, either in SQLite or Postgres, for post-processing and analytics. Two architectural details matter more than the marketing. First, ranking happens after federation, so connector latency is on the critical path unless you use the asynchronous mode. Second, the query and response transformation is done by a pipelined Processor architecture, and connectors and mixers are described as extensible objects. That is where a team would hook in domain-specific normalisation, and it is the part of the codebase worth reading before you commit.

Getting it running: three commands and one environment variable

The README's quick start is deliberately short. Fetch the compose file: curl https://raw.githubusercontent.com/swirlai/swirl-search/main/docker-compose.yaml -o docker-compose.yaml. Then, optionally, export MSAL_CB_PORT=8000, MSAL_HOST=localhost, and OPENAI_API_KEY with your key, which is what enables real-time RAG with citations. Note that the MSAL variables are present in the same block as the OpenAI key, and the README does not explain what they configure beyond the surrounding context of Microsoft 365 OAuth2 integration. If you are not connecting Microsoft 365, treat them as unexplained and test without them. Start the stack with docker-compose pull && docker-compose up, then open http://localhost:8000/galaxy and log in with admin / password. Out of the box SWIRL is configured to search Arxiv, European PMC and Google News, which is enough to confirm the federation path works before you touch a real connector. The default credentials are a development convenience and should not survive contact with any shared network.

The Docker install does not persist, and that is the first real constraint

The README states plainly that the Docker version does not retain data or configuration when shut down, and points to a separate Quick Start Guide for a persistent install. This is the most consequential operational fact in the document and it is easy to miss under a two-minute quick start. It means the compose file is a demonstration, not a deployment. Anything you configure through the UI, any connector you add, any result history you accumulate, is gone on the next docker-compose down. A production install has to be built from the persistent path, and the README does not describe that path in the material available here. The result store choice compounds this: SQLite or Postgres. SQLite is fine for a single node and a small federation, but the moment you run more than one instance or want the analytics the README mentions, Postgres is the only defensible option, and that decision is not made in the compose file.

Cosine similarity is the ceiling, and the README admits it

The comparison table is unusually candid. Community ranks with cosine similarity using spaCy and NLTK. Enterprise ranks with a three-pass pipeline: BM25, then E5 embeddings with hybrid fusion, then a cross-encoder. Those are not variations on a theme. A single cosine pass over live federated results is sensitive to the embedding model's behaviour on short, heterogeneous snippets, and it has no lexical fallback when the vector signal is weak. The README's own framing is that you graduate to Enterprise when you outgrow cosine ranking. So the honest reading of Community is a system whose retrieval quality is bounded by a first-generation ranking method, applied to sources it does not control the formatting of. For a knowledge-base search box where users scan ten results, that may be entirely adequate. For an assistant that drafts customer-facing responses, ranking quality is the failure mode you will hit first, and it will look like the model hallucinating when it is actually the retriever returning the wrong passages.

Community versus a vector database: live federation or a materialised index

The obvious alternative is the pipeline SWIRL argues against: chunk your sources, embed them, store them in a vector database, and query that. The difference is not philosophical, it is operational. A vector database gives you sub-second retrieval, stable ranking you can tune offline, and a corpus you can evaluate against because it is fixed at ingest time. It costs you an ingestion pipeline, a re-indexing schedule every time a source document changes, and a second permission model that has to mirror the first. SWIRL gives you freshness and permission inheritance at the cost of per-query latency across every connector, ranking you cannot pre-compute, and a result set whose composition changes between two identical questions. There is also a middle option the README does not discuss: keep the vector database but populate it from the same source APIs SWIRL federates, which gets you retrieval speed while still reading from the systems of record. That path keeps the ETL work SWIRL exists to remove, so it is a real trade, not a free win.

Maintenance, licensing and the Enterprise boundary

SWIRL Community is Apache-2.0, which permits commercial self-hosting and modification. The README does not describe any licence obligation beyond that, and nothing here should be read as legal advice; if you redistribute or embed it in a product, read the licence text yourself. On maintenance, the release cadence visible in the material is roughly monthly patch releases under the 4.5.0.x line, and the repository is not archived. The practical upgrade cost is unknown from this material: the README does not document a migration procedure, and the persistence story (SQLite or Postgres) means schema changes across versions are a real risk you should test on a copy before touching production. The Enterprise boundary is explicit and worth quoting in substance: three-pass reranking, canonical answers and Pinned Results, an MCP server for agents, a hallucination warning on generated answers, and a business console with AI-Yield analytics, semantic cache and dedup at scale are all listed as not included in Community. If any of those is a requirement rather than a nice-to-have, you are evaluating the wrong artefact.

Editorial conclusion

Adopt SWIRL Community if your retrieval problem is spread across systems you cannot copy (SharePoint, Confluence, Drive, Jira, GitHub) and you can live with cosine-similarity ranking over live results. Do not adopt it if you need canonical answers, an MCP endpoint for agents, a hallucination warning on generated text, or managed connectors, because the README places all four behind SWIRL 5 Enterprise. Verify two things before you commit: whether the connectors you need are on the current list at swirlaiconnect.com/connectors, and whether a persistent Postgres-backed install (not the Docker compose file, which the README says does not retain data or configuration when shut down) survives your restart and upgrade path.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. swirlai/swirl-search on GitHub