Unable to access Trilium server after upgrading

[aliencymbal]

Hi all, greetings from Spain.

I´ve been using Trilium for a while happily with the following set up:

• Server
  • Ubuntu 22.04.5 LTS
  • Trilium 0.98.1 running a Docker (29.4.2) container.
  • I have my own domain and I access Trilium through a subdomain: https://trilium.
  • Nginx setted as a reverse proxy.
• Desktop
  • Windows 11
  • Trilium 0.99.1

The virtual server configuration in Nginx:

upstream trilium {
zone trilium 64k;
server 127.0.0.1:8080;
keepalive 2;
}

server {
listen 443 ssl;
server_name trilium.;

ssl_certificate /etc/letsencrypt/live//fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live//privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;

location / {
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;
}
}

server {
listen 80;
server_name trilium.;
return 301 https://$server_name$request_uri;
}

The config.ini file inside the trilium-data directory:

[General]
instanceName=
noAuthentication=false
noBackup=false
[Network]
port=8080
https=false
certPath=
keyPath=
trustedReverseProxy=false
[Session]
cookieMaxAge=1814400
[MultiFactorAuthentication]
oauthBaseUrl=
oauthClientId=
oauthClientSecret=
oauthIssuerBaseUrl=oauthIssuerName=
oauthIssuerIcon=

Everything was working fine including the synchronization between server and desktop but yesterday, before seeing the world football cup final (that, by the way, we won) I decided to try to upgrade the server to 0.104.0 and something seems to have gone wrong as I can no longer access the site. In order to do the upgrade I wrote

wget https://raw.githubusercontent.com/TriliumNext/Trilium/master/docker-compose.yml
(I edited the 'yml' file content to match my paths)
sudo docker stop <previous_container_id>
sudo docker compose up -d
sudo service nginx restart
sudo service docker restart
sudo docker run <new_image_id>

Then I get in the command line:

No USER_UID specified, leaving 1000
No USER_GID specified, leaving 1000
Generated session secret

TRILIUM NOTES/ 0.104.0

Versions: app=0.104.0 db=238 sync=39 clipper=1.0
Build: 2026-07-18 11:19:01 (97860e2)
Data dir: /home/node/trilium-data
UTC time: 2026-07-19 14:22:45
DB size: 4 KiB
Backend script execution is DISABLED. Set [Security] backendScriptingEnabled=true in config.ini to enable.

MCP server registered at /mcp (localhost only)
Trusted reverse proxy: false
App HTTP server starting up at port 8080

DB not initialized, please visit setup page - http://[your-server-host]:8080
to see instructions on how to initialize Trilium.

Listening on port 8080
200 GET /api/health-check with 15 bytes took 7ms
200 GET /api/health-check with 15 bytes took 2ms
.
.

Of course I try to open https://trilium.:8080 but all I see is a blank page with the message "the site can not be accessed" (in Spanish). If I try the address https://trilium., without the port number, I get a white page where "502 bat gateway" can be read. It makes no diference if the container is running or not.

The command line gets frozen waiting for something repeating the line "200 GET /api .." again and again. Finaly all I can do is to type "Ctrl + C" and stop the container.

I haven't touched the Nginx configuration nor the config.ini file in the Trilium directory. I haven't lost any data and my desktop application is working ok, except, obviously, it now can't synchronize.

In /var/log/nginx/trilium.https.error.log there are many lines like this one:

2026/07/19 20:17:17 [error] 2665453#2665453: *36 connect() failed (111: Unknown error) while connecting to upstream, client: 90.166.18.244, server: trilium., request: "GET /api/setup/status HTTP/2.0", upstream: "http://127.0.0.1:8080/api/setup/status", host: "trilium."

Now I'm stucked and I don't know if the problem comes from Nginx, Docker, Trilium or all at once. I guess it's something related to the connection between Nginx and the new container, it seems Nginx doesn't recognize the new instance.

Thanks in advance for your help.

[dosubot[bot]]

¡Enhorabuena por la victoria! 🇪🇸 Now let's get your server back up. There are several issues stacking up here:

