any-sync-dockercompose: a self-hosted Anytype backend in one Compose file
Deploy your own any-sync network with Docker Compose - self-host Anytype backend
At a glance
- What is it?
- The repository packages a full any-sync network (coordinator, three sync nodes, filenode, consensus node, MongoDB, Redis, MinIO) behind docker compose up. It is aimed at personal networks, and the README says so twice.
- Who is it for?
- Adopt it for a personal any-sync network or a test rig, where the seven-service stack and roughly 1 GB RAM requirement are acceptable. Do not adopt it as a production backend: the README points high-load deployments at the Puppet and Ansible modules instead.
- 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 2 days ago.
- What is it written in?
- Mainly Shell, 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 gap between running Anytype and running the network behind it
Anytype clients talk to an any-sync network. Someone has to operate that network: a coordinator that tracks spaces and members, sync nodes that hold documents, a filenode that stores attachments, and a consensus node that resolves conflicts. Standing those up by hand means generating configs, wiring MongoDB, Redis and an S3-compatible store, and keeping the whole set on compatible versions. This repository collapses that into a Compose project. It is for a person or small group who wants their own network rather than the public one, and for anyone who needs a disposable network to test against. The README is explicit about the ceiling: the setup is "suitable for personal self-hosted any-sync networks", and high-load production deployments are directed elsewhere. Treat that sentence as the scope of the whole project.
Seven long-running services and what depends on what
The README's architecture table lists the moving parts. any-sync-coordinator manages spaces and members and depends on MongoDB. Three any-sync-node instances handle document sync and depend on the coordinator. any-sync-filenode stores files and depends on the coordinator, MinIO and Redis. any-sync-consensusnode handles conflict resolution and depends on the coordinator. MongoDB holds coordinator state, Redis holds the filenode index, and MinIO provides S3-compatible object storage. A netcheck service monitors connectivity across all nodes on a periodic basis. One optional service, anytype-cli, sits commented out in docker-compose.yml and exposes an HTTP and gRPC API for automation. That dependency chain matters operationally: the coordinator and MongoDB are the base of the stack, so a coordinator that will not start takes the nodes, filenode and consensus node with it. The three sync nodes are replicas of one role rather than three distinct components, which is worth knowing before you read the process list and assume four separate services failed.
First run: clone, copy the env file, compose up
The getting-started path in the README is four steps. Clone the repository and enter it, then run cp .env.example .env. Optionally run ./update-versions.sh, which the README says updates the ANY_SYNC_*_VERSION variables in .env from the Anytype API; skip it and you keep the pinned versions from .env.example. Then run docker compose up -d, or make start, and on first run the stack generates configs under ./etc/ and starts every service. Connecting a client means uploading ./etc/client.yml to the Anytype app as the self-hosted network config. Requirements are Docker with the Compose plugin, version 2 or later, and about 1 GB of RAM available. The configuration section names three keys worth editing: EXTERNAL_LISTEN_HOSTS for external IPs when clients are not on localhost, STORAGE_DIR to move data off the default ./storage, and ANY_SYNC_DAEMONS_MEMORY_LIMIT, defaulting to 500M, to set a per-daemon memory limit. If you edit nothing else, EXTERNAL_LISTEN_HOSTS is the one that decides whether remote clients can reach you at all.
make upgrade is a reset, not an upgrade
The quick reference is where the sharp edges are. make start generates config and starts services. make stop stops them with data preserved. make restart does both. make logs follows output from all services. make pull fetches the latest images, and make update is pull plus restart, described as a rolling update. make down stops and removes containers with data preserved. Then there is make upgrade, flagged in the README as a full reset that removes containers and volumes before starting fresh. The name is the problem. A reader who skims the list will assume upgrade means what update means, and the two differ by whether your volumes survive. The README's warning at the top points at the Upgrade Guide in the wiki before any upgrade, and that warning is doing real work here. make clean is more destructive still, running docker system prune --all --volumes, which the README notes removes all Docker data, not just this project's. make cleanEtcStorage removes the generated ./etc/ configs and ./storage/ directory. Four of these targets touch persistent state, and two of them reach beyond the project. Read the target before running it.
Version drift and the update-versions.sh escape hatch
The stack is a set of independently versioned services, and the .env file carries ANY_SYNC_*_VERSION variables for them. Left alone, those stay at whatever .env.example pins. Running ./update-versions.sh pulls the latest compatible set from the Anytype API and rewrites the variables. That is a convenience with a cost: the file you edited for EXTERNAL_LISTEN_HOSTS and STORAGE_DIR is the same file the script rewrites. If you have local changes and run it without checking, you need to know whether it touches only the version variables or more. The README says it updates the ANY_SYNC_*_VERSION variables, which suggests a narrow edit, but the safe habit is to diff .env after running it. There is also a timing question the README does not answer: whether a version set fetched today is compatible with configs already generated in ./etc/. Since ./etc/ is generated on first run and make cleanEtcStorage exists to remove it, regenerating configs after a version jump is at least a supported path. Whether it is a required one is not stated in the material available.
What the Compose setup does not give you
The README's own pointers are the clearest limitation. High-load production deployments should use the Puppet or Ansible modules, which means this project is not the tool for a network serving many users or sustained traffic. The roughly 1 GB RAM figure and the 500M default per-daemon memory limit describe a size class, not a scaling story. There is no mention of TLS termination, backups, monitoring beyond the netcheck connectivity probe, or what happens to MongoDB and MinIO data under load. netcheck tells you whether nodes can reach each other; it does not tell you whether the coordinator is keeping up. A second limitation is the config surface. Customization happens by editing .env directly, and the README defers the full reference to the Configuration wiki, so anything beyond the three named keys requires leaving the repository. If your requirement is a network with documented capacity planning, this is the wrong starting point, and the README says as much.
Puppet and Ansible modules, and the difference in approach
The alternative the README names is anyproto/puppet-anysync or anyproto/ansible-anysync. The difference is not packaging preference, it is the unit of management. This repository treats the network as one Compose project on one host: a single docker-compose.yml, one .env, one ./storage directory, and make targets that act on the whole set at once. The Puppet and Ansible modules treat it as configuration to be applied across hosts, which is what you want when the coordinator, storage and nodes should not all fail together. With Compose, a host reboot takes the entire network down and brings it back in dependency order. With a configuration-management module, you can place and restart services independently. The trade-off runs the other way too: Compose needs Docker and a .env file, and the README's first-run flow is four commands. A Puppet or Ansible deployment assumes you already run that tooling and are prepared to maintain the manifests. For one person on one machine, the Compose route is less machinery. For anything with an availability expectation, it is the wrong shape.
Licence, maintenance load, and what to check before you commit data
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That covers the Compose files and scripts here. It does not automatically cover the container images the stack pulls, and the README does not state their licences, so if you redistribute a running network rather than the repository, check each image separately. This is a description of the licence text, not legal advice. On maintenance: the release cadence is active, with v7.0.1, v7.1.0 and v7.2.0 appearing across roughly two months in the supplied history, and the last push date matches the newest release. Upgrading is therefore a recurring task rather than a one-off, and the README routes you to the Upgrade Guide in the wiki before each one. The practical cost is that you own MongoDB, Redis, MinIO and five any-sync daemons on one host, plus the version alignment between them. Before pointing a real client at ./etc/client.yml, verify three things: that EXTERNAL_LISTEN_HOSTS matches how clients will reach the host, that the ANY_SYNC_*_VERSION values in .env are the set you intend to run, and that you understand which make targets preserve volumes. Those three checks are cheap. Recovering a network after make upgrade is not.
Editorial conclusion
Adopt it for a personal any-sync network or a test rig, where the seven-service stack and roughly 1 GB RAM requirement are acceptable. Do not adopt it as a production backend: the README points high-load deployments at the Puppet and Ansible modules instead. Before trusting it with data, read the Upgrade Guide in the wiki, because make upgrade removes containers and volumes, then confirm the versions update-versions.sh wrote into .env and that etc/client.yml matches the client you will actually use.
Community notes