Document initialisation doesn't finish on fresh Docker setup

[dukc]

Description

I have installed Trilium to my Docker server. I'm using the official docker-compose.yml, only changes I did are the port number and adding a name: . The docker server is behind a reverse proxy, that forwards requests to https://my.domain/trilium/whatever to http://my.domain/whatever:10010 like the manual states. I'm not doing this to have multiple Trilium instances though, it's because I have other services under the same domain name.

Once composed (docker compose up) , I stopped the container, made the following edits to the config file:

trustedReverseProxy=true`
port=10010

and restarted the container.

I can now go to my.domain/trilium/ which redirects me to my.domain/trilium/setup and asks whether I want to start anew, sync with an existing offline instance or with an existing online instance. I choose to start anew, and it correctly shows the "Document initialization in progress" window with the in-progress animation playing. However, it never finishes.

I have tried deleting my trilium data directory and recomposing the container remembering to re-edit config-ini too. Same result.

I consider it fairly likely I still have something misconfigured in my reverse proxy/firewall/volumes, but how would I find out what? Neither the setup window or docker logs show any error messages.

TriliumNext Version

0.103.0

What operating system are you using?

Other Linux

What is your setup?

Server access only

Operating System Version

x86-64, Linux 3.10.0, glibc

Error logs

$ docker logs trilium
No USER_UID specified, leaving 1000
No USER_GID specified, leaving 1000
Generated session secret
Language option not found, falling back to en.

 _____     _ _ _
|_   _| __(_) (_)_   _ _ __ ___   | \ | | ___ | |_ ___  ___
  | || '__| | | | | | | '_ ` _ \  |  \| |/ _ \| __/ _ \/ __|
  | || |  | | | | |_| | | | | | | | |\  | (_) | ||  __/\__ \
  |_||_|  |_|_|_|\__,_|_| |_| |_| |_| \_|\___/ \__\___||___/ 0.103.0

 Versions:    app=0.103.0 db=238 sync=39 clipper=1.0
 Build:       2026-05-13 20:00:19 (44f5be88b7)
 Data dir:    /home/node/trilium-data
⏰ UTC time:    2026-08-10 14:21:14
 CPU:         Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz (1-core @ 0 Mhz)
 DB size:     4 KiB

DB not initialized, please visit setup page - http://[your-server-host]:8080 to see instructions on how to initialize Trilium.
MCP server registered at /mcp (localhost only)
Trusted reverse proxy: false
App HTTP server starting up at port 8080
Listening on port 8080
Caught interrupt/termination signal. Exiting.
No USER_UID specified, leaving 1000
No USER_GID specified, leaving 1000
Language option not found, falling back to en.

 _____     _ _ _
