DEV Community: SeaCloud Labs

SeaTicket: An Open-Source Support Center for Your Community

SeaTicket — Wed, 04 Nov 2026 09:47:43 +0000

Support requests come in through GitHub, Discord, forums, and email. Bug reports, user questions, and discussions happen across all these channels, making it difficult for maintainers to keep track of requests, find existing answers, and provide consistent support.

AI assistants like ChatGPT, Claude, Gemini can help answer questions, but maintainers still have to gather documentation, issues, and discussions from different platforms and provide that context manually. This adds work, and even with the right information, AI can overlook details, misinterpret documentation, or make assumptions that lead to incorrect answers. These mistakes can mislead users, create more work for maintainers, and ultimately undermine the community's trust in the project.

One support center for all your channels

SeaTicket brings issues and questions from GitHub, Discord, forums and email into one workspace, with connections to tools such as Jira, Linear and Confluence. Maintainers can see what the community is reporting across channels and notice when separate conversations describe the same problem.
The channels themselves stay where they are. SeaTicket syncs with each one, and approved replies are posted back to the original thread, so users get their answer where they asked while the team tracks the work in a single place.

A more reliable way to handle support with AI

SeaTicket's AI agent uses your project's documentation, issues, and past discussions to investigate support requests. It finds relevant information, identifies related issues, and drafts answers with references to the original sources, allowing maintainers to verify the information before responding.
When a report needs engineering work, the agent suggests creating a ticket for the team to assign and track through resolution. Nothing is sent, posted, or closed automatically. Maintainers review each recommendation and can approve, edit, or discard it before taking action.
Once an issue is resolved, its answer can be saved as searchable knowledge. This helps users find existing solutions and reduces repetitive questions. By grounding answers in project information and keeping maintainers in control, SeaTicket helps teams provide more reliable, consistent support as their community grows.

A front door for your community

For open-source maintainers, a dedicated support portal shows that their community matters. It gives users an official place to find answers, ask questions, report issues, and track their requests, building trust and making support feel like a core part of the project.
SeaTicket's portal brings AI chat powered by the project's knowledge base, browsable documentation, and ticket submission and tracking into one place. Users can help themselves first, finding answers and resolving common questions without waiting for a maintainer. This self-service approach reduces repetitive requests and gives the team more time to focus on building and improving the project.
Instead of questions scattered across different channels, users get a clear path to give feedback, and maintainers get one place to manage requests. The portal connects directly to your workspace, keeping the process streamlined from the first question to resolution.

An open-source alternative to Zendesk

Zendesk is a capable support platform, but its closed-source model and per-agent pricing can push costs up as a team grows. Each added maintainer means another seat, and AI usage can bring further charges.
SeaTicket takes a different approach. It is open source under the Apache 2.0 license and includes unlimited team members. Cloud pricing is based on issue volume and AI credits rather than seats, so a growing team does not mean buying more seats. SeaTicket can also be self-hosted, which Zendesk does not offer, and its code can be inspected and modified for more control over the software and how it is used.
The support portal is another point of difference. SeaTicket's external portal, where a community can chat with AI, browse the docs and submit and track its own issues, is included on every Cloud plan, Free included. On Zendesk's plan comparison, the customer portal, where customers manage their own requests, comes at an added cost and is not included on every plan.

Where the data goes

Support conversations can contain sensitive information, so data privacy matters.
Self-hosted deployments keep data on servers the team controls, in its own database and file storage, and the team decides who has access. SeaTicket Cloud stores data in the service SeaTicket runs, and it can be exported at any time.
When AI is used, SeaTicket sends the relevant text to an AI model. Teams that self-host choose that model: a hosted one from a provider such as OpenAI or Google, or a model they run themselves so the text never leaves their own servers.

Built from the work of supporting Seafile

SeaTicket comes from the team behind Seafile, an open-source platform developed since 2012. Supporting Seafile's community across GitHub, forums and email meant answering the same questions repeatedly, searching for past fixes, and trying not to lose important feedback among routine requests. SeaTicket grew out of that experience, built to organize the work and to help other maintainers facing the same challenge.

A path to an answer for every issue

Open-source communities do best when people can get help, report problems and see that someone is listening. SeaTicket gives maintainers one place to gather the conversation, investigate with AI, route unresolved issues to engineers, and reply with sources you can verify. The aim is straightforward: support issues resolved sooner, and a more consistent experience for the people asking.

SeaTicket Cloud is free to try , and the open-source code is available on GitHub .

Why we stopped using one Elasticsearch index per tenant and built our own

SeaCloud Labs — Thu, 17 Sep 2026 08:13:38 +0000

TL;DR: We open-sourced SeaSearch , an Elasticsearch-compatible search engine that keeps index data in S3 and routes ownership instead of replicating data, so tenant count isn't capped by cluster state.

The tax on one index per tenant

If you've built multi-tenant search on Elasticsearch, you've had this argument with yourself.
The clean approach to multi-tenant search is one Elasticsearch index per tenant. Data stays physically separate, queries only hit the relevant tenant's data, and a traffic spike from one customer does not slow down anyone else's.
But every index costs at least one shard, and each shard is basically its own mini Lucene database, with its own files, its own background maintenance work, its own chunk of memory.
Separately, every index's mappings and routing information live in cluster state, which the master maintains and replicates to every node. A few thousand indexes and mapping updates get sluggish. Tens of thousands and the master node becomes the thing you page about at 3am.

