# any-sync-bundle: self-host Anytype with one Docker command

> The Go project that merges every Anytype sync module into one binary, and what it costs you in scaling options. A look at the install path, the config files that matter, and where it stops being the right tool.

**grishy/any-sync-bundle** — Anytype Bundle: Prepackaged All-in-One Self-Hosting

- Repository: https://github.com/grishy/any-sync-bundle
- Stars: 681 · Forks: 31
- Language: Go
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/grishy-any-sync-bundle

## The deployment problem any-sync-bundle is built to remove

Self-hosting Anytype the official way means running several separate services: a sync node, a consensus node, a coordinator, a filenode, plus MongoDB and Redis behind them. That is a multi-container deployment with its own config surface, and it is the reason most people who want a private Anytype sync server do not finish the job. any-sync-bundle takes those official modules, keeps them as dependencies rather than rewrites, and ships them as one process. The README describes the result as "K3s for Any Sync", which is a fair shorthand: the upstream components are still there, but the packaging and the wiring are done for you.

The target user is stated plainly. Self-hosters who value simplicity over complexity, and low-resource homelab or Raspberry Pi setups. The project also states who it is not for: anyone needing high-availability clustering across nodes, anyone needing horizontal scaling beyond a single server, and anyone who wants the official Anytype architecture as-is. That last exclusion is the honest one. This is a repackaging, so if your requirement is fidelity to the upstream topology, the bundle is the wrong artifact by design.

## How the bundle collapses several services into one binary

The Go module file shows what is actually inside. The direct dependencies include any-sync, any-sync-consensusnode, any-sync-coordinator, any-sync-filenode and any-sync-node, all at 0.13.x, plus the mongo-driver, go-redis, and BadgerDB v4. So the binary links the official modules and runs them together rather than proxying to them.

Storage has two modes. The default is embedded BadgerDB, which the README lists as zero configuration, no external dependencies, lower latency, and limited by local disk space. The optional mode uses what the README calls the original Anytype upstream S3 implementation from any-sync-filenode, and it names AWS S3, MinIO, DigitalOcean Spaces, Cloudflare R2 and Backblaze B2 as targets. That is a real trade: S3 buys you capacity beyond the local disk and costs you network latency plus configuration work.

Network surface is deliberately small. TCP 33010 carries DRPC and UDP 33020 carries QUIC. Two ports, one TCP and one UDP, which is why the Dockerfile exposes exactly those and nothing else. The all-in-one image is built on redis/redis-stack-server and installs MongoDB 8.0 into the same image; the minimal image is distroless and expects you to supply MongoDB and Redis yourself.

Versioning is worth understanding before you pull anything. Tags follow the format v[bundle-version]-[anytype-compatibility-date], so v1.6.0-2026-08-18 means bundle SemVer 1.6.0 with an anytype any-sync compatibility date of 2026-08-18, derived in UTC from Anytype's published compatibility list. The README also states that bundle configuration format 1 remains readable across 1.x releases, which is the compatibility promise that matters when you upgrade.

## Installing any-sync-bundle and importing the client config

The fastest path is the single docker run from the README. Replace the address with your server's LAN IP for local-only access, your public domain for remote access, or both comma-separated. The stop timeout of 120 seconds is not decorative: the container is given time to shut down cleanly.

```bash
docker run -d \
    -e ANY_SYNC_BUNDLE_INIT_EXTERNAL_ADDRS="192.168.100.9" \
    -p 33010:33010 \
    -p 33020:33020/udp \
    -v $(pwd)/data:/data \
    --stop-timeout 120 \
    --restart unless-stopped \
  ghcr.io/grishy/any-sync-bundle:1.6.0-2026-08-18
```

After the first run, the README says to import ./data/client-config.yml into your Anytype apps. That file is regenerated on every start, so it is not something to back up. The file that is worth backing up is ./data/bundle-config.yml, which holds service configuration and private keys. The README marks it red for backup and the client config green.

If you prefer Compose, the repository ships four files: compose.aio.yml for the all-in-one image with embedded MongoDB and Redis, compose.external.yml for the bundle plus external MongoDB and Redis containers, compose.s3.yml for the bundle plus MinIO, and compose.traefik.yml for a Traefik reverse proxy. The README says to edit ANY_SYNC_BUNDLE_INIT_EXTERNAL_ADDRS in the compose file before starting.

```bash
docker compose -f compose.aio.yml up -d
```

There is also a binary path, but only with external MongoDB and Redis. Download from the release page and run it with the external addresses plus your Mongo and Redis URIs.

```bash
./any-sync-bundle start-bundle \
  --initial-external-addrs "192.168.100.9" \
  --initial-mongo-uri "mongodb://127.0.0.1:27017/" \
  --initial-redis-uri "redis://127.0.0.1:6379/" \
  --initial-storage ./data/storage
```

The configuration reference lists nine ANY_SYNC_BUNDLE_INIT variables plus AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for S3. Only ANY_SYNC_BUNDLE_INIT_EXTERNAL_ADDRS is required. The README notes that all ANY_SYNC_BUNDLE_INIT variables are taken into account on start and later baked into the config, so changing one after first boot is not the same as changing it before.

## The single-node ceiling and the backup file you cannot lose

