xynehq/xyne is archived in place: an Apache-2.0 work search engine that now lives at juspay/xyne-spaces
AI-first Search & Answer Engine for work. Open-source alternative to Glean.
At a glance
- What is it?
- Xyne is a self-hosted, permissions-aware search and answer layer over Google Workspace, Slack, Atlassian and code hosts. The repository you are probably looking at is no longer the maintained one, which changes the adoption question more than any feature list does.
- Who is it for?
- Adopt Xyne only after confirming that github.com/juspay/xyne-spaces is the repository you are actually installing from, and that its README still points at the same docs.xynehq.com deployment pages this one does. If you are evaluating the xynehq/xyne tree itself, treat it as a frozen snapshot: useful for reading the integration and permissions design, wrong for building on, because the README states plainly that this repo is no longer maintained here.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The repository you found is a forwarding address
The first line of the README is a warning banner: this repo is no longer maintained here, and the new home is github.com/juspay/xyne-spaces. Everything below that banner describes Xyne as it was at the point of the move. The last recorded push to this tree is 2026-09-10, and the most recent release listed is v3.1.1 from 2025-09-30. Those two dates do not line up with a project under active development, and they are not supposed to. If you are reading this because a search result sent you to xynehq/xyne, the practical step is to open the juspay repository before you read any further, because issue threads, releases and fixes will accumulate there and not here. The rest of this article describes the design as the README and the linked documentation present it, which is the honest scope of what can be verified from this material.
What fragmentation problem Xyne claims to solve, and for whom
The README frames the problem as work information spread across SaaS apps, docs, files, repos, projects, issues, emails, messages and tickets. The stated goal is a combined Google plus ChatGPT style experience: search across all of it and get answers with sources attached. The named use cases are concrete rather than abstract. Find a file. Triage an issue. Ask everything about a customer, a deal, a feature or a ticket. Discover the right people. That list tells you the intended user is someone inside an organisation who already has a dozen tabs open and no single place to ask. The buyer is more likely an IT or platform team willing to run a service than an individual, because the product only works once it holds credentials for the apps it indexes. Xyne positions itself as an open-source alternative to Glean, Gemini and MS Copilot. The word that matters in that sentence is open-source, since the deployment model and the model choice are the parts a hosted competitor will not give you.
Google Workspace coverage is the differentiator, not the graph
The README makes a specific claim about scope: Xyne is live across all of Google Workspace, meaning Drive, PDFs, Docs, Sheets and Slides, plus Calendar, Contacts and Gmail including attachments. It then argues that when most enterprise search tools say Google Workspace integration they generally mean Drive, and skip contacts, calendar and gmail. That is the sharpest claim in the document and the one worth testing first, because it is also the easiest to check. Calendar and Contacts are not documents. They are structured records with their own access semantics, and pulling them into a search index means deciding what a result looks like when the answer is a meeting rather than a paragraph. The README does not describe how those record types are represented. Slack and Atlassian are listed as next, not shipped, so anyone whose information lives mainly in chat and tickets is looking at a roadmap item rather than a feature.
The mechanism: connectors, an index, a relationship graph, then retrieval
The architecture the README describes has four stages. Connect to applications. Securely index the data. Map a graph of relationships. Serve answers with sources. The ordering matters, because the graph sits between indexing and answering, which is what allows a question about a customer or a deal to resolve across several systems rather than matching a single document. The README states that ingestion is multi-threaded, which is a claim about throughput during the initial crawl rather than about query latency. Model choice is deliberately outside the core: the project describes itself as model agnostic, able to plug into any LLM, through any cloud provider, and the demo section includes DeepSeek running over internal data, with the README noting you can point it at a local DeepSeek via ollama. The privacy claims are stated as absolutes: no training on your data or prompts, and no telemetry. Those are architectural promises rather than observable behaviour, and the material does not include the code paths that would let you confirm them independently.
Permissions are enforced live, which is the hard part
The README describes permissions-aware behaviour as live enforcement of the apps' existing permissions, with the rule that no one sees what they do not have access to. This is the single most consequential design decision in the project, and it is the one most likely to break in ways users notice immediately. Live enforcement means the search layer cannot cache an answer past a permission change without risking a leak, so the retrieval path has to consult the source systems or a faithfully synchronised copy of their ACLs. The README does not explain which of those two approaches Xyne takes, and the difference is large: consulting source systems on every query adds latency and coupling, while mirroring ACLs adds a synchronisation problem where a revoked share can linger. Until that is documented, the permissions claim should be treated as the primary thing to test, not the primary thing to trust.
Getting it running: docker-compose, a service account, and the docs
Deployment is presented as a single docker-compose command, runnable locally or on a virtual machine. The README does not inline the compose file. It points to docs.xynehq.com, with a Quickstart section for local runs and a Cloud Deployment section covering AWS EC2 with Docker. Google Workspace setup is a separate step: the README says to follow the Service Account integration instructions at docs.xynehq.com/authentication/service-accounts. So the real setup sequence is three external pages, not one command, and the compose invocation itself is not visible in this repository's README. The README states the project is self-hosted and can be deployed on a laptop, on-premises or in the cloud. It also states there is no telemetry, which means there is no vendor-side dashboard to fall back on when ingestion stalls. Whatever observability you get is whatever the compose stack ships with, and that is not described here.
Where Xyne is the wrong tool
Three cases stand out. First, if your organisation's institutional knowledge lives mainly in Slack and Jira, the README lists those as next, so the product's coverage of your actual corpus is partial by its own account. Second, if you cannot issue a Google Workspace service account with broad read scope, the integration path does not exist for you; the whole design assumes the search layer can read what users can read. Third, if you want a managed service with a support contract, self-hosting is the point of the project rather than an option within it, and the Apache-2.0 licence gives you the code without giving you an operator. There is also a maintenance failure mode specific to this repository: anyone who forks xynehq/xyne to build on it is forking a tree the maintainers have already declared dead, and will be carrying upstream divergence from the first commit.
How this differs from Glean, and from a plain RAG stack
Glean is the comparison the README invites, and the difference is not primarily retrieval quality, which cannot be assessed from this material. It is control. Glean is a hosted product: you grant it access, it indexes, and the operational surface is theirs. Xyne inverts that, which is why the README leads with self-hosted, model agnostic and no telemetry. You pick the LLM, you pick the cloud, and you can point it at a local model. The cost of that inversion is that indexing, permission synchronisation, upgrades and connector breakage become your problems. The other comparison is against assembling your own retrieval pipeline from an embedding store and a chat interface. A hand-rolled stack gives you exactly the connectors you write and no relationship graph. Xyne's stated bet is that the graph plus the pre-built connectors are worth more than the flexibility you give up, and the README's framing of an OrgOS platform for internal AI applications is that bet stated as a direction.
Maintenance, licensing and what the move costs you
Apache-2.0 is a permissive licence. It permits commercial use, modification and redistribution, and it includes a patent grant. It does not give you the Xyne trademark, and it does not obligate the maintainers to keep the connectors working when Google changes a Workspace API. The material here does not state a support policy, an LTS branch, or a compatibility matrix for the Google APIs the connectors depend on, so the realistic maintenance model is that you track the juspay repository and absorb breaking changes yourself. The upgrade cost is dominated by the permission layer: a change to how ACLs are fetched is a security-relevant change, not a routine version bump. This is not legal advice, and if you are deploying inside a regulated environment, have counsel read the licence alongside your own data processing obligations rather than relying on a summary.
Editorial conclusion
Adopt Xyne only after confirming that github.com/juspay/xyne-spaces is the repository you are actually installing from, and that its README still points at the same docs.xynehq.com deployment pages this one does. If you are evaluating the xynehq/xyne tree itself, treat it as a frozen snapshot: useful for reading the integration and permissions design, wrong for building on, because the README states plainly that this repo is no longer maintained here. Verify the Google Workspace service account scopes against the authentication page before you hand it credentials, and check whether the Slack and Atlassian connectors are still listed as next rather than shipped.
Community notes