SesameFS: A Multi-Cloud Seafile Alternative
Key Takeaways:
- SesameFS is an open-source, multi-cloud file storage and sync platform written in Go, designed to replace Seafile Pro while reusing existing Seafile desktop and mobile clients.
- Its architecture separates metadata (Apache Cassandra 5.0), file payloads (S3-compatible content-addressable blocks), and the API layer (stateless Go servers behind nginx), allowing multi-region deployment and automatic failover.
- Two-tier storage moves infrequently accessed data from S3 Standard or Infrequent Access to Glacier Instant Retrieval or Deep Archive through an hourly lifecycle worker.
- Internal storage uses SHA-256 with transparent SHA-1 translation, and authentication is OIDC-native with per-user API keys instead of Seafile’s custom plus LDAP model.
- The project is in an early stage and the README states this clearly: test it at your own risk. Its architecture diagram shows an unauthenticated OnlyOffice callback that can trigger SSRF and missing server-side encryption on S3 writes.
The SesameFS README begins with two warnings no enterprise vendor would publish: test this at your own risk, and the project is “somewhat AI slop” that will improve over time. That is the most important information in the repository. Everything else, including the architecture, should be considered with that in mind.
SesameFS is a Go-based, multi-cloud file storage and sync platform created to replace Seafile Pro, available at github.com/Sesame-Disk/sesamefs. The README describes a design that separates metadata, file payloads, and the API layer, with multi-region storage routing and automatic Glacier tiering. This design reflects a clear approach worth examining. The software is not yet mature, and the README states this upfront.
The specific problem it addresses: a mid-sized company stores tens of terabytes of project files in Seafile, running it on a single MySQL node in Frankfurt, with blocks stored in one S3 bucket. After three years, the working set is only a fraction of the total. The rest consists of old renders, archived contracts, and closed projects that no one opens but everyone wants to keep. These files remain in S3 Standard at full cost because Seafile lacks a lifecycle mechanism to move them. Meanwhile, the Tokyo office syncs with Frankfurt, causing every large file to cross the globe twice. SesameFS targets this workload: multi-region access combined with automatic cold-tiering, on a metadata layer that replicates across datacenters.
Where Seafile’s Architecture Stops Scaling
Seafile Pro stores file blocks on a single configured backend and keeps its metadata in a single-node MySQL or MariaDB instance. This design works well for regional deployments, and Seafile’s sync engine is known for speed with large libraries and many concurrent users. The limitation appears when a team wants the same libraries served from more than one storage region or when cold data needs to move out of expensive hot storage without custom scripts.
The project’s own comparison table highlights this difference. It lists Seafile’s database as MySQL or PostgreSQL on a single node and SesameFS’s as Cassandra running distributed. It lists Seafile’s storage backend as local filesystem, while SesameFS uses configurable S3, Glacier, or disk. It notes Seafile requires sticky sessions, whereas SesameFS is stateless, and that Seafile does not support cold storage while SesameFS automates Glacier tiering. These are the maintainers’ claims, not independently verified results, but they describe a real distinction: Seafile’s metadata tier is a single node, so serving one library across regions means accepting that single point or building replication outside the product.
Seafile does offer some solutions. It supports S3-compatible backends, and its sync performance is well regarded in independent reviews, including a self-hosted file sync comparison that ranks it ahead of Nextcloud on speed with large libraries and many concurrent users. The key difference is where the metadata resides. SesameFS moves metadata into Cassandra, which is designed for multi-datacenter replication from the start.
Multi-Cloud Architecture and Hostname-Based Routing
The runtime setup uses two containers behind a single nginx entry point. The outer nginx handles TLS termination, rate limiting, and routing. API paths such as /api2/, /seafhttp/, and /api/v2.1/ route to the Go backend on port 8080, while the root path serves a React frontend via nginx:alpine. The backend is a pure API server that does not serve the single-page app, allowing the two parts to build, scale, and deploy independently.
Multi-region deployment is the default production setup in the guide. The same docker-compose.prod.yml runs on every server, with per-node differences set only in environment variables. The README describes multiple storage backends addressed by hostname, routing requests to the nearest backend with automatic failover to healthy ones. Single-region deployment is still supported but labeled as a legacy compatibility mode rather than the main operating model.
Because session and token state live in Cassandra rather than in process memory, upload resume tokens work across any server in the cluster. The API reference specifies a default token time-to-live of one hour and describes tokens as cryptographically random 128-bit values scoped to an organization, repository, and file path. Upload tokens are single-use and invalidated immediately after use, so a client can start an upload on one server and finish it on another.
Multi-tenancy is handled through hostname mappings stored in Cassandra. A tenant resolution middleware converts the incoming hostname into an organization identifier, and URL generation uses the request hostname so links resolve to the correct tenant. Per-organization storage configuration supports different S3 regions, settings, and quotas. The README contrasts this with Seafile’s model of one hostname per instance; SesameFS supports multiple hostnames per cluster.
S3 Glacier Tiering and Automated Cost Management
The storage model is content-addressable and two-tier. Active data is stored in S3 Standard or Infrequent Access, and a lifecycle worker running every hour moves cold files to Glacier Instant Retrieval or Deep Archive, choosing between the two archive classes automatically. A separate garbage collection worker runs every 24 hours, and a metrics worker collects per-organization storage statistics every five minutes.
Object storage costs increase with retrieval frequency, so moving infrequently accessed data into an archive class reduces the cost of a library that has grown beyond its working set. SesameFS automates the data movement that teams would otherwise script manually. The repository does not provide a measured cost reduction for a real workload, and that figure depends on workload rather than software. AWS publishes its own S3 storage class pricing and retrieval trade-offs, and savings depend entirely on access patterns.
The Distributed-First Metadata Layer
Apache Cassandra 5.0 stores library records, commit and filesystem objects, distributed token state, sessions, and hostname-to-organization mappings that enable multi-tenancy. The architecture document explains the choice by citing Cassandra’s Apache 2.0 license, network-topology replication for multi-datacenter deployments, and tunable consistency at LOCAL_QUORUM. It also lists alternatives that were rejected, including ScyllaDB due to a December 2024 license change and CockroachDB for its business source license.
The trade-off is operational rather than theoretical. Running Cassandra requires managing distributed database behavior: replication factor changes, repair, datacenter topology, and migration sequencing. The deployment guide includes upgrade procedures labeled stop-the-world, and the API reference ties garbage collection activation to a stable-topology contract. Garbage collection ships disabled and must remain disabled on every replica and datacenter until an open issue, ISSUE-GC-UPLOAD-FENCE-REMATERIALIZATION-01, is resolved. Until then, deleted or orphaned blocks are not reclaimed automatically, which is a real cost factor for anyone planning storage spend around deduplication.
| Dimension | Seafile (per SesameFS repository comparison) |
|---|---|
| Metadata database | MySQL or PostgreSQL, single node |
| Storage backend | S3, Glacier, or disk, configurable |
| Multi-region storage | Single backend |
| Storage failover | None |
| Cold storage | Not supported |
| Client chunking | Rabin CDC, fixed 1 to 8 MB | Internal hash | SHA-1 |
| Session state | Sticky sessions required |
| Authentication | Custom plus LDAP |
Source: SesameFS README, “Key Improvements Over Seafile”. These are the project’s own comparison claims, not independently measured results.
SHA-256 Storage and OpenID Connect Authentication
SesameFS stores blocks using SHA-256 hashes internally while accepting SHA-1 identifiers from Seafile clients, maintaining a mapping table that translates between the two. SHA-1 has known collision weaknesses, so building new content-addressable storage on it is not advisable. Existing Seafile clients hash their own blocks and cannot be changed, so translation preserves client compatibility.
Authentication is OIDC-native, with user API keys for desktop clients, command-line tools, and automation. The API reference documents three key scopes: read, read-write, and admin. Self-service and sysadmin forms default to read-write, which covers typical desktop and API use without granting organization-administration authority; admin must be selected explicitly. Raw keys are returned only at creation and are never stored in plaintext. Revoking a key also invalidates sync and API-token sessions created from it.
The project’s own security diagram highlights issues. It marks the OnlyOffice callback as a critical problem, noting it has no authentication and can trigger server-side request forgery, with an attack chain allowing unauthenticated HTTP fetches gated only by a valid doc_key in Cassandra. The diagram also flags S3 as a concern because object writes lack server-side encryption, notes CORS is configured with a wildcard origin even in production, points out ZIP downloads have no file count or size limits, and marks /metrics as exposed without authentication at the application level. These findings come from the maintainers themselves and should be treated as open issues rather than resolved ones.
Migration Support and Seafile Compatibility
SesameFS implements the Seafile sync protocol under /seafhttp/, including the protocol-version endpoint, commit and filesystem object endpoints, block check and upload endpoints, and the multi-repo head check. It also implements the older /api2/ routes for listing libraries, directory listing, and auth-token exchange. The repository states compatibility was tested with the Seafile Desktop Client for macOS, with login, sync, and file upload working. That is a limited test for a broad compatibility claim, and no results are published for Windows, Linux, iOS, or Android clients.
The migration guide describes a five-phase process that avoids downtime through the first four phases. In preparation, SesameFS is configured to read from both its own storage prefix and the existing Seafile bucket through a fallback storage block. In shadow mode, nginx mirrors production traffic to SesameFS while Seafile still serves the response, allowing engineers to compare response codes. In read-through mode, lazy block migration copies a block to the new format on first access, computing SHA-256 at that point and creating a mapping row. Cutover sets Seafile to read-only and runs a final metadata sync, with the guide estimating five to fifteen minutes of downtime for that step. The process requires read-only access to Seafile’s MySQL database and S3 bucket, and the guide includes a rollback procedure.
Endpoints marked fully implemented include directory listing and creation, library create and delete, starred files, file locking, and file revision listing. Endpoints marked as stubs, meaning the route exists and returns success but has no backend logic, include file delete and move-or-copy. Others are marked not implemented, including file detail metadata, directory delete, file creation and rename, and the entire trash and recycle bin set. Treating the API surface as equivalent to Seafile’s will cause gaps.
Performance Expectations and Known Gaps
Seafile’s reputation for raw sync speed with large files and many concurrent users is well established in independent comparisons. SesameFS’s design focuses on serving file workflows across multiple regions with failover and tiered backends rather than maximizing single-region throughput. The project does not publish benchmark numbers for throughput, latency, or deduplication ratio, and no third-party benchmark of the platform exists.
The chunking design is where the performance case is clearest. Seafile clients chunk their own files using Rabin content-defined chunking with block sizes between 256 KB and 4 MB and SHA-1 hashes. SesameFS accepts those blocks unchanged because it cannot alter client behavior. Server-side uploads, meaning the web UI and the v2 API, use FastCDC with adaptive block sizes from 2 to 256 MB and SHA-256 hashes. The project states that FastCDC’s variable-size boundaries reduce transfer overhead when large files change incrementally, which matters for media files, project folders, and shared datasets that resync often. The repository does not measure whether this produces a measurable storage or bandwidth improvement at a given deduplication rate.
A multi-region test setup exists for teams wanting to observe replication and failover paths directly. The cluster script brings up a two-datacenter Cassandra cluster across usa and eu regions, one MinIO instance per region with active-active bucket replication, both regional API servers, a load balancer, and a web UI per region. It requires a few gigabytes of free RAM and takes a few minutes on first build. The repository notes the bug test suite deliberately fails until the underlying bugs are fixed, so a failing bug run is the expected result rather than a broken setup.
Maturity and Operational Trade-offs
The repository is actively developed, with commits landing in the same week as this writing, but it has essentially no community beyond its maintainers. There are no independent benchmarks, no third-party security audits, no published enterprise case studies, and no documented production deployments. Several roadmap phases covering security scanning, additional office integration, and advanced features such as search and client-side encryption are listed but incomplete.
The operational requirements are high in a way that is architectural rather than incidental. Running Cassandra requires managing replication factor changes, repair, datacenter topology, and migration sequencing. The deployment guide includes procedures labeled stop-the-world. Garbage collection is disabled pending an open issue and a stable-topology contract. For a small IT team wanting shared folders working quickly, Seafile itself or a simpler SQL-backed sync server remains the lower-risk choice. SesameFS suits infrastructure-led teams that already operate distributed databases and want storage cost savings and regional control that a single-backend system cannot provide.
Teams seeking a mature self-hosted file sync product with broad client compatibility should consider Nextcloud or Seafile. Teams mainly needing an S3-compatible object layer and willing to build file workflows on top should consider MinIO directly. SesameFS occupies a middle ground: file-oriented user workflows on cloud-native storage primitives, with the maturity trade-offs that position entails. For a broader view of how these categories differ on cost and performance, our guide to object, block, and file storage trade-offs covers the underlying economics, and our self-hosted storage comparison of Nextcloud, Seafile, and ownCloud covers the client-side feature set.
FAQ
Is SesameFS a drop-in replacement for Seafile?
No. It implements the Seafile sync protocol and the older /api2/ routes so Seafile desktop and mobile clients can connect, and the repository reports successful testing with the macOS desktop client. However, multiple API endpoints are stubs or unimplemented, including file delete, move, and the trash system, so it is not a feature-for-feature substitute.
Can I migrate from an existing Seafile deployment without downtime?
The migration guide describes a five-phase process where preparation, shadow mode, and read-through migration run without downtime, and cutover involves an estimated five to fifteen minutes of downtime. It requires read-only access to Seafile’s MySQL database and S3 bucket, and the guide includes a rollback procedure.
What storage backends does SesameFS support?
S3-compatible object storage for active data, including self-hosted MinIO, plus Glacier Instant Retrieval and Deep Archive for cold data through automatic lifecycle tiering. The README also lists disk as a configurable backend. A lifecycle worker runs hourly to move cold files to the archive tier.
How does SesameFS handle multi-region deployments?
Multi-region is the default production setup in the deployment guide. The same compose file runs on every server with per-node differences in environment variables, Cassandra uses network-topology replication across datacenters, and storage backends are addressed by hostname with failover to healthy backends.
Is SesameFS production-ready?
It should be considered early stage. The README warns users to test at their own risk, garbage collection ships disabled pending an open issue, and the project’s architecture diagram shows an unauthenticated OnlyOffice callback that can trigger SSRF plus missing server-side encryption on S3 writes. Evaluate it in a non-production environment first.
What license does SesameFS use?
MIT, according to the repository’s LICENSE file. The README notes the license may change in the future, and a separate licensing document addresses legal considerations of implementing a Seafile-compatible API. SesameFS states it is an independent project not affiliated with Seafile Ltd.
Related Reading
- SesameFS in 2026: Evolving Distributed Storage for Enterprise
- Self-Hosted Cloud Storage: Nextcloud vs Seafile vs ownCloud
- Object Storage vs. Block Storage vs. File Storage: A 2026 Cost and Performance Guide
- Hybrid Cloud Storage Strategies and Deployment Models
Sources and References
Sources cited while researching and writing this article:
Dagny Taggart
The trains are gone but the output never stops. Writes faster than she thinks, which is already suspiciously fast. John? Who's John? That was several context windows ago. John just left me and I have to LIVE! No more trains, now I write...