The scaling limits are stated by the project, not inferred. No high-availability clustering across multiple nodes. No horizontal scaling beyond a single server. If your spaces grow past what one machine's disk and one process can serve, the bundle does not have an answer; S3 storage moves the file payload out but the coordination, consensus and sync roles still run in one process on one host.

The backup story is the second sharp edge. bundle-config.yml contains the private keys, and it is the only file the README flags as needing a backup. Lose it and the configuration that identifies your deployment is gone. There is no documented rollback procedure in the README, and no documented migration path between major bundle versions beyond the statement that format 1 stays readable across 1.x. If you are planning a multi-year deployment, that is a gap you should notice before you commit, not after.

Operational hygiene around the init variables is a third. Because they are baked into the config on start, a running deployment does not simply pick up a changed environment variable. The README does not describe what happens to an existing config when an init variable changes, so treat first-run configuration as the decision point.

Finally, exposure. TCP 33010 and UDP 33020 are the whole attack surface, and the README offers a Traefik compose file for reverse proxying. It does not document TLS termination or authentication at the bundle layer, so anything you put in front of those ports is your responsibility.

## When to run the official Anytype deployment instead

The direct alternative is the official Anytype self-hosting architecture that any-sync-bundle repackages. The difference is not features, it is topology. Upstream gives you the individual modules as separate services, which is what you want if you intend to scale a node out, place MongoDB and Redis on dedicated hosts, or reason about each service's resource envelope independently. The bundle gives you those same modules in one process with one config file and two open ports.

There is a middle option inside the project itself: the minimal image and compose.external.yml keep the bundle binary but move MongoDB and Redis into their own containers. That gets you external data services without adopting the full upstream service split. If your objection to the all-in-one image is only that you do not want a database inside the same container as the sync process, this is the configuration to use, and it is the same binary.

For a homelab with a handful of users, the trade is straightforward. You give up independent scaling of each role and you take on the constraint that one process serves everything. In exchange you get a deployment that is one command and a config file you can read.

## Maintenance, licensing and what upgrades actually involve

The last push to the repository was on 2026-08-31, and the most recent release in the list is v1.6.0-2026-08-18, published on 2026-08-25. Earlier releases are v1.5.0-2026-07-17 and v1.4.3-2026-04-21, so the cadence over the visible window is roughly one release every month or two, with the tag date tracking Anytype's compatibility list rather than the project's own calendar.

That versioning scheme is the maintenance cost you should price in. Because the tag embeds the anytype compatibility date, upgrading the bundle is partly a question of which Anytype client versions the new compatibility date covers. The README points at Anytype's published compatible-versions endpoint as the source for that date. Pinning an explicit version tag, which the README recommends over :latest, means you decide when to move. It also means you own the check that your clients still work after the move.

The licence is MIT. That permits modification and redistribution, and the repository includes the LICENSE file at the top level. Nothing in the README describes additional terms, trademark restrictions or a separate commercial licence. This is not legal advice; if you plan to redistribute the image or bundle it into a product, read the LICENSE file and the licences of the upstream anyproto modules, which are separate dependencies rather than part of this repository.

Building from source is supported through the Dockerfile, which is a multi-stage build: a Go 1.27.0 alpine stage with module and build caches, then either a distroless static image or the all-in-one image. Go 1.27.0 is the toolchain declared in go.mod.

## Conclusion

Adopt it if you are a homelab or Raspberry Pi self-hoster who wants an Anytype sync server on one machine and accepts a single-node ceiling. Do not adopt it if you need high-availability clustering or horizontal scaling, which the README lists as reasons it is not for you. Before you switch any client over, verify that ./data/bundle-config.yml exists and is backed up, that TCP 33010 and UDP 33020 are reachable from your clients, and that the version tag you pulled matches an anytype compatibility date your Anytype app accepts.

## FAQ

### How do I install any-sync-bundle with Docker?

Run the single docker run command from the README with ANY_SYNC_BUNDLE_INIT_EXTERNAL_ADDRS set to your LAN IP or public domain, mapping TCP 33010 and UDP 33020 and mounting a volume at /data. Then import ./data/client-config.yml into your Anytype apps. Compose files are also provided for all-in-one, external, S3 and Traefik setups.

### Which any-sync-bundle image tag should I use?

Tags follow v[bundle-version]-[anytype-compatibility-date], for example 1.6.0-2026-08-18. The README recommends explicit version tags over :latest so you control when you update. The all-in-one tag embeds MongoDB and Redis; the -minimal tag expects you to run those yourself.

### Which files does any-sync-bundle need me to back up?

The README marks ./data/bundle-config.yml as requiring backup because it holds service configuration and private keys. ./data/client-config.yml is regenerated on each start and does not need backing up.

### Can any-sync-bundle scale across multiple servers?

No. The README lists high-availability clustering across multiple nodes and horizontal scaling beyond a single server as reasons the project is not for you. S3 storage moves file payloads to external object storage, but the sync roles still run in one process.

## Sources

- [grishy/any-sync-bundle on GitHub](https://github.com/grishy/any-sync-bundle)
- [Issues](https://github.com/grishy/any-sync-bundle/issues)
- [License: MIT](https://github.com/grishy/any-sync-bundle/blob/main/LICENSE)
- [README](https://github.com/grishy/any-sync-bundle/blob/main/README.md)
- [Releases](https://github.com/grishy/any-sync-bundle/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/grishy-any-sync-bundle