1.3.0 - Cannot install ExApp

[AndiTheHacker]

Hi there!

I have issues installing the new version of the flow ExApp in Nextcloud.
I thought that my issues would be due to my Nextcloud being moved to a new domain very recently, however, I changed all possible configurations and deleted and reinstalled the Harp daemon and the flow app + docker volumes multiple times. I confirmed with grep that there are no leftovers of my old domain in any files on my system, so that can be ruled out as the issue.
The issue is that the docker container is in a restart loop and never gets healthy to become a accessible app.
This is the log that is constantly being spammed into the docker log:

Found /certs/frp directory. Creating configuration with TLS certificates.
Starting frpc in the background...
flow is already in /etc/hosts
2026-01-16 23:35:54.612 [I] [sub/root.go:142] start frpc service for config file [/frpc.toml]
2026-01-16 23:35:54.612 [I] [client/service.go:295] try to connect to server...
PostgreSQL binaries found.
2026-01-16 23:35:54.623 [I] [client/service.go:287] [42ab7d4e5d078173] login to server success, get run id [42ab7d4e5d078173]
2026-01-16 23:35:54.623 [I] [proxy/proxy_manager.go:173] [42ab7d4e5d078173] proxy added: [flow]
2026-01-16 23:35:54.624 [I] [client/control.go:168] [42ab7d4e5d078173] [flow] start proxy success
Starting PostgreSQL...
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start.... done
server started
Waiting for PostgreSQL to start...
PostgreSQL is up and running.
ALTER ROLE
DATABASE_URL is already set to: postgresql://flow:flow@%2Fvar%2Frun%2Fpostgresql/flow?sslmode=disable
NUM_WORKERS is already set to: 8
Starting windmill in background...
Starting main command as a Python script: /ex_app/lib/main.py
Running in standalone mode
We STRONGLY recommend using at most 1 worker per container, use at your own risks
Connecting to database...
PostgreSQL version: PostgreSQL 15.15 (Debian 15.15-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit (windmill require PG >= 14)
OTEL settings loaded: tracing (false), logs (false), metrics (false), endpoint (None), headers defined: (false)
Database connected
2026-01-16T23:35:54.985040Z  WARN windmill-common/src/server.rs:81: SMTP not configured
[DEBUG]: USERS_STORAGE_PATH= /nc_app_flow_data/windmill_users_config.json
[DEBUG]: PROJECT_ROOT_FOLDER= /
[DEBUG]: STATIC_FRONTEND_PRESENT= True
2026-01-16T23:35:55.551360Z ERROR windmill-api/src/tracing_init.rs:39: response latency=0 status=401
2026-01-16T23:35:55.614686Z ERROR windmill-common/src/error.rs:267: Internal: Not implemented in Windmill's Open Source repository @users_oss.rs:53:9 error=InternalErrLoc { message: "Not implemented in Windmill's Open Source repository", location: "users_oss.rs:53:9" }
2026-01-16T23:35:55.614720Z ERROR windmill-api/src/tracing_init.rs:39: response latency=1 status=500
2026-01-16T23:35:55.614729Z ERROR windmill-api/src/tracing_init.rs:50: response failure latency=1
[initialize_windmill]: initialize_windmill: can not change default credentials password: Internal: Not implemented in Windmill's Open Source repository @users_oss.rs:53:9
Traceback (most recent call last):
  File "/ex_app/lib/main.py", line 741, in <module>
    initialize_windmill()
  File "/ex_app/lib/main.py", line 316, in initialize_windmill
    raise RuntimeError(f"initialize_windmill: can not change default credentials password, {r.text}")
RuntimeError: initialize_windmill: can not change default credentials password, Internal: Not implemented in Windmill's Open Source repository @users_oss.rs:53:9

[oleksandr-nc]

Hello. Did the flow app was working for you before the update?

[AndiTheHacker]

Yes. On 1.2.1, flow / windmill was working flawlessly. After updating to 1.3.0 and fixing my domain problems, I had the same issue as #129. In an attempt to fix the issue (also thinking that it was a problem of my specific instance and not knowing that it was a general issue), I removed the app with "delete data" enabled (as far as i know this deletes the docker volume). Now, the install gives me the error mentioned at the start.

[Technotrickie]

Thank god I'm not the only one struggling with this...
I too have very similar errors popping up in the containers logs as below.

HP_SHARED_KEY is not set. Skipping FRP configuration.
Added flow to /etc/hosts
PostgreSQL binaries found.
Starting PostgreSQL...
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start..... done
server started
Waiting for PostgreSQL to start...
PostgreSQL is up and running.
ALTER ROLE
DATABASE_URL is already set to: postgresql://flow:flow@%2Fvar%2Frun%2Fpostgresql/flow?sslmode=disable
NUM_WORKERS is already set to: 1
Starting windmill in background...
Starting main command as a Python script: /ex_app/lib/main.py
Running in standalone mode
Connecting to database...
PostgreSQL version: PostgreSQL 15.15 (Debian 15.15-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit (windmill require PG >= 14)
OTEL settings loaded: tracing (false), logs (false), metrics (false), endpoint (None), headers defined: (false)
Database connected
2026-01-19T17:54:28.770377Z WARN windmill-common/src/server.rs:81: SMTP not configured
[DEBUG]: USERS_STORAGE_PATH= /nc_app_flow_data/windmill_users_config.json
[DEBUG]: PROJECT_ROOT_FOLDER= /
[DEBUG]: STATIC_FRONTEND_PRESENT= True
2026-01-19T17:54:29.319626Z ERROR windmill-api/src/tracing_init.rs:39: response latency=0 status=401
2026-01-19T17:54:29.434244Z ERROR windmill-common/src/error.rs:267: Internal: Not implemented in Windmill's Open Source repository @users_oss.rs:53:9 error=InternalErrLoc { message: "Not implemented in Windmill's Open Source repository", location: "users_oss.rs:53:9" }
2026-01-19T17:54:29.434486Z ERROR windmill-api/src/tracing_init.rs:39: response latency=3 status=500
2026-01-19T17:54:29.434531Z ERROR windmill-api/src/tracing_init.rs:50: response failure latency=3
[initialize_windmill]: initialize_windmill: can not change default credentials password: Internal: Not implemented in Windmill's Open Source repository @users_oss.rs:53:9
Traceback (most recent call last):
File "/ex_app/lib/main.py", line 741, in
initialize_windmill()
File "/ex_app/lib/main.py", line 316, in initialize_windmill
raise RuntimeError(f"initialize_windmill: can not change default credentials password, {r.text}")
RuntimeError: initialize_windmill: can not change default credentials password, Internal: Not implemented in Windmill's Open Source repository @users_oss.rs:53:9

I was beliving it to be an issue with the way I am attempting to set it up in my Nextcloud instance running on an Ubuntu server. I installed docker on the server as instructed by the Docker pages, then went on to creating the app api daemon which I believed was the issue somehow. Once I had that connecting ok, then testing a deployment ok, I tried Flow but that container is in a pepetual restart loop. The log above has not differed much since last thursday when i started this. I did note that a new update to flow on Github had been applied and could that be the cause? I just put it down to my lack of knowledge on docker.

What I dont get as well is why mione indicates no HP_SHARED_KEY is set? It is quite clearly in the Daemon setup page as well as the Docker Socket Proxy container creation.. eitherway, I dont see that in AndiTheHacker's log post so maybe thats just a red herring for me..

Am I wrong in thinking that if the Test Deploy is succesful then the Nextcloud and docker links work and in theory so should any other exapp?
I hope someone has the answer to this as I don't know how many more times I can re install these containers only to see the same errors.

[collex100]

I got into the same mistake.

[AndiTheHacker]

@Technotrickie When the HP_SHARED_KEY does not work, it can indicate that you have errors in your daemon configuration. I think in my case it was setting the FRP server to harp:8780 (instead of standard localhost:8782). But yes, generally you are correct, that the AppAPI should be working correctly if the test deploy works. In any way, that is not the main issue we are experiencing here.