We didn't want to write a search engine

Two years ago we started looking for a way out. The first decision was to not build a search engine from scratch. Analyzers, scoring, segment merging, query planning. That's decades of accumulated work and we had no interest in relearning it badly.
ZincSearch got us most of the way. Written in Go instead of the JVM, where Bluge is doing the indexing underneath, and an Elasticsearch-compatible API surface. That handled the runtime footprint and the migration story in one move.
What it didn't solve: running an unbounded number of indexes across a cluster without paying for that isolation in replicated storage and operational complexity. That's the part we built, and it's most of what SeaSearch is.

Put the indexes in S3 and route ownership instead of data

Compute nodes hold no authoritative data, so failover is a map update rather than a data migration.

Four moving pieces:

Compute nodes serve reads and writes. They all talk to the same S3-compatible bucket, where index data is stored.
etcd holds cluster metadata: index metadata and the partition ownership map.
The cluster manager watches node health and decides who owns what.
The proxy (gateway) takes a client request, looks up which node owns that index, and forwards it.

Indexes are hashed into a fixed number of partitions. The cluster manager keeps a partition-to-node map in etcd. The proxy reads that map to route. When a node dies or a new one joins, the manager recomputes the map and hands ownership over.
Nothing moves. The new owner pulls what it needs from S3 on demand.
Compare that to a replica-based cluster, where high availability means a second physical copy of your data on another node, and rebalancing means shipping gigabytes across the network while your cluster is already unhappy. With shared storage, adding read capacity is: start a node, update the map. Losing a node is: update the map.
This is why the index count stops being scary. Creating an index adds an entry to etcd, not a shard to a cluster state document that every node has to agree on.

The obvious objection: S3 is slow

It is. A round trip to object storage is roughly an order of magnitude worse than local NVMe, and search is a latency-sensitive workload. Caching here is mandatory.
The thing that makes the cache easy is that index data is organized into immutable segments. Once a segment is written it can be read or deleted, never modified.
Cache invalidation is the hard part of caching. Immutability deletes the question entirely. If you have the segment locally, your copy is correct.
Compute nodes keep a rotating local disk cache. When it fills, old segments get evicted to make room. That's what lets a node serve an index larger than its own disk: it just churns through segments.

Two things make the cold path tolerable:

Parallel warm-up. Modern datacenter bandwidth is enormous and a single-threaded fetch wastes it. During warm-up we pull many segments from S3 concurrently, which turns a serial latency problem into a bandwidth problem.
Distributed query execution. For very large indexes, SeaSearch can split a single query across multiple compute nodes. Each loads and searches a slice in parallel, and results get aggregated. This does two useful things at once: queries go faster, and cache pressure gets spread out instead of crushing one node.

Latency in practice: the first query after a node starts, or after a segment gets evicted, is slow. Every query after that runs at roughly local-disk speed. For file metadata search, where the active working set is a small fraction of total data, that's been a good trade for two years. If your workload touches all of your data uniformly and constantly, it would be a worse one.

The ranking problem with multiple indexes

Searching across many independent indexes introduces another problem: the relevance scores from those indexes aren't directly comparable.
BM25 scores are computed from index-local statistics: term frequency, document count, average field length. A match for invoice in a twelve-document library gets a score computed against completely different statistics than the same match in a 400,000-document library. Both _search across multiple indexes and _msearch score each index independently.
Merge those results, sort by score, and your top hit mostly reflects which library the file happens to live in. Users don't file that as "inconsistent scoring across index statistics." They file it as "why is this random file at the top."
So we added a unified search endpoint that computes comparable scores across the whole set of indexes:

POST /api/unified_search
{
  "index_queries": [
    { "index": "library-a1b2", "query": {} },
    { "index": "library-c3d4", "query": {} }
  ]
}

The constraint is that the query has to be the same for each index, aside from filters. That's fine for the "search everything I can see" case, which is the case that needed it.

What it doesn't do

Compatibility claims are worth less than a list of what's missing, so here's ours.

No shards or replicas settings. number_of_shards and number_of_replicas are meaningless under shared storage.
Field types are limited to text, keyword, numeric, bool, date, and vector. No nested , object , or flattened .
Mappings are additive. You can add fields. You can't change existing ones.
Unsupported search parameters: indices_boost , knn , min_score , retriever , pit , runtime_mappings , seq_no_primary_term , stats , terminate_after , version .
Your durability is your object store's durability. That's a feature if you're on S3 or a well-run MinIO cluster. It's a problem if you were planning to point it at a single disk and call it a day.

If you're running Elasticsearch for observability with deep aggregation pipelines and ILM policies, SeaSearch is not your replacement and we won't pretend otherwise. If you're running app search for a multi-tenant product, it probably is.

Why we're open-sourcing this

We built SeaSearch because Seafile needed it and we think the architecture solves a problem that other multi-tenant applications may also run into. There's no paid tier and no feature set held behind a commercial license.
We'd rather have people use it, test it, and tell us where it breaks than keep it sitting inside one company's infrastructure.

Tell us how yours breaks

Curious what other people landed on, because every option has failures and nobody writes about theirs:

Where did it start hurting, and at what document count?
How many indexes before cluster state became the bottleneck?
How do you handle promotion?
What does that cost you in operations?

Code and issues: https://github.com/seacloud-lab/seasearch
Docs: https://seasearch-manual.seacloud-labs.ai/latest/
Happy to answer architecture questions in the comments.