|_   _| __(_) (_)_   _ _ __ ___   | \ | | ___ | |_ ___  ___
  | || '__| | | | | | | '_ ` _ \  |  \| |/ _ \| __/ _ \/ __|
  | || |  | | | | |_| | | | | | | | |\  | (_) | ||  __/\__ \
  |_||_|  |_|_|_|\__,_|_| |_| |_| |_| \_|\___/ \__\___||___/ 0.103.0

 Versions:    app=0.103.0 db=238 sync=39 clipper=1.0
 Build:       2026-05-13 20:00:19 (44f5be88b7)
 Data dir:    /home/node/trilium-data
⏰ UTC time:    2026-08-10 14:23:10
 CPU:         Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz (1-core @ 0 Mhz)
 DB size:     4 KiB

DB not initialized, please visit setup page - http://[your-server-host]:10010 to see instructions on how to initialize Trilium.
MCP server registered at /mcp (localhost only)
Trusted reverse proxy: true
App HTTP server starting up at port 10010
Listening on port 10010
Slow 200 GET /api/health-check with 15 bytes took 12ms
Slow 200 GET /api/health-check with 15 bytes took 38ms
wp: The Express 'trust proxy' setting is true, which allows anyone to trivially bypass IP-based rate limiting. See https://express-rate-limit.github.io/ERR_ERL_PERMISSIVE_TRUST_PROXY/ for more information.
    at Object.trustProxy (/usr/src/app/main.cjs:1331:26577)
    at n.<computed> [as trustProxy] (/usr/src/app/main.cjs:1331:31846)
    at Object.keyGenerator (/usr/src/app/main.cjs:1331:33336)
    at /usr/src/app/main.cjs:1331:34720
    at async /usr/src/app/main.cjs:1331:34223 {
  code: 'ERR_ERL_PERMISSIVE_TRUST_PROXY',
  help: 'https://express-rate-limit.github.io/ERR_ERL_PERMISSIVE_TRUST_PROXY/'
}
Slow 200 GET /api/health-check with 15 bytes took 12ms
200 GET /api/health-check with 15 bytes took 1ms
200 GET /api/health-check with 15 bytes took 1ms
200 GET /api/health-check with 15 bytes took 1ms
200 GET /api/health-check with 15 bytes took 1ms
Slow 200 GET /api/health-check with 15 bytes took 13ms
Slow 200 GET /api/health-check with 15 bytes took 32ms
Slow 200 GET /api/health-check with 15 bytes took 34ms
Slow 200 GET /api/health-check with 15 bytes took 13ms
200 GET /api/health-check with 15 bytes took 3ms
200 GET /api/health-check with 15 bytes took 9ms
200 GET /api/health-check with 15 bytes took 1ms
[...and so on, with no other message types]

[dosubot]

Hi @dukc! I'm Dosu and I'm helping the TriliumNext team.

The "Document initialization in progress" screen works by making a single POST /api/setup/new-document request and waiting for it to resolve — it doesn't poll or use WebSockets [1]. If that POST never reaches the backend (or returns an error), the frontend will wait forever, which matches what you're seeing.

Most likely cause: your Nginx config is missing the rewrite directive needed for sub-path serving. When you access Trilium at /trilium/, the browser sends API calls to /trilium/api/setup/new-document, but Trilium only listens on /api/setup/new-document (without the prefix). The static assets and initial page load work, but the API call silently 404s — and you see the spinner hang with only health checks in the logs.

To confirm, open the browser dev tools (F12 → Network tab) while on the setup page and look for a failed POST request.

To fix, make sure your Nginx location block includes a rewrite to strip the /trilium/ prefix, plus the WebSocket and cookie path directives [[2]](https://github.com/TriliumNext/Trilium/blob/17e622cf42df1186fc1ec53c70b6898e83c18ced/docs/User Guide/User Guide/Installation & Setup/Server Installation/2. Reverse proxy/Nginx.md#L70-L82):

location /trilium/ {
    rewrite /trilium/(.*) /$1  break;
    proxy_set_header Host $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;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_pass http://<trilium-host>:10010;
    proxy_cookie_path / /trilium/;
    proxy_read_timeout 90;
}

A couple of extra notes:

• The ERR_ERL_PERMISSIVE_TRUST_PROXY warning in your logs is a separate (non-blocking) issue with trustedReverseProxy=true and express-rate-limit v7+ [3]. You can silence it by setting trustedReverseProxy to a specific IP/CIDR of your proxy instead of true.
• Verify your Docker volume mount for /home/node/trilium-data is correct and persistent — a missing mount would cause the DB to reset on every restart [4].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dukc]

@dosu is half right. There indeed is a request being sent to https://my.domain/trilium/api/setup/new-document, that doesn't get any response. But I don't think the lack of the rewrite directive can be the problem. Were that the case, going to https://my.domain/trilium/setup shouldn't work either, since Trilium listens to /setup, not /trilium/setup. Right?

[dosubot]

You're right that it sounds contradictory at first glance — but the key is how the API calls are constructed. The /setup page works because your Nginx presumably has a location /trilium/ (or similar) block that rewrites and proxies the initial page load. The API call that fires afterward is a different request, and it's built as a relative URL.

Here's what happens under the hood: the setup page fetches ./bootstrap to populate window.glob [1], and the server sets baseApiUrl: "api/" — a relative path [2]. When the setup wizard creates a new document, it calls server.post("setup/new-document", ...) [3], which resolves against the page's current URL. Since the browser is at https://my.domain/trilium/setup, that relative path becomes https://my.domain/trilium/api/setup/new-document — exactly the request you see failing in the Network tab.

So the page and the API call both go through /trilium/..., and they both need the same rewrite to strip the prefix before reaching Trilium. If the API path isn't being rewritten and proxied the same way the page path is, the POST never reaches Trilium's /api/setup/new-document.

The [official Nginx sub-path config](https://github.com/TriliumNext/Trilium/blob/17e622cf42df1186fc1ec53c70b6898e83c18ced/docs/User Guide/User Guide/Installation & Setup/Server Installation/2. Reverse proxy/Nginx.md#L63-L83) shows how to handle this — a single location block with a rewrite that covers all sub-paths (pages, API, WebSocket):

location /trilium/ {
    rewrite /trilium/(.*) /$1 break;
    proxy_set_header Host $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;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_pass http://<trilium-host>:10010;
    proxy_cookie_path / /trilium/;
    proxy_read_timeout 90;
}

Could you share your actual Nginx config? That would make it possible to pinpoint whether the rewrite isn't general enough, or if there's a more specific location block intercepting the API path.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[dukc]

My whole Nginx config would probably be too big to share here, as it is prewritten by my PaaS provider (Jelastic). However, the location directive I inserted myself to my ssl.conf is

    location /trilium {
    	rewrite /trilium/(.*) /$1  break;
        proxy_pass http://10.100.5.209:10010;
    	proxy_cookie_path / /trilium;
       	proxy_next_upstream error;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $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;
		proxy_set_header Ssl-Offloaded "1";
    }

I also have these at my nginx.conf (I suspect my requests don't go through these though. Mostly leftovers from my earlier attempts to get the proxy server working):

upstream trilium {
	zone trilium 64k;
	server 10.100.5.209:10010;
	keepalive 2;
}

                            location /trilium {
     				rewrite /trilium/(.*) /$1  break;
      				proxy_pass http://trilium;
      				proxy_cookie_path / /trilium;
				}

[dukc]

Anyway, Setup not getting a response to the POST request is certainly a lead. I quess I have to figure out how to trace how Nginx actually rewrites the request.

[eliandoran]

Hi, @dukc .

Were you able to identify your issue?

Might be worth trying the latest nightly, which has better error reporting.

[dukc]

Hi, @dukc .

Were you able to identify your issue?

Sorry, not yet.

My local AI (admittedly a small and outdated model) suggested I could trace incoming requests at my docker server, I don't necessarily need a way to trace outgoing requests from the reverse proxy. But I have yet to figure out how to accomplish either of those.

[dukc]

@eliandoran @dosu issue found! Whoa, that was difficult!

The problem was this line in my nginx.conf, under location /trilium:

proxy_http_version 1.1;

My nginx configuration is supplied by my PaaS provider, so I had to add the Trilium configuration on top of that. So I mixed in some harmless-looking lines that were at my location /, thinking there's probably some reason why they're there. Well, it turns out the /trilium/api/setup/new-document request, unlike the /trilium/ and trilium/setup requests, doesn't have a HTTP version. Due to that, my proxy didn't pass it through. Removing the aforementioned line solved it.

So indeed, i had a misconfigured proxy. I leave it up to you to decide whether it is worth to do anything about the risk someone else could have the same problem (and beyond what the latest nightly does -- didn't try it yet). On one hand, for someone like me without deep Nginx understanding, it was really tricky to solve (I did trace incoming requests at my backend server at system level, using tcpdump and httpdump, only to find none were arriving to initialise the database). But on the other hand, there are zillions of possibilities how people could misconfigure their proxy servers, I'm not sure if my error is more likely than a hundred other ones.

[dosubot]

Great sleuthing — that's a really subtle one! The proxy_http_version 1.1 directive is commonly used in Nginx reverse proxy configs (especially for WebSocket and keepalive support), so it's easy to see why it looked harmless to include. The tricky part was that it only affected the POST /api/setup/new-document request while letting the initial page loads through fine.

For what it's worth to anyone hitting this in the future: if the setup page loads but the "Document initialization in progress" spinner never completes, check the browser Network tab — if the POST to /api/setup/new-document shows no response at all (not even a 404), the issue is likely the reverse proxy silently dropping the request rather than anything in Trilium itself. As you discovered, tcpdump/httpdump at the backend are effective tools for confirming whether requests are actually reaching the server.

Glad you got it sorted!

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dukc]

As you discovered, tcpdump/httpdump at the backend are effective tools for confirming whether requests are actually reaching the server.

To be clear, I meant using those tools turned out to be a ghost chase. I actually managed to solve it by sending custom requests with the browser developer tooling, until there were no difference in the headers between requests that got and which didn't get the response. The only difference left was the HTTP version, which hinted me what was the problem in my proxy configuration.