# any-sync-dockercompose: a self-hosted Anytype backend you run with Docker Compose

> A Compose stack that stands up a full any-sync network (coordinator, three sync nodes, filenode, consensusnode, MongoDB, Redis, MinIO) for personal use. It is not the path for high-load production, and the README says so.

**anyproto/any-sync-dockercompose** — Deploy your own any-sync network with Docker Compose - self-host Anytype backend

- Repository: https://github.com/anyproto/any-sync-dockercompose
- Website: https://doc.anytype.io/
- Stars: 945 · Forks: 133
- Language: Shell
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/anyproto-any-sync-dockercompose

## The gap any-sync-dockercompose fills

Anytype clients talk to an any-sync network, and a network is not one process. It is a coordinator that tracks spaces and members, several document sync nodes, a filenode backed by object storage, and a consensusnode for conflict resolution. Standing that up by hand means generating matching configs for every daemon, wiring them to MongoDB, Redis and an S3-compatible store, and keeping the versions compatible with each other. The repository exists to collapse that into one Compose project.

The README is explicit about the audience: a self-hosted any-sync network "designed for personal use, review, or testing purposes." It then points readers who need high-load production deployments at the Puppet or Ansible modules instead. That is an unusual amount of honesty in a README, and it should shape how you read the rest of this page. If your goal is a network for yourself, a small group, or a lab, this is the intended tool. If your goal is serving many unrelated users with an uptime target, the project itself redirects you elsewhere.

## What the Compose file actually starts

The stack is defined in docker-compose.yml, and the service list is longer than the name suggests. any-sync-coordinator owns space and member state in MongoDB. Three any-sync-node instances handle document sync, each exposing a TCP port and a separate QUIC port plus an internal API and metrics endpoint. any-sync-filenode stores files and depends on both MinIO and Redis; Redis runs as redis/redis-stack-server with the RedisBloom module loaded, which is a hint that the filenode index relies on probabilistic data structures rather than plain keys.

A consensusnode participates in conflict resolution. A netcheck service periodically probes connectivity across the nodes, so the stack includes its own health monitor rather than leaving that to you. MongoDB runs as a single-member replica set, which is why the container command carries --replSet and why the healthcheck calls rs.initiate. The orchestration detail worth noticing is any-sync-init: it is a build-from-source container that runs once, generates configuration into ./etc/, and every other service waits on it with condition: service_completed_successfully. Config generation is a prerequisite step, not a side effect of startup.

There is also an optional anytype-cli service, commented out in the Compose file, described as an HTTP/gRPC API server for automation. If you want to drive the network programmatically rather than through the desktop client, that is the door, and you have to open it yourself.

## Installing it and connecting a client

Requirements are Docker with the Compose plugin v2 or newer and roughly 1 GB of RAM available. Clone the repository and create your environment file from the template. The README's own steps are these:

```bash
git clone https://github.com/anyproto/any-sync-dockercompose.git
cd any-sync-dockercompose
cp .env.example .env
```

Before starting, decide how clients will reach the host. The default in .env.example binds to localhost only, which is fine for a single machine and useless for a phone on the same LAN. Edit .env directly:

```bash
EXTERNAL_LISTEN_HOSTS="1.2.3.4"
STORAGE_DIR="/mnt/data/any-sync"
ANY_SYNC_DAEMONS_MEMORY_LIMIT=1G
```

The first line sets the externally reachable address, the second moves persistent data off the default ./storage, and the third raises the per-daemon memory limit from its 500M default. Multiple hosts can be listed space-separated, per the commented example in the file.

The repository pins service versions in .env.example, and there is a script that refreshes them from the Anytype API. Running it is optional; skipping it keeps the pinned set.

```bash
./update-versions.sh
docker compose up -d
```

On first run the stack generates configs into ./etc/ and starts everything. When it finishes, the file you need is ./etc/client.yml. Upload that into the Anytype app as your self-hosted network config; the README links to the Anytype docs section on switching between networks. There is no alternative path to client onboarding described here: the generated YAML is the handoff.

