Open almereyda opened 3 months ago
Thank you for your effort on selfhosting, as you say, still more to work on basic but not AI.
I try to use your files to deploy the server. Maybe some problem with the docker-compose.yml, where is the building dockerfile ? I already add the origin postgres.Dockerfile in ./context/postgres, but.......
after that I add dockerfile statement to docker-compose.yml as below:
It that right ?
Thanks for the encouragement reg. #565.
It's the same as in this repository here:
main use cases of the proposed feature
As a platform engineer, I need to be able to spin up conventional and minimally reconfigured appflowy instances quickly, in order to provision many communities with it.
As a distributed systems engineer, I need to be able to isolate the side-effects of an application deployment cleanly, in order to to provide for consistency of an environment.
what types of users can benefit from using your proposed feature
Families, Homelab engineers, Civic society: groups, communities, initiatives, associations, not-for-profits, non-government-organisations, foundations (<= there is money ..), Internet Service Providers, AppFlowy Developers
Additional context
The current
docker-compose.yml
and thedeploy.env
example present a very opinionated setup, which is tightly coupled with the code https://github.com/AppFlowy-IO/AppFlowy-Cloud/issues/228#issuecomment-2167072296 and makes assumptions about the target system. While the Nginx configuration contains an example for binding its ports to the host system, a deployment behind a reverse proxy is a lot more likely for common production environments.Additionally, the database initialisation logic in the before migration hard-codes the database name and the password for the supabase/auth
gotrue
user. Since thePOSTGRES_USER
will be part of thesuperuser
role, this can also be provided at run time with dynamically created initialisation logic.https://github.com/AppFlowy-IO/AppFlowy-Cloud/blob/430e3e15c9a1dc6aba2a9599d17d946a61ac7cae/migrations/before/20230312043000_supabase_auth.sql#L29
https://github.com/AppFlowy-IO/AppFlowy-Cloud/blob/430e3e15c9a1dc6aba2a9599d17d946a61ac7cae/migrations/before/20230312043000_supabase_auth.sql#L35
This issue documents the outcome of modifications that were applied to make this run behind a Træfik reverse proxy as edge router and load balancer.
Further no Docker volumes are used for capturing database state, but mountpoints of ZFS datasets, which are managed externally from the Docker daemon.
.env
nginx.conf
20230312043000_supabase_auth.sql
compose.yml
This setup favours convention over configuration, but for secrets and custom namespaces.
It also adds a first round of healthchecks and also state to redis.
There are two obstacles that present themselves on setting this up, where application runtime state is applied.
migrate
container that knows how to replace certain values in the SQL with variables. This could be achieved by using aninit.d
.sh
script instead, and passing down the required variables to the container.Apart from that, AppFlowy Cloud appears quite stable.