WHAT DO YOU RECOMMEND?
The ability to self-host my own backup node for AnyType is the software’s most attractive trait for me. I believe the user-experience in the self-hosting setup process can be improved to reflect the polish that is encountered in the rest of AnyType. Currently, the self-hosting process for AnyType takes more steps to set up than other similar self-hosted applications. That workflow can be improved in ways that make it easier to understand, more approachable, and more immune to dependency hell.
HOW COULD IT BE DONE?
One method to achieve this would be to construct a singular docker-compose.yml file for the user to work with. The contents of this file would instruct a series of docker containers on the steps necessary to collect and compile the necessary resources, then spin them up in a repeatable way.
Ideal Self-Hosting User Workflow with docker compose:
- Copy docker-compose.yml contents
- Change necessary values using a text editor
- configuration volume location
- data volume location
- network port for accessing the node
- addresses that the application will be accessed at
- Storage and user limit counts
- Paste the customized docker-compose.yml to deploy to any docker-compose environment
Many applications use this solution for self-hosting because it simplifies the setup process immensely. The user could simply copy the contents of the docker-compose file into their docker compose manager of choice (Dockge, Portainer, TrueNAS, Unraid, Synology).
This workflow is common for other self-hosted services. As an example, here is the docker-compose.yml for changedetection.io:
All the user must do is change relevant values in the volumes and ports in this file using a text editor, then paste the contents into their self-hosted interface. This singular file has all the information and configuration ability that is needed for docker to fully compose the necessary services and begin running the docker-compose application.
The current process uses a makefile to generate and run a docker-compose.yml file and associated environment variables file. This makefile workflow is somewhat unique to AnyType, which restricts its portability and complicates the self-hosting setup. One way to streamline this process would be to re-work the makefile compilation process to work inside the containerized environment.
REAL WORLD USE CASES
I would like to self-host an anytype node for my own personal use. It would only be accessible inside of my local network. My home server runs TrueNAS Scale as an operating system. TrueNAS Scale uses Docker Compose to host it’s user-defined services. TrueNAS, like several similar platforms, has a dedicated interface for pasting the contents of a docker-compose.yml file to host an application or service. TrueNAS is an operating system as appliance, meaning that it enforces best practices via discouraging CLI use.
I am familiar with Linux administration, networking, self-hosting docker services, and editing docker-compose files for the purposes of self-hosting.
The TrueNAS server currently runs 24 docker-compose stacks from various sources like the TrueNAS Community Catalog, provided from individual projects, and ones that I have put together myself.
Currently, AnyType is difficult for me to host on my established system because AnyType asks for different configuration steps that are usually handled inside docker compose. I can circumvent these limitations using various methods like virtualization, but creating unique workarounds when everything else runs cleanly in docker compose is going to create problems down the road with server upkeep. Updating, troubleshooting, or migrating data becomes a series of edge cases because AnyType is handled differently than other services.
RECOMMENDED ALTERNATIVES
Because AnySync is open source, the AnyType community may be able to create a docker-compose document that streamlines the setup process. However, the best people to refactor the docker-compose process would be those with in-depth familiarity with the AnySync software, security, and networking requirements. Thoughtful design work here would result in more extensibility and easier maintenance in the future.
ADDITIONAL CONTEXT
The advantage that docker brings to software development is that it offers portability. A good metaphor is a shipping container. A standard shipping container can be carried by truck, train, or boat because every container has standardized dimensions and fastening points. Any platform can take part in the shipping process because of these agreed-upon standards.
Within this metaphor, AnyType does not provide a shipping container, it provides instructions on how to build a factory for it’s shipping container. This results in unnecessary complexity for the user.
If a condensed docker-compose.yml file is created, it will also be a large step to assisting AnyType backup node to be deployed to the “app store” format on several of these docker-compose-based operating systems. For instance, on TrueNAS, there is a “community” branch of the app store that has other self-hostable docker-compose/helm-chart containers. Having visibility in these communities would improve awareness of AnyType and benefit users at the same time.
It would be easy to ignore the current user-experience for self hosting by blaming the user’s lack of expertise, but the current process for self-hosting is not portable, and doesn’t conform to the regular practices when deploying using docker-compose. These things are certainly complicated, but improvement is absolutely possible.
To forward the goal of a better internet and to prove AnyType is the best choice, the self-hosted workflow must be addressed.