If you prefer the Makefile, make start does the same thing with a guard: it refuses to run when .env is missing and tells you to copy the example file. It also runs update-versions.sh quietly first, so make start and the manual sequence are not identical in behaviour.

## The Makefile targets that destroy data

The quick reference is where the operational risk lives. make start, make stop, make restart, make logs, make pull and make down are ordinary. Two targets are not. make upgrade is annotated in the README as a full reset that removes containers and volumes and then starts fresh, and in the Makefile it expands to down, then clean, then start, where clean is docker system prune --all --volumes. That is not scoped to this project: it prunes all Docker data on the host, including images and volumes belonging to unrelated stacks. On a machine that runs other Compose projects, that is a footgun.

make cleanEtcStorage removes the generated ./etc/ directory and the storage directory, with STORAGE_DIR read from .env and falling back to ./storage. Because it deletes the generated configs, the next start regenerates them, which is the intended recovery path when configuration drifts.

The README carries a warning to read the Upgrade Guide in the wiki before upgrading, and given what make upgrade does, that warning is load-bearing rather than boilerplate. The README does not document rollback, and it does not describe a backup procedure for ./etc/ or the storage directory. If your network holds anything you would miss, the backup story is yours to design.

## Resource limits and the scale ceiling

Every any-sync daemon inherits a YAML anchor that sets restart: unless-stopped and a memory limit drawn from ANY_SYNC_DAEMONS_MEMORY_LIMIT, defaulting to 500M per daemon. That default is the clearest signal of intended scale. Five any-sync processes at 500M each, plus MongoDB, Redis and MinIO, is a stack sized for one person or a small group, not for a public network.

The requirement of about 1 GB of RAM available sits oddly next to that arithmetic, and it is worth reading as a floor for starting the stack rather than a comfortable operating budget. The memory limit is per daemon, so raising it multiplies across the daemons rather than applying once. There is no documented guidance in the README on sizing beyond this variable, and no published capacity numbers. Treat any figure you see elsewhere with suspicion.

Redis is configured with --maxmemory set from REDIS_MAXMEMORY and --maxmemory-policy noeviction. That policy means Redis will refuse writes rather than evict, so the filenode's index does not silently lose entries under pressure; the failure mode is an error instead. Redis also runs with --protected-mode no and --appendonly yes, which is consistent with a container-internal service but worth knowing if you expose ports beyond the Compose network.

## Where this is the wrong tool, and what to use instead

The wrong tool for a public or commercial multi-tenant deployment. The README says so directly and names two alternatives: the Puppet module and the Ansible module, both in the anyproto organization. The difference is not cosmetic. Puppet and Ansible modules describe a desired state for machines you manage over time, with idempotent runs, inventory and per-host configuration, which is what a multi-machine deployment needs. Docker Compose describes a set of containers on one host. Running three sync nodes as separate containers on a single machine gives you process isolation, not host isolation: a disk failure or a kernel problem takes the whole network with it.

It is also the wrong tool if you want a managed backend and no operational surface at all. Nothing in this repository removes MongoDB, Redis or MinIO from your life; they are part of the stack you now patch and monitor.

For a different kind of comparison, a general note-taking stack assembled from Docker Compose, such as a Notion-style self-hosted wiki, typically runs one application container plus a database. This project runs nine or more services because an any-sync network genuinely has that many roles: coordinator, three sync nodes, filenode, consensusnode, netcheck, MongoDB, Redis, MinIO. The complexity is intrinsic to the protocol, not padding in the Compose file. That is the honest reason to think twice: you are not choosing a heavier packaging of the same thing, you are choosing to operate a distributed system.

## Maintenance, versions and licence

The repository is not archived, and the last push was on 2026-08-18, which is recent enough that the project is being worked on. Releases track that: v7.2.0 on 2026-08-18, v7.1.0 on 2026-07-24, v7.0.1 on 2026-06-15. Note that the repository version and the service versions are different numbering schemes. The release tag v7.2.0 describes this Compose project; the images it runs are pinned separately in .env.example as ANY_SYNC_NODE_VERSION=v0.13.1, ANY_SYNC_FILENODE_VERSION=v0.13.0, ANY_SYNC_COORDINATOR_VERSION=v0.13.0 and ANY_SYNC_CONSENSUSNODE_VERSION=v0.13.0, alongside MONGO_VERSION, REDIS_VERSION and MINIO_VERSION.

