Sync-in/server: a self-hosted file platform that keeps files readable on disk
Sync-in · Sovereign platform for file storage, sharing, synchronization, and collaboration.
At a glance
- What is it?
- Sync-in/server is an AGPL-3.0 TypeScript server for storage, sync, sharing and document collaboration, distributed via Docker and npm. Its design promise is that files stay readable on the filesystem instead of being wrapped in an opaque object store, and the README lists WebDAV, OIDC, LDAP, quotas and Collabora or OnlyOffice integration as shipped features.
- Who is it for?
- Adopt Sync-in/server if you want a private file workspace whose storage you can inspect with ordinary filesystem tools and whose clients include a desktop app, a CLI and WebDAV. Do not adopt it if you need a mature third-party app ecosystem or you cannot accept the AGPL-3.0 network copyleft.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- 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 problem Sync-in/server addresses: file ownership without an opaque store
Most self-hosted file platforms solve sharing by taking ownership of your bytes. Files land in a database-backed store or a content-addressed tree, and the only way to read them is through the application. That is fine until the application is unavailable, the schema changes between versions, or you want to rsync a directory to a backup host. Sync-in/server positions itself against that pattern. The README states the project is "designed to stay fast, lightweight, and centered on your data, keeping files readable on your filesystem while adding collaboration features only where they are needed." That sentence is the whole design thesis. The primary audience is the homelab and small-team operator who already runs a reverse proxy, a database and a container runtime, and who wants Dropbox-style sharing and sync without handing the storage layer to a vendor. The topics list confirms the framing: homelab, on-premise, private-cloud, cloud-alternative, nextcloud. The last one is a positioning statement as much as a keyword.
What the feature list actually covers, and what it leaves unspecified
The README enumerates a wide surface. On the file side: drag and drop, smart clipboard, gallery view, sorting, filtering, previews, quotas, trash retention, file protection tools and folder anchoring without duplication. On the identity side: local accounts, OIDC, LDAP, MFA, recovery codes and application passwords. On the collaboration side: spaces, shares, guests, personal groups, roles, fine-grained permissions, protected public links with access limits, expiration dates and passwords, comments, notifications, file locking and activity tracking. Search is full-text with indexing of document content across common office formats. Editing is delegated to Collabora Online, OnlyOffice or Euro-Office. Sync reaches clients through WebDAV and through separate desktop and CLI applications for Windows, macOS and Linux, which the README says support multi-server synchronization workflows. That is a lot of ground, and the README gives no architecture diagram, no storage schema and no statement about which database the server expects. The npm package name is @sync-in/server and the Docker image is syncin/server, so both install paths are official. Everything beyond that has to come from the documentation site, which is linked but not reproduced here.
Folder anchoring and the readable-filesystem claim
The most consequential item in the feature list is easy to skim past: "folder anchoring without duplication." A platform that lets one folder appear in several places without copying bytes has to maintain a mapping between logical paths and physical ones. The README does not explain whether that mapping lives in a database, in extended attributes, or in symlinks. This matters because it determines what happens when you move a file with a shell command instead of through the web interface. If the mapping is database-backed, an out-of-band move breaks the reference. If it is symlink-based, a naive backup tool may follow the link and duplicate the data, or skip it entirely. The claim that files stay readable on your filesystem is credible for ordinary uploads, since nothing in the README suggests encryption at rest. It is less obviously true for anchored folders, and that is the first thing to test on a scratch instance before trusting the platform with a real directory tree.
Getting it running: Docker and npm are the two documented paths
The README links a Docker setup guide and an npm setup guide rather than embedding commands, so the exact invocation is not in the material reviewed here. What is confirmed: the published image is syncin/server on Docker Hub, and the published package is @sync-in/server on npm. A deployment therefore starts from either a container run against that image or an npm install of that package. The feature list implies the surrounding dependencies you will have to supply yourself: a database for accounts, shares, permissions and the search index, plus a Collabora Online, OnlyOffice or Euro-Office instance if you want in-browser editing. WebDAV support means the HTTP layer has to accept methods beyond GET and POST, which is a reverse proxy concern. The README does not state which proxy configurations were tested, so treat method pass-through as a deployment task, not an assumption. The same applies to the OIDC and LDAP paths: the README confirms they exist as authentication options but gives no provider matrix.
Where Sync-in/server is the wrong choice
Three cases stand out. First, if your requirement is a large catalogue of third-party apps that read and write the same data (calendars, mail, notes, task boards from independent vendors), Sync-in/server does not claim to offer that. Its collaboration surface is files, comments, notifications and office documents, and the README lists no plugin or app framework. Second, if your organisation cannot accept AGPL-3.0-or-later, this is disqualifying rather than negotiable. The licence applies to the server, and the AGPL network clause means offering a modified Sync-in as a service to others triggers source distribution obligations. That is a real constraint for anyone planning a hosted product on top of it. Third, if you need formal vendor support with an SLA, the README points to GitHub Issues, GitHub Discussions and Discord. Those are community channels. There is a sponsorship programme and a registered trademark policy, but no commercial support tier is described in the material.
How it differs from Nextcloud, and why the gap is not only about features
Nextcloud is the obvious comparison, and the README's own topic list invites it. The difference in approach is architectural emphasis. Nextcloud is a platform with an app store, a broad set of first-party groupware components and a long release history; its surface area is the point. Sync-in/server is narrower by design, and the README frames that narrowness as a performance and ownership argument: keep the data on the filesystem, add collaboration only where needed. That trade runs in both directions. You get a smaller attack surface and a filesystem you can inspect. You give up the app ecosystem and the accumulated operational knowledge that comes with a widely deployed platform. For a homelab operator who wants file sync, WebDAV and document editing and nothing else, the narrower target is a reasonable fit. For an organisation that expects to bolt on calendar, contacts and mail later, it is not.
Maintenance, release cadence and licence obligations
The release history shows v2.5.0 on 2026-09-02, preceded by v2.4.4 on 2026-07-25 and v2.4.3 the day before that. That pattern suggests active development with patch releases between minor bumps, and the last push to the default branch is dated 2026-09-09. The practical upgrade cost is the usual one for a self-hosted server with a database: back up the database and the storage tree, read the release notes for migration steps, and expect the Collabora or OnlyOffice integration to be the fragile part when either side changes. The README does not describe a migration tool or a supported upgrade path between major versions, so that is unverified. On licensing: AGPL-3.0-or-later governs the server code, and Sync-in is a registered trademark with a separate policy linked from the README. If you plan to modify and redistribute, or to expose a modified instance to third parties, read the licence text and the trademark policy before you start. This is a description of what the repository states, not legal advice.
Editorial conclusion
Adopt Sync-in/server if you want a private file workspace whose storage you can inspect with ordinary filesystem tools and whose clients include a desktop app, a CLI and WebDAV. Do not adopt it if you need a mature third-party app ecosystem or you cannot accept the AGPL-3.0 network copyleft. Before committing, verify three things against your own deployment: that your reverse proxy passes WebDAV methods, that your storage backend survives the folder anchoring feature, and that your Collabora or OnlyOffice instance is reachable from the Sync-in container.
Community notes