We started with a question that turned out to be uncomfortable: why does every “AI search” tool want our data on their servers?
The honest answer is that it’s the easy architecture. Send the text to a managed embedder, store the vectors in a managed vector DB, run BM25 in a managed search service, and bill the customer per token, per vector, per query. The vendor never has to ship a binary, never has to support filesystem semantics, never has to worry about whose laptop their code runs on.
It’s the easy architecture for the vendor. It’s the wrong architecture for almost every customer.
What you actually want from a search engine
Think about what indexing your knowledge base should give you:
- A search bar that finds the file you meant, including the ones whose vocabulary doesn’t match your query.
- A way to wire it into your AI agent without writing custom glue.
- Confidence that your data is still your data — not bundled into someone’s training set, not subject to a vendor’s outage, not stuck behind a billing portal when you cancel.
Item 3 is where SaaS search goes wrong. Even the vendors that pinky-promise not to train on your data have to receive it to index it. The data is there, on their disks, in their logs, in their backups. The promise is a policy, not a property.
Self-hosted semantic search is a different property: your text never reaches a third party because the embedder runs on your machine. Nothing to opt out of, nothing to renegotiate when the vendor’s terms change.
The objections, and why they don’t hold anymore
Three objections kept self-hosted semantic search out of mainstream practice until ~2024:
“Local embeddings aren’t good enough.” They were once. They aren’t anymore. Open-weight models — BGE, Nomic, GTE, Jina — score within a few percent of the best closed APIs on MTEB. For retrieval (not for fine-grained reasoning), the gap is closed.
“Running embedders locally is a pain.” It was. ONNX Runtime + FastEmbed-go changed that. A single binary, the model auto-downloads on first use, runs on CPU. No GPU required for the corpora most teams have.
“Vector databases are complicated to operate.” They are — when you treat them as a separate system. SQLite + sqlite-vec collapses the vector store into a file. There’s nothing to operate.
The three objections each had a real engineering blocker. Each blocker fell, independently, in the last two years. The new default is local.
What StrataFS is, in this frame
StrataFS is the search engine that exists at the intersection of those three changes:
- Open-weight embedder (BGE Base EN v1.5 default, swappable).
- ONNX Runtime for local execution.
- SQLite + FTS5 + sqlite-vec for storage.
The result is a single Go binary that indexes Local + S3 + GCS + Azure + SharePoint + Drive + Jira, runs hybrid search across all of them, and never makes a network call unrelated to the configured storage backends.
The most useful sentence to print at the top of your security review: “StrataFS, in the configured deployment, makes outbound calls only to the storage backends listed in
config.toml. The embedding model runs in-process. There is no telemetry.”
Real things you can do that you couldn’t before
Three workflows that “self-hosted” enables and SaaS doesn’t:
1. Index code you can’t ship to a vendor. Defense contractors, regulated finance, anyone with a “no third-party processing” clause in their security policy. Send a developer the npm package; they install it locally; their codebase is indexed without ever leaving the machine. The compliance conversation went from “weeks” to “no”.
2. Index ephemeral or air-gapped environments. A disconnected research workstation. A customer’s on-prem environment where you’re consulting. A travel laptop on a flight. The index lives on disk; queries don’t need network.
3. Bring your own embedder. Have a domain-specific model trained on legal contracts, medical notes, your codebase? Drop the ONNX file into the config. The hybrid search engine doesn’t care which model produced the vectors as long as the dimensions match.
The shape of operational cost
People underestimate how much less operational work self-hosted semantic search is than the SaaS version. Some math:
- SaaS vector DB: API keys to rotate, rate limits to budget, request retries to write, billing to forecast, vendor outage incident reviews to run, GDPR DPA to refresh annually, data residency dance for EU customers.
- Self-hosted SQLite:
cron rsync ~/.stratafs/ s3://backups/or equivalent.
The SaaS model is “complexity but it’s their complexity”. Until something goes wrong with your stack and the vendor support has 4 hour SLA. Then it’s your complexity again.
When SaaS still makes sense
Be honest. Self-hosted semantic search isn’t always the right answer:
- Massive shared corpora: 500M+ documents indexed once and queried by thousands of users. SaaS vendors absorb the operational scale you’d otherwise build.
- Hyper-elastic load: zero queries for hours, then 10,000 in 30 seconds. Managed vector DBs scale faster than you can provision.
- Strong managed-ML preferences: teams that want a vendor’s roadmap, support contracts, and SOC2 attestation rather than DIY.
For everything else — code search, team knowledge bases, personal indexing, agent retrieval, small/medium enterprise document search — the math is now in favour of local.
The license matters
StrataFS is MIT-licensed. Not “source available”, not “open core”, not “free unless you commercialize”. MIT. The full source. No usage limits. No telemetry. No phone-home. No “we may change this license later” clause.
This matters because a self-hosted tool with a hostile license is a vendor lock-in waiting to happen. The whole point of going local is to control your own substrate. A copyleft, server-side-public-license, or other unfriendly license re-introduces vendor risk at a different layer.
How to try it without committing
The fastest path to “do I want this?”:
npm install -g stratafs
stratafs config init
stratafs sources add code --type local --path "$HOME/work"
stratafs serve &
stratafs search "your concept here" --mode hybrid
Three minutes. The index lives in ~/.stratafs/; rm -rf ~/.stratafs undoes everything. No account to delete, no SaaS dashboard to log out of, no email follow-up.
If it works for you, the next step is wiring your agent (see the MCP page) or pointing it at a cloud bucket (see the storage page). If it doesn’t, you’ve lost an evening.
That’s the case for self-hosted semantic search. It’s not ideology — it’s that the three blockers fell, and the math now favours local for the workloads most teams actually have.