Desktop Version - Multiple Notebook Support?

[pyz0123-cpu]

Quick question about data directories in the desktop version.

The documentation explains that Trilium’s data directory can be changed using
the TRILIUM_DATA_DIR environment variable (with Windows, Linux, and macOS
examples), and that this mechanism allows running multiple database instances
or launching Trilium with different data directories.

From what I can tell, this works as expected for the server version, since the
backend clearly supports arbitrary data directories and initializes config.ini
inside whatever directory TRILIUM_DATA_DIR points to.

However, when I try this with the desktop version (both on Windows and on the
Linux repo build), the desktop app always opens the default data directory
shown in the About dialog. It doesn’t seem to honor TRILIUM_DATA_DIR or
--data-dir, and the only way I’ve found to open a different notebook is to
rename it to “trilium-data” in the default location.

Before I assume I’m misunderstanding the documentation, I wanted to check:

Does the desktop version intentionally not support selecting a custom data
directory, even though the backend and server version do?

One additional note: the documentation’s recommendation to set a global
environment variable (TRILIUM_DATA_DIR) for changing the data directory
seems unusual for a desktop application. Global environment variables are
typically used for server processes or system-wide configuration, not for
per-instance desktop workflows. In a normal desktop environment, asking users (or their IT
departments) to set a global variable just so a single application can find
its data directory would be considered highly unconventional. This is part of
why I wanted to clarify whether the desktop version is intended to support
this mechanism.

Thanks for a great piece of software!

[dosubot[bot]]

The desktop version does support TRILIUM_DATA_DIR, but there's a critical catch: the environment variable must be set before the Electron process starts. This is where most users hit problems.

Root Cause: On Linux (and often Windows), when you launch the desktop app from an application menu or shortcut, it doesn't inherit environment variables set in your shell (.bashrc, etc.). The data directory resolution happens at ES6 module initialization time, before the app even starts—so if the variable isn't in the process environment at launch, it's too late.

Also important: Trilium does not support --data-dir. Command-line argument support for this doesn't exist—only environment variables work.

Workarounds:

• Linux: Launch from terminal (TRILIUM_DATA_DIR=/path/to/data trilium), or edit your .desktop file:

  Exec=env TRILIUM_DATA_DIR=/path/to/data trilium %U
  

• Windows: Use a wrapper .bat script:

  set TRILIUM_DATA_DIR=C:\your-trilium-data
  start trilium.exe

• Multiple instances: You'll also need unique ports—TRILIUM_PORT=37840 for instance 1, TRILIUM_PORT=37841 for instance 2, etc. The single-instance lock uses the port in its path.

Your observation about global environment variables being unusual for desktop apps is valid—this is a known pain point, and there's been discussion about adding proper command-line argument support.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[pyz0123-cpu]

Thanks DOSU for the explanation — I appreciate the clarification. I have to admit, this workflow feels a bit like a time warp. Injecting a global environment variable to switch notebooks on a desktop app in today’s world is… well, very “Back to the Future.” Most desktop software exposes this through a flag, a shortcut option, or a simple UI element.

So I just want to make sure I’m understanding the intended workflow correctly. Because if this is the only option, it will be a very hard sell to my friends and end users in my company.

[eliandoran]

There are plans to support custom database paths exposed at UI level but we are a long way from there.

[pyz0123-cpu]

Thanks for confirming — that makes sense. Since the UI support for custom
database paths is still a long way off, I put together a small notebook
switcher that fills the gap in the meantime. It simply lets the user pick
a notebook folder and then launches Trilium with the correct --data-dir
path. Nothing fancy, just a lightweight helper that uses the workflow
Trilium already supports.

If you think it might be useful, I’m happy to share it. It might help bridge the UX gap
until the built‑in selector arrives.

[TheBig-O]

If you would share your switcher, that would be great! I would love to separate work and home files. I'm happy with how I have it now, but there will come a day when I switch jobs and would like to be able to "forget" about all the stuff from the previous job, but not delete it.

[pyz0123-cpu]

Mr. Big-O -- I wanted to share a bit about the notebook switcher I built before attaching anything.

Server Support - I think this switcher will work on the server version of Trilium — but I have NOT tested it yet. The Trilium documentation states that the server version supports --data-dir /path/to/notebook. If the server behaves exactly as documented, then:

A valid notebook folder should open normally
An empty folder should initialize a new blank notebook
Any folder you point to should be treated as intentional

But again — this is based on documentation. I have not yet tested the server behavior directly.

Desktop Behavior (Tested) - Based on testing so far, the desktop app currently has some limitations that affect multi‑notebook workflows. These aren’t bugs — they’re simply how the desktop version is designed today. Specifically:

The desktop app always looks for a trilium-data folder in its expected location
It doesn’t currently use the folder a user selects through an external tool
It only opens a notebook if that folder is already valid
If the folder is empty or incomplete, the desktop app starts the setup process and loads the demo notebook

This design works fine for single‑notebook users, but it makes multi‑notebook workflows difficult without changes to how the desktop app handles --data-dir.

What This Means for the Switcher - The switcher can:
let you choose notebook folders
create new notebook directories
manage multiple notebook locations
launch Trilium with the correct --data-dir argument

But because the desktop app currently ignores that argument: It cannot fully work on the desktop until Trilium forwards --data-dir. That is the only missing piece on the Trilium side.

Platform Support - The switcher itself is:

fully implemented and tested on Linux
requires minor adjustments for Windows
requires minor adjustments for macOS

These are small changes (mostly path handling and launch commands), but they are still required. So even if Trilium Desktop starts forwarding --data-dir, the switcher will still need Windows‑specific tweaks and/or macOS‑specific tweaks before it becomes fully cross‑platform.

What You’ll Be Able to Do (Once --data-dir Works on Desktop) -
separate work and personal notebooks
archive old notebooks without deleting them
switch contexts cleanly
keep data organized
avoid mixing everything into one giant file

The switcher solves all of this — as soon as the desktop version forwards --data-dir the same way the server version is documented to.

If you want to look at it I can attach the Python file. It runs with: python3 swticher.py No dependencies - just python 3. I just wanted to give you the full context before sharing it. Let me know if you are interested.

[TheBig-O]

Ah, Thank you for that context. That all seems reasonable and I totally understand the limitations because of how the app is written right now (and that multi-notebooks is well down on their list of capability adds).
I would love to give it a go to see if I can get it to support my intended workflow.
I appreciate the help and information!

[pyz0123-cpu]

switcher.py

Attached is the Python source for switcher.py. I wrote this over a weekend a couple of weeks ago and was pretty happy with how it turned out.

When I finally tested it, though, I kept running into the setup/demo dialog no matter which folder I selected. That’s when it became clear what was happening: there’s no way to get around the hard‑coded desktop wrapper behavior.

The desktop app always expects a trilium-data folder in a very specific location, and it doesn’t currently pass the --data-dir argument through to the backend. Because of that, even if you launch Trilium with a different folder, the backend never sees it — so the desktop app falls back to setup mode and loads the demo notebook every time.

The switcher itself works exactly as intended (folder selection, creation, management, launching with the right arguments), but the desktop wrapper simply doesn’t use the folder you give it. That’s the only blocker. Let me know your thoughts.

[TheBig-O]

Awesome! Thank you. I can't wait to give it a go.