That split is the main maintenance cost. ./update-versions.sh refreshes the ANY_SYNC_*_VERSION variables from the Anytype API so the daemons stay on a compatible set. make start runs it automatically, which means a plain start can pull newer daemon images than the ones pinned when you last read the file. If you want reproducibility, run the stack without that refresh and keep the pins; if you want compatibility with the current network, let it run. Either way, the README's instruction to read the Upgrade Guide before upgrading applies, because a version bump here can cross a protocol change.

The project is licensed under MIT, per LICENSE.md and the README's closing line, and the README notes it is made by Any, a Swiss association. MIT is permissive, so redistribution and modification are allowed with the licence and copyright notice retained. The images the stack pulls are separate artifacts with their own terms: MongoDB, Redis, MinIO and the any-sync daemons are not covered by this repository's MIT licence. If you plan to redistribute a bundle, check each image's licence rather than assuming the MIT file covers the whole running system. That is a factual boundary, not legal advice.

## Conclusion

Adopt it if you want your own any-sync network for personal use and already run Docker with the Compose v2 plugin and about 1 GB of RAM to spare; the README positions the Puppet and Ansible modules as the route for high-load production deployments. Skip it if you need a managed service or a single-binary install, since this stack carries MongoDB, Redis and MinIO alongside five any-sync daemons. Verify first that EXTERNAL_LISTEN_HOSTS matches how clients will reach the host, that STORAGE_DIR points at a disk you are willing to lose, and read the Upgrade Guide before running make upgrade, which removes containers and volumes.

## FAQ

### What is any-sync-dockercompose and who is it for?

It is a Docker Compose project that deploys a self-hosted any-sync network, the backend Anytype clients connect to. The README describes it as suitable for personal self-hosted networks and for review or testing, and points high-load production deployments at the Puppet or Ansible modules.

### How do I install any-sync-dockercompose?

Clone the repository, copy .env.example to .env, optionally run ./update-versions.sh, then run docker compose up -d or make start. The README requires Docker with the Compose plugin v2 or newer and about 1 GB of RAM available.

### How do I connect an Anytype client to my self-hosted any-sync network?

After the first start, the stack generates ./etc/client.yml. Upload that file into the Anytype app as your self-hosted network config; the README links to the Anytype docs section on switching between networks.

### Does make upgrade delete my data in any-sync-dockercompose?

Yes. The README labels make upgrade a full reset that removes containers and volumes before starting fresh, and the Makefile expands it to down, then clean, then start, where clean runs docker system prune --all --volumes. The README also warns to read the Upgrade Guide before upgrading.

### What is the difference between the repository version and the any-sync service versions?

The release tags such as v7.2.0 version this Compose project, while .env.example pins the daemon images separately, for example ANY_SYNC_NODE_VERSION=v0.13.1 and ANY_SYNC_COORDINATOR_VERSION=v0.13.0. Running ./update-versions.sh refreshes the ANY_SYNC_*_VERSION variables from the Anytype API.

### Is any-sync-dockercompose suitable for a production deployment?

The README states the setup is suitable for personal self-hosted any-sync networks and directs high-load production deployments to the Puppet or Ansible modules instead. Docker Compose also places all services on one host, which the alternative modules do not.

## Sources

- [anyproto/any-sync-dockercompose on GitHub](https://github.com/anyproto/any-sync-dockercompose)
- [License: MIT](https://github.com/anyproto/any-sync-dockercompose/blob/main/LICENSE)
- [Project website](https://doc.anytype.io/)
- [README](https://github.com/anyproto/any-sync-dockercompose/blob/main/README.md)
- [Releases](https://github.com/anyproto/any-sync-dockercompose/releases)

---

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