AppFlowy-IO
[FR] Real Packaging instead of Docker (deb/rpm)
1~3 main use cases of the proposed feature Easy process of installation/removal. Could be integrated to distribution to help spread your good work everywhere.
what types of users can benefit from using your proposed feature Everybody, docker should not be the only solution to install/run a software. Packaging the cloud software like you have done the client software will benefit everyone.
Additional context Add any other context or screenshots about the feature request here.
AI (appflowy_ai) part seems not be anywhere on github or did I miss something?
appflowy_ai service is currently close source, although the image can be used for free without any license.
It should be possible to create a package that install appflowy_cloud, admin_frontend, gotrue as a service, which can then be controlled via systemctl. However, there are some caveat:
- Some database migration will need to be performed on Postgres, otherwise gotrue service will fail. This is currently handled by mounting the migration script on the postgres on docker compose.
- A reverse proxy such as Nginx will need to be installed, and the configuration will need to be setup manually.
The above could potentially be mitigated by having an installation script, that takes in user input and download the necessary migration file / generate reverse proxy configuration depending on user input. Though some effort will be required to determine the feasibility of this.
I've managed to build/run almost everything but it's not working :(
I have two things that doesn't work right now.
Appflowy History
History service seems to want to run migrations again but they where run normaly (with some minor modifications) but still. I don't use the default supabase_auth_admin and postgres user/DB but custom ones since it should be authrorized since user/password/db are set in environment *_DATABASE_URL (but writing this, i find that there's some hardcoded thing about it in application.rs and web_app.rs files!)
thread 'main' panicked at /services/appflowy-history/src/application.rs:35:41:
called `Result::unwrap()` on an `Err` value: Failed to run migrations: while executing migrations: error returned from database: no schema has been selected to create in
Stack backtrace:
0: anyhow::error::<impl anyhow::Error>::msg
1: appflowy_history::application::create_app::{{closure}}
2: appflowy_history::main::{{closure}}
3: appflowy_history::main
4: std::sys::backtrace::__rust_begin_short_backtrace
5: std::rt::lang_start::{{closure}}
6: main
7: <unknown>
8: __libc_start_main
9: _start
stack backtrace:
0: 0x561de575ea5a - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h1b9dad2a88e955ff
1: 0x561de54d5fab - core::fmt::write::h4b5a1270214bc4a7
2: 0x561de572e9e2 - std::io::Write::write_fmt::hd04af345a50c312d
3: 0x561de575fed7 - std::panicking::default_hook::{{closure}}::h96ab15e9936be7ed
4: 0x561de576112c - std::panicking::rust_panic_with_hook::hfe205f6954b2c97b
5: 0x561de5760975 - std::panicking::begin_panic_handler::{{closure}}::h6cb44b3a50f28c44
6: 0x561de57608d9 - std::sys::backtrace::__rust_end_short_backtrace::hf1c1f2a92799bb0e
7: 0x561de57608c4 - rust_begin_unwind
8: 0x561de52c6de2 - core::panicking::panic_fmt::h3d8fc78294164da7
9: 0x561de52c72a5 - core::result::unwrap_failed::hfa79a499befff387
10: 0x561de53d8619 - appflowy_history::main::{{closure}}::h6ce4247727534893
11: 0x561de53cdfde - appflowy_history::main::hd13399afcdfac9dd
12: 0x561de533ccb3 - std::sys::backtrace::__rust_begin_short_backtrace::h9602a253362b3416
13: 0x561de533ca70 - std::rt::lang_start::{{closure}}::h28e6a7ad357cfe07
14: 0x561de53da20b - main
15: 0x7f870dcdfd68 - <unknown>
16: 0x7f870dcdfe25 - __libc_start_main
17: 0x561de52e73a1 - _start
18: 0x0 - <unknown>
view of the table _sqlx_migrations
version | description
----------------+----------------------------------
20240924045045 | access request
20240910100000 | af collab embeddings indices
20240813040905 | template
20240806103039 | template creator
20240806054557 | template category
20240729065107 | publish view reaction 2
20240725065111 | publish view reaction
20240723090305 | publish view comment
20240630010030 | workspace member foreign key
20240629035230 | publish collab 6
20240627525836 | publish collab 5
20240626184736 | publish collab 4
20240621105148 | publish collab 3
20240618173348 | publish collab 2
20240618035048 | af workspace ai usage
20240617135926 | af workspace foreign key indices
20240614171931 | collab embeddings
20240613112820 | publish collab
20240604090043 | add workspace settings
20240531031836 | chat message meta
20240529054858 | workspace add token usage
20240510024506 | chat message
20240412083446 | history init
20240306110000 | workspace invitation 2
20240304173938 | workspace invitation
20240303003711 | collab member timestamp
20240227000000 | workspace icon
20240123140707 | workspace owner trigger
20231130150000 | user id foreign key
20231130140000 | user delete trigger
20231113074418 | user change
20230926145155 | blob storage
20230906102651 | collab
20230906101555 | user profile
20230906101222 | workspace
20230906101032 | permission
20230312043023 | user
AppFlowy Client
Don't think this is related to above but not really sur because the service is down.
When I use the magic link received, the client app very briefly (too briefly to be read...) show a error message:
msg: error returned from database: new row violates row-level security policy for table "af_user"
Don't really know why or how to fix it. If you have any hints.
Ok I managed to fix the error for appflowy history by set APPFLOWY_HISTORY_DATABASE_NAME variable since it seems that APPFLOWY_HISTORY_DATABASE_URL is not fully used for extract that. So I have all service running but still get the af_user error.
- What are their needs?
- Some users prefer not to use containers for their deployment and prefer running every services directly on the machine.
- What challenges exist with our current solution?
- We will need to add additional github action to publish the binaries file, and also making sure that the pre-compiled binary can run on most major distribution.
- We will also need to maintain deb/rpm package.
- Users will still need to install the reverse proxy themselves, and manually add the configuration. Though it is possible that we may provide example configuration as part of the package, which the user can link to.
- What percentage of self-hosters might face the same issue?
- It’s rare, and some user has already successfully do this on their own without our help, by compiling from source.
What are their needs?
- Some users prefer not to use containers for their deployment and prefer running every services directly on the machine.
What challenges exist with our current solution?
- We will need to add additional github action to publish the binaries file, and also making sure that the pre-compiled binary can run on most major distribution.
- We will also need to maintain deb/rpm package.
- Users will still need to install the reverse proxy themselves, and manually add the configuration. Though it is possible that we may provide example configuration as part of the package, which the user can link to.
What percentage of self-hosters might face the same issue?
- It’s rare, and some user has already successfully do this on their own without our help, by compiling from source.
I installed AppFlowy Cloud on Unraid, and the main interface shows numerous AppFlowy containers. Could the official team package all services into a single container?
@Schoumi I believe you can install Appflowy cloud directly on your machine via Yunohost. Not sure if something like that would interest you or be helpful. Here's a link to the Yunohost page AppFlowy on Yunohost. It's not a perfect soliution but it might work for you
@Byrnesdigital thanks for the input but not it won't work for me as i manage my server without yunohost and i have many services already running. I don't want to have a complete system to manage above appflowy only for appflowy.