You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the deploy.env example present a very opinionated setup, which is tightly coupled with the code #228 (comment) 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 the POSTGRES_USER will be part of the superuser role, this can also be provided at run time with dynamically created initialisation logic.
events {
worker_connections 1024;
}
http {
# docker dns resolver
resolver 127.0.0.11 valid=10s;
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 8080;
# https://github.com/nginxinc/nginx-prometheus-exporter
location = /stub_status {
stub_status;
}
}
server {
listen 80;
client_max_body_size 10M;
underscores_in_headers on;
# GoTrue
location /gotrue/ {
set $gotrue gotrue;
proxy_pass http://$gotrue:9999;
rewrite ^/gotrue(/.*)$ $1 break;
# Allow headers like redirect_to to be handed over to the gotrue
# for correct redirecting
proxy_set_header Host $http_host;
proxy_pass_request_headers on;
}
# WebSocket
location /ws {
set $appflowy_cloud appflowy_cloud;
proxy_pass http://$appflowy_cloud:8000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_read_timeout 86400;
}
# AppFlowy-Cloud
# created a separate location block for handling CORS preflight (OPTIONS) requests specifically for the /api endpoint.
location = /api/options {
if ($http_origin ~* (http://127.0.0.1:8000)) {
add_header 'Access-Control-Allow-Origin' $http_origin;
}
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE, PATCH';
add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization, Accept, Client-Version';
add_header 'Access-Control-Max-Age' 3600;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
location /api/chat {
set $appflowy_cloud appflowy_cloud;
proxy_pass http://$appflowy_cloud:8000;
proxy_http_version 1.1;
proxy_set_header Connection "";
chunked_transfer_encoding on;
proxy_buffering off;
proxy_cache off;
proxy_read_timeout 600s;
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
}
location /api {
set $appflowy_cloud appflowy_cloud;
proxy_pass http://$appflowy_cloud:8000;
proxy_set_header X-Request-Id $request_id;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Set CORS headers for other requests
if ($http_origin ~* (http://127.0.0.1:8000)) {
add_header 'Access-Control-Allow-Origin' $http_origin always;
}
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, PATCH' always;
add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization, Accept, Client-Version' always;
add_header 'Access-Control-Max-Age' 3600 always;
}
# Admin Frontend
# Optional Module, comment this section if you are did not deploy admin_frontend in docker-compose.yml
location / {
set $admin_frontend admin_frontend;
proxy_pass http://$admin_frontend:3000;
proxy_set_header X-Scheme $scheme;
proxy_set_header Host $host;
}
}
}
20230312043000_supabase_auth.sql
29c29< ) THEN CREATE USER supabase_auth_admin BYPASSRLS NOINHERIT CREATEROLE LOGIN NOREPLICATION PASSWORD 'root';---> ) THEN CREATE USER supabase_auth_admin BYPASSRLS NOINHERIT CREATEROLE LOGIN NOREPLICATION PASSWORD '<openssl rand -hex 32>';35c35< GRANT CREATE ON DATABASE postgres TO supabase_auth_admin;---> GRANT CREATE ON DATABASE com_example_appflowy TO supabase_auth_admin;
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.
nginx.conf, where only certain routes are needed and the conventional DNS name of the appflowy_cloud container reappears
20230312043000_supabase_auth.sql, which might be replaced by a little migrate container that knows how to replace certain values in the SQL with variables. This could be achieved by using an init.d.sh script instead, and passing down the required variables to the container.
Apart from that, AppFlowy Cloud appears quite stable.
The text was updated successfully, but these errors were encountered:
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:
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 #228 (comment) 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.AppFlowy-Cloud/migrations/before/20230312043000_supabase_auth.sql
Line 29 in 430e3e1
AppFlowy-Cloud/migrations/before/20230312043000_supabase_auth.sql
Line 35 in 430e3e1
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.
The text was updated successfully, but these errors were encountered: