any-sync-bundle: Self-Hosting Anytype Sync in One Container
Anytype Bundle: Prepackaged All-in-One Self-Hosting
At a glance
- What is it?
- The project packages every Anytype sync module into a single Go binary with embedded MongoDB and Redis, cutting a multi-service deployment down to two open ports. It is a good fit for a homelab box and a poor fit for anyone who needs more than one server.
- Who is it for?
- Adopt it if you are running a single homelab host or a Raspberry Pi and want Anytype sync without assembling MongoDB, Redis and the individual any-sync services yourself. Do not adopt it if you need high-availability clustering or horizontal scaling across nodes, which the README explicitly lists as out of scope.
- Can I use it commercially?
- Yes. MIT 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 Go, 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 Deployment Problem Anytype Self-Hosting Creates
Self-hosting Anytype through the official route means running several any-sync services alongside MongoDB, Redis and a file node, then keeping their configuration consistent. The README describes the bundle as merging all official Anytype sync modules into a single binary, and positions it as K3s for Any Sync. That comparison is the clearest statement of intent in the repository: it is not trying to be the reference architecture, it is trying to be the smaller thing you can actually finish installing.
The target user is named directly. Self-hosters who value simplicity over complexity, and low resource homelab setups including Raspberry Pi deployments. The inverse list is just as explicit: anyone who needs high-availability clustering across multiple nodes, horizontal scaling beyond a single server, or the official Anytype architecture as-is should look elsewhere. Two open ports carry the whole service, TCP 33010 for DRPC and UDP 33020 for QUIC. That constraint tells you what kind of deployment this is. Everything terminates on one host.
What the Binary Actually Contains
The all-in-one image embeds MongoDB and Redis, so the sync modules, the coordination layer and the datastore all live in one process tree inside one container. A separate minimal image ships the same bundle without those embedded services, expecting external MongoDB and Redis URIs instead. The same split appears in the compose files: compose.aio.yml is the embedded variant, compose.external.yml brings its own MongoDB and Redis containers.
Storage has two modes. By default the bundle uses embedded BadgerDB, and the README lists the trade-off plainly: zero configuration and lower latency against being limited by local disk space. The optional S3 path reuses the original Anytype upstream S3 implementation from any-sync-filenode, which the README says works with AWS S3, MinIO, DigitalOcean Spaces, Cloudflare R2 and Backblaze B2, at the cost of network latency and configuration work. There is no third mode, and there is no sharding story. One bundle, one storage backend.
The versioning scheme is worth understanding before you pin anything. Release tags follow v[bundle-version]-[anytype-compatibility-date], so v1.6.0-2026-08-18 means bundle SemVer 1.6.0 paired with an any-sync compatibility date of 2026-08-18, derived in UTC from Anytype's published compatibility list. The README states that bundle configuration format 1 remains readable across 1.x releases. That is a promise about config compatibility, not about the sync protocol, which moves with the date portion of the tag.
Getting It Running: The Single Docker Command
The README's TL;DR is a docker run invocation. You replace the address placeholder with your server's local IP for LAN-only access, your public domain for remote access, or both comma-separated. The container maps TCP 33010 and UDP 33020, mounts ./data, and sets a stop timeout of 120 seconds with restart unless-stopped. The stop timeout is not decorative: the README includes it in the canonical command, which suggests the services need time to shut down cleanly.
After the first run you import ./data/client-config.yml into the Anytype apps, following the client setup instructions linked from the README. If you prefer compose, the repository ships four files: compose.aio.yml, compose.external.yml, compose.s3.yml and compose.traefik.yml. The README instructs you to edit ANY_SYNC_BUNDLE_INIT_EXTERNAL_ADDRS in the compose file before starting, then run docker compose -f <file> up -d.
The binary path exists too, but only with external MongoDB and Redis. It takes --initial-external-addrs, --initial-mongo-uri, --initial-redis-uri and --initial-storage flags. Note the naming pattern: every ANY_SYNC_BUNDLE_INIT* variable is read at start and then baked into the configuration, so changing one later means regenerating config rather than flipping a runtime switch. S3 setup adds ANY_SYNC_BUNDLE_INIT_S3_BUCKET, ANY_SYNC_BUNDLE_INIT_S3_ENDPOINT, ANY_SYNC_BUNDLE_INIT_S3_REGION (default us-east-1), ANY_SYNC_BUNDLE_INIT_S3_FORCE_PATH_STYLE for MinIO, plus AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. ANY_SYNC_BUNDLE_INIT_FILENODE_DEFAULT_LIMIT sets the per-space storage limit in bytes.
Two Config Files, One of Which You Must Back Up
The README's configuration table makes the backup question unambiguous. ./data/bundle-config.yml holds service config and private keys, and is marked as requiring backup. ./data/client-config.yml is regenerated on every start and does not. If you lose the data directory without a copy of bundle-config.yml, you lose the keys the services identify themselves with. That is the single operational fact most likely to bite someone who treats the container as disposable.
Upgrades are framed as a deliberate act. The README notes that :latest and :minimal tags exist but recommends explicit version tags, with the reasoning that you should update on your own schedule. That advice fits the versioning model: the date suffix tracks Anytype's any-sync compatibility, so a client that has moved to a newer any-sync version may not talk to an older bundle. The README does not describe an in-place migration procedure or a rollback path beyond restoring your data directory, and I could not confirm from the supplied material whether downgrading across compatibility dates is supported. Treat the version tag as a compatibility contract you check before pulling.
Licensing is MIT, which places few restrictions on use, modification or redistribution. The README does not discuss what that means for the upstream Anytype components it incorporates, and nothing in the material addresses trademark or attribution obligations for the bundled services. If you plan to redistribute a modified image, that is a question for your own review rather than something this repository answers.
Where a Single-Node Bundle Stops Being the Right Answer
The README's own exclusion list is the honest limitation. No high-availability clustering across multiple nodes, no horizontal scaling beyond a single server. A single container with embedded MongoDB and Redis is a single point of failure by construction. If that container's host goes down, sync stops for every client until it comes back. There is no replica set underneath, because the embedded datastore is not a cluster.
The minimal image and compose.external.yml soften this only partly. Pointing the bundle at external MongoDB and Redis lets you run those as managed or replicated services, but the bundle itself remains one process on one machine. You have moved the durability question, not the availability question.
Storage is the second boundary. Local BadgerDB is capped by local disk, and the README says so directly. S3 removes that ceiling but adds latency and a dependency on an external object store. The per-space limit is set through ANY_SYNC_BUNDLE_INIT_FILENODE_DEFAULT_LIMIT in bytes, which is a quota, not an expansion mechanism. If your use case is a handful of people syncing notes and files, none of this matters. If it is an organisation with uptime expectations, the architecture is the wrong shape and the README says as much before you install anything.
How This Differs From Running the Official Stack
The real alternative is the official Anytype self-hosting architecture, which the README depicts in a side-by-side diagram and describes as requiring the individual sync services plus MinIO and separate logical services. The bundle's stated advantages over that setup are no required MinIO and no duplicate logical services, with the services collapsed into one binary.
The difference is not cosmetic. In the official layout you operate several moving parts and can, in principle, scale or replace them independently. In the bundle you get one artifact with an embedded datastore and two ports, and you give up the ability to grow any component separately. The README frames this as simplicity over complexity, and that framing is accurate: it is a deliberate reduction in operational surface area, paid for with the scaling options listed under Not for you if.
A second, smaller comparison sits inside the project. The all-in-one image against the minimal image is the same trade at a finer grain. Embedded MongoDB and Redis for a single command, or external ones for control over the datastores. Choosing between them is really a question of whether you already run MongoDB and Redis and want to keep them under your own backup and monitoring regime.
Who Should Install This, and What to Check First
This is for the person with one always-on box, a home network, and a preference for finishing the install today. The README's Raspberry Pi mention and its low-resource framing put the intended hardware in plain terms. The single docker run command with an address substituted is genuinely the whole setup, followed by importing client-config.yml into the Anytype apps.
It is not for anyone whose answer to the availability question involves the word cluster, and it is not for anyone who wants the official architecture unchanged. Those are the README's own exclusions, not an inference.
Three things to verify before you commit. First, that the any-sync compatibility date in the release tag lines up with the Anytype client version you intend to connect, since that date is the part of the tag tied to protocol compatibility. Second, that ./data/bundle-config.yml is inside whatever backup routine covers the host, because it carries the private keys and is not regenerated. Third, that TCP 33010 and UDP 33020 are both reachable from your clients, including the UDP path, which is the one people forget when a firewall is involved. Get those three right and the deployment is as small as the README claims.
Editorial conclusion
Adopt it if you are running a single homelab host or a Raspberry Pi and want Anytype sync without assembling MongoDB, Redis and the individual any-sync services yourself. Do not adopt it if you need high-availability clustering or horizontal scaling across nodes, which the README explicitly lists as out of scope. Before committing, verify that your client's any-sync compatibility date matches the date embedded in the release tag, and back up ./data/bundle-config.yml, because that file holds the private keys.
Community notes