Simplify self-host deployment to improve adoption in UI-based Docker environments

Have you read a contributing guide?

• I have read CONTRIBUTING.md
• I have searched the existing requests and didn't find any that were similar
• I have considered creating a pull request instead and want to proceed

Clear and concise description of the problem

Hello,

First of all, thank you for providing the self-hosted AnySync setup. I really appreciate the effort behind making Anytype self-hostable.

I would like to propose a UX improvement regarding the current deployment process.

At the moment, the setup requires generating configuration files before launching the containers (typically via make, or via the documented manual generation flow).

While this works fine for users comfortable with CLI workflows, it creates friction for people who manage their infrastructure using tools like:

• Portainer
• Unraid
• CasaOS
• TrueNAS Scale
• or other Docker UI-based environments

In those setups, users typically:

• Paste a docker-compose file into a stack
• Adjust environment variables and volume paths
• Deploy

The need to run a separate configuration-generation step outside of docker-compose makes AnySync the only service in my homelab that cannot be managed entirely from a Docker UI.

I understand that a “make-less” flow is documented in the wiki, but it still requires running a manual config-generation step before the stack can start, which remains a blocker for fully UI-driven deployments.

Suggested solution

I believe simplifying this (if technically possible) could significantly improve adoption in the homelab / self-hosting community.

Possible ideas:

• Allow config generation automatically on first container startup
• Provide a “pre-generated config” mode
• Offer an official simplified compose file
• Or integrate something similar to what projects like any-sync-bundle are attempting

I’m not suggesting changing the architecture — only exploring whether the setup could be made more Docker-native and UI-friendly.

Would this be something the project would consider?

Thank you again for your work.

Alternative

No response

Additional context

No response

Start by reading CONTRIBUTING.md and the documented manual generation flow in the wiki, then inspect the current docker-compose and make-based configuration-generation entry point. Compare that flow with the UI-based deployment needs described here and define a concrete approach whose done state allows deployment without a separate configuration-generation step.