[FR] Ease up deployment

[DenuxPlays]

I think a GitHub workflow that creates and publishes all the images needed will ease up deployment.
No need to build the database images and no need to clone the repo.
Just a simple compose file and the .env file.
This way also things like watchtower would work correctly.

1~3 main use cases of the proposed feature

Currently you need to clone the repo and build your own docker images in order to deploy.
That means an increased deployed and update complexity that is not quite necessary.

• easier deployment
• easier to update
• better version management
• no need for git

what types of users can benefit from using your proposed feature

Only selfhosters will benefit from it.

Additional context

I can make these workflows and create a pr if wanted.
Also we could publish directly to the GitHub registry and so no extra setup is needed.

[khorshuheng]

For postgres image, since we only use pgvector extension at the moment, we can also use pgvector/pgvector:pg16.

Unfortunately, we still need to clone the repo. It is not because we need to build the image, we still need the following:

1. https://github.com/AppFlowy-IO/AppFlowy-Cloud/blob/main/migrations/before/20230312043000_supabase_auth.sql
2. https://github.com/AppFlowy-IO/AppFlowy-Cloud/blob/main/nginx/nginx.conf

Though the 2nd item could be optional with some modification on docker compose, and using nginx/traefik outside docker compose instead.

[DenuxPlays]

Ah okay.
I just copied the files (for now) and I cannot get it to work.

I am currently stuck here: #823

Also I cannot reach minio with the default configuration.

[almereyda]

I would like to assist with reviewing or preparing work on GitHub Actions for building the images.

Also, there were further gotrue migration regressions recently.

• [Bug] Supabase Auth / gotrue migration 20240612123726 fails on Postgres container without postgres role #839

A Compose setup that appeared to be more stable had been documented to:

• [FR] Documented production example behind a reverse proxy, here Træfik #622

Easing the deployment also means to support disabling unwanted or possibly unavailable ternary integrations. It would be sad to see OpenAI as a hard proprietary dependency.

• [FR] Allow to disable (Open)AI integration and provide context about the Appflowy (Open)AI dependency #565

[almereyda]

Also I cannot reach minio with the default configuration.

@DenuxPlays Would you like to open a separate issue to investigate this further?

[khorshuheng]

@almereyda Thanks for your effort of investigating the issue for gotrue migration. It is less of a regression bug, but more like the migration script has always been hard coded a role and password that isn't parameterized, for the supabase Auth user. I think it should be possible to parameterized it by using psql variables, experimenting with this approach now with my personal Kubernetes installation of AppFlowy cloud, but the same approach might be applicable to docker compose setup too.

On the reverse proxy setup - we have been discussing this internally, on whether to provide a separate docker compose file that is more appropriate for users who are using a reverse proxy outside docker compose, which is more production ready especially if you want to use HTTPS with Let's Encrypt. But consider that there could be many variations of the setup (eg. nginx vs envoy vs traefik), i am wondering if the different variations should be part of the main repository, or a separate community driven repository that contains all the different variations specific for self hosting scenario.

On OpenAI - most functions still run perfectly fine without the ai service, though I certainly understand that it can be annoying not to have the search function (as we use AI to generate embeddinga for search), or see the warnings generated by AppFlowy cloud.

If you meant the docker compose setup can't run without the AppFlowy AI service, then it is certainly unintended - we run dev deployment without AI all the time. In which case, please let us know and we can look into it.

I have also been thinking, if we should just extract the optional service like AI to the extra docker compose file as opposed to the main one.

If it is purely the logging message, that can be handle relatively easily, we can simply suppress it.

If it is to have an alternative endpoint that support OpenAPI request format, there is a GitHub issue that is still open at the moment.

If it is to have search functionality without using any sort of AI model at all, that I will spend time to check whether it is already possible, and if not, what are the changes that we need to make.

[DenuxPlays]

Also I cannot reach minio with the default configuration.

@DenuxPlays Would you like to open a separate issue to investigate this further?

No it was my fault or at least it started working somehow.
I got it working.
I think there is a lot of documentation missing and without a decent amount of docker knowledge it is very hard to get it working.

I planned to open a pr to improve documentation but I have too much to do and not enough time. :(

I think this issue can be closed and replaced with a few and one tracking issue.

As I think there is a lot do like:

• Improved compose file without the building stuff
• Links to the docker hub images
• Support for changing the openAI url
• Documentation to get reverse proxies working
• documentation to deploy without cloning the repo

And probably more.

I think a tracking issue that tracks all other smaller issues would be the best idea.