**What**
any-sync: the self-hosted backend for Anytype (https://anytype.io), a local-first knowledge base / Notion alternative. The desktop and mobile clients run on your own devices; what would be packaged is the sync node they talk to.
**Why this one is worth the effort**
Anytype without a sync node gives you two options, and both are bad for a StartOS user:
1. Anytype's own network — works, but it is the vendor's infrastructure and a paid subscription (~$10/month) once you pass the free storage tier. I hit that tier with a single imported workspace (2 GB of attachments).
2. "Local-only" mode — no vendor involvement, but multi-device sync is then peer-to-peer over the LAN only, and in my testing it does not work: pairing a phone by QR is accepted, then sync never starts. I have wire-level evidence (TCP established, ~4 KB handshake, then keepalives only, desktop reporting "No devices connected") and I am filing that upstream separately.
So today, if you want Anytype on more than one device without paying a subscription, there is no reliable route. A self-hosted any-sync node on StartOS is exactly that route, and it is precisely the shape of problem StartOS exists to solve.
**There is currently no Notion-style personal knowledge base in either registry**
I surveyed both registries by JSON-RPC before asking (2026-08-29): **54 packages in the official registry, 75 in the community one.** Neither contains anything that fills this role.
The nearest things, and why each is not it:
- nextcloud: the closest, and genuinely capable with the Collectives and Tables apps. But it is a large groupware suite, and its UX is a long way from a personal knowledge base. I tried this route first and gave up on it.
- papra, paperless-ngx: document archives with OCR. Good at filing PDFs, not at writing and linking notes.
- forgejo, gitea: have wikis, but a git forge is not a note-taking tool.
- ghost: publishing, not personal notes.
- vikunja: tasks and projects, no documents.
- archivebox, filebrowser: link archiving and file browsing respectively.
So this is not "another one of those" — it is a category with **zero** coverage today, and one that a lot of people are actively looking to de-Google/de-SaaS. Notion, Evernote, Obsidian Sync and Roam are all cloud subscriptions; a self-hosted sync node for a local-first client is the natural StartOS answer, and Anytype is the most mature client in that shape.
**Licensing: no obstacle, and this is worth stating up front**
- **any-sync (the server, i.e. the part that would be packaged) is MIT.**
https://github.com/anyproto/any-sync
- The clients are under the "Any Source Available License 1.0", which explicitly permits use, modification AND redistribution for Non-Commercial Use (defined to include personal use).
For contrast: I looked at AFFiNE for the same job and it is not packageable, its server is under an Enterprise Edition licence that forbids redistribution outright. Anytype has no such problem.
**There is a reference implementation**
https://github.com/anyproto/any-sync-dockercompose — MIT, actively maintained, and effectively the spec. It is the upstream's own deployment.
**Being honest about the size**
This is not a small package. The compose stack runs roughly eleven containers:
- MongoDB
- Redis (redis-stack-server)
- MinIO (+ a bucket-creation job)
- any-sync-coordinator (+ a bootstrap job)
- any-sync-filenode
- any-sync-node x3
- any-sync-consensusnode
- any-sync-tools (netcheck)
Upstream's README asks for ~1 GB RAM, which understates the operational surface. I would rather say that plainly than have someone discover it after starting.
**What I can offer**
I am a StartOS user, not a packager. I am happy to test builds, provide logs, and report back in detail/ I have already done fairly thorough diagnostic work on the client side and I am comfortable with ss/lsof/journalctl and reading upstream source.
Environment: StartOS 0.4.0.1, x86_64. Anytype desktop 0.56.5, Android client, currently running local-only with no server involvement.
I would recommend any packaging requests should be submitted to the authors of said software. They are best equipped to do so. We make it easy for anyone to package software for StartOS, and these days AI can do most of the work.
@marco You can sideload from here: Release 0.13.1:0 · stupleb/anytype-startos · GitHub
Backup restores with files is something that needs to be tested.
I also found it doesn’t work to add the config.yml and then recover an existing vault associated with the anytype.io servers. You instead need to create and entirely NEW vault and go through the process of exporting and importing the content, which also needs testing.
@StuPleb — this is a much bigger answer than I expected. Thank you.
I have not installed it, but I did read the wrapper’s README, and it is clearly not a quick repackage. Awesome. Would you submit it to the community registry?
I am asking because of a self-imposed rule rather than any doubt about your work: I do not sideload onto my server. The box runs things I depend on, and an .s9pk from outside a registry is a binary I cannot meaningfully review myself. What the submission process adds is exactly the part I cannot do, an independent build and safety review.
And right now the registry has no personal-knowledge-base package at all, which is what started this thread.
If it does reach Beta, I will test it and report back properly. I have a real workload for it rather than a toy: a Notion workspace imported into Anytype, 2.8 GB vault, and I have already done an Export Channel => Any-Block => Import round-trip and verified it restores intact, which is the exact migration path your README prescribes.
Environment: StartOS 0.4.0.1, x86_64. Anytype desktop 0.56.5 and the Android client.
I’m not sure there’s all that much difference where I upload the file, if I review it and then upload it to the community registry, it’s the exact same file I’d upload. The registry is a set of links to *.s9pk files. It’s currently running on my server, which has things I rely on. This is safe to do so because on StartOS services sit in their own containers. If a service is buggy, it’s that service that is affected, not others.
For now then, this service will go untested and unlisted, unless there are any other users who would like to give it a shot.