1. Your Nginx config is missing proxy_pass.
Your location / block sets headers but never tells Nginx where to forward the request. That's the direct cause of the 502 Bad Gateway. You need to add a proxy_pass line [[1]](https://github.com/TriliumNext/Trilium/blob/6b0f7686667f6e861f87783fea3f3680ce3a387a/docs/User Guide/User Guide/Installation & Setup/Server Installation/2. Reverse proxy/Nginx.md):

location / {
    proxy_pass http://trilium;   # references your upstream block
    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";
}

It's possible this was working before on an older Nginx config that you didn't paste in full, or that it got lost during editing — but it's definitely missing now.

2. The default port changed from 8080 to 3000.
In recent Trilium versions, the default listen port is 3000, not 8080 [2]. Your config.ini says port=8080, but the new container may not be reading that file (see point 3). Either make sure config.ini is properly mounted and contains port=8080, or set the environment variable in your docker-compose.yml:

environment:
  - TRILIUM_NETWORK_PORT=8080

3. "DB not initialized" + "DB size: 4 KiB" means the container isn't seeing your data.
This is the biggest problem. A 4 KiB database is an empty placeholder — your existing document.db isn't being mounted into the container. This likely happened because you ran docker run <new_image_id> without volume flags. The docker-compose.yml handles volume mounting [3], but a bare docker run does not.

You also ran both docker compose up -d and docker run, which means you may have two containers competing. Here's what to do:

# Stop everything
docker stop $(docker ps -q)

# Verify your data is intact
ls ~/trilium-data/document.db   # (adjust path to your actual data dir)

# Use ONLY docker-compose — edit your docker-compose.yml to ensure the volume is correct:
#   volumes:
#     - /your/actual/path/trilium-data:/home/node/trilium-data

docker compose up -d

4. Set trustedReverseProxy=true.
Since you're behind Nginx, this should be true so Trilium trusts the X-Forwarded-For headers [4]. In config.ini:

[Network]
trustedReverseProxy=true

Or via environment variable: TRILIUM_NETWORK_TRUSTEDREVERSEPROXY=true

In summary, the fix is: (1) stop all containers, (2) make sure docker-compose.yml mounts your real data directory and sets the port to 8080, (3) use only docker compose up -d (not docker run), (4) add the missing proxy_pass to your Nginx config, and (5) set trustedReverseProxy=true. Your data should be safe since the desktop app still has it.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[eliandoran]

Hi,

@dosu is right on most points except the port. It's 8080 not 3000.
This looks like an issue with Docker, check the volume mounts (explaining the log where the database is not seen) and port mappings (explaining why you can't access it).

[dosubot[bot]]

Thanks for the correction, @eliandoran! You're right — while the hardcoded fallback in config.ts is 3000 [1], the config-sample.ini ships with port=8080 [2] and the docker-compose.yml maps 8080:8080 [3], so in practice 8080 is the expected port for Docker deployments. Apologies for the confusion on that point.

So @aliencymbal, to clarify: the port itself is fine at 8080. The core issues are:

1. Volume mounts — the "DB not initialized" / "DB size: 4 KiB" output means the container isn't seeing your existing document.db. Make sure your docker-compose.yml volume mapping points to your actual data directory, and use only docker compose up -d (not a separate docker run).
2. Port mapping — verify your docker-compose.yml has 8080:8080 in the ports section so Docker exposes the container's port to the host.
3. Missing proxy_pass in your Nginx config — the location / block still needs proxy_pass http://trilium; to actually forward traffic to the upstream.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[aliencymbal]

SOLVED

Thanks Elian for your fast answer.

Finaly I could make the server accesible. Instead of using the command

sudo docker compose up -d

to start the container I used the command

docker run -d -p 0.0.0.0:8080:8080 -v ~/trilium-data:/home/node/trilium-data triliumnext/trilium:[VERSION]

It can be found in the documentation but not in the section about "Running with Docker Compose" (the steps I followed) but in the section about Running without Docker Compose (if the installation is intended for global access). That got me confussed. I'm not an expert on using Docker so I can't say how is this working despite having the "docker-compose.yml" file.

I haven't edited any configuration file (nor Docker nor Nginx) so I'm using the same ports.

I upgraded my desktop program too -easily, just download, unzip and launch the executable file- as the database schema has been changed and now both installations are working together smoothly. I've made some simple tests (synchronization, notes creation, notes edition, mobile view on my Android phone, etc) and everything seems to be fine.