Trilium Notes: a hierarchical notes app for large personal knowledge bases

What Trilium Notes solves, and who ends up using it

Most note apps treat the folder as the only container. Trilium Notes treats the note as a node in a tree that can be arbitrarily deep, and it lets a single note sit in more than one place at once. The README calls this cloning. If you write about a topic that belongs under both "Projects" and "Reading", you do not copy it and let the two versions drift. You clone it and edit once.

The second structural idea is the attribute. Notes carry attributes that the application uses for organisation, querying and scripting, and the README points to scripting as the payoff. That combination is what separates Trilium from a plain outliner: you can build a saved query, attach a script to a note, and have the tree reorganise itself. The README also lists note versioning, hoisting, full text search and a REST API for automation.

This is a tool for one person maintaining a large body of interconnected notes over years. It is not a team wiki. Sharing exists, and it publishes notes to the public internet, but the README describes no collaborative editing model, no comments, no per-paragraph review. If your problem is a shared document space with permissions, this is the wrong shape of tool.

The note tree, attributes and the sync server behind the UI

The repository is a pnpm workspace. The top level holds apps/ and packages/, with a tsconfig.base.json and a single pnpm-lock.yaml, and the root package.json exposes filtered scripts for a client, a server, a desktop build and a standalone build. That layout tells you the web client and the server are separate artefacts, and that the desktop application is assembled from them rather than being the primary target.

Data flow follows the same split. The server owns the note database and serves the web client over HTTP; the desktop build embeds the same server locally. Synchronisation is a separate concern: the README describes synchronisation with a self-hosted sync server, and lists third-party services for hosting that server. So there are two servers in a full setup, one for the notes you read and one for the sync protocol, and the README notes that sync versions are incremented between releases.

The docker-compose.yml in the repository shows the server side plainly: the image is triliumnext/trilium, the container sets TRILIUM_DATA_DIR to /home/node/trilium-data, and port 8080 is published. The data directory is bind-mounted from ${TRILIUM_DATA_DIR:-~/trilium-data}, and /etc/timezone and /etc/localtime are mounted read-only. That last detail is a small but telling design choice: the application reads the host clock rather than keeping its own timezone setting.

Installing Trilium Notes with Docker and creating a first note

The README points to the latest release on GitHub as the stable download for most users, and to docs.triliumnotes.org/user-guide/setup for installation instructions. On a server, the repository ships a compose file. Its own comments say that running docker-compose up will create or use the trilium-data directory in the user home, and that TRILIUM_DATA_DIR=/path/of/your/choice sets a different directory.

TRILIUM_DATA_DIR=/path/of/your/choice docker-compose up

After the container starts, open http://localhost:8080. The compose file's comments say Trilium will be available there and also at http://<host-ip>:8080, and they warn that you might want to limit this with Docker networks, reverse proxies or firewall rules. They also state that UFW is known not to work with default Docker installations, which is worth reading before you assume a host firewall is protecting the port.

The compose file uses the image triliumnext/trilium:latest and comments that you can optionally replace latest with a version tag like v0.90.3, warning that using latest may cause unintended updates to the container. To pin a release, edit the image line:

services:
  trilium:
    image: triliumnext/trilium:v0.90.3

For a desktop install, download the latest release from the GitHub releases page rather than building from source. The root package.json is a workspace manifest, not an end-user installer; its scripts such as desktop:build and standalone:build are development entry points. Once the application is open, the README directs you to press F1 to read the same documentation inside the app.

Where Trilium Notes stops being the right answer

The mobile story is the weak point. The README lists a touch optimised mobile frontend for smartphones and tablets, which is a web frontend, not a native application. People search for Trilium Notes Android and Trilium notes iOS, and the README describes no native clients for either platform. If your workflow depends on an app that syncs in the background and works offline on a phone, the browser frontend is a different experience, and the README does not document what happens when connectivity drops.

Storage format is the second boundary. People ask whether Trilium is Markdown, and the answer in the README is narrower than that question implies: Markdown import and export are listed as features, alongside Evernote import. That is a conversion path, not a storage format. If you want a directory of .md files that any editor can open, this is not that. You get Markdown out through export.

The README also does not document rollback for an upgrade. It links to an upgrading guide, but the README itself is silent on downgrading after a sync version increment. Combined with the note that versions after v0.90.4 increment the sync version and prevent direct migration from zadam/trilium, that silence matters if you run several instances.

Trilium versus Obsidian: files on disk against a note tree

The comparison people search for is Trilium vs Obsidian, and the difference is architectural rather than cosmetic. Obsidian stores a vault as plain files in a folder, and the file system is the source of truth. Trilium stores notes in its own database, with the tree, attributes and revisions as first-class structures, and exposes data through the application, its export features and a REST API.

That choice buys Trilium things a file-based tool has to approximate. Cloning a note into two places in the tree is native. Attributes and scripting let notes drive queries and behaviour. Per-note encryption is granular at the note level, and the README describes it as strong. None of that maps cleanly onto Markdown files with YAML front matter.

The trade runs the other way too. With plain files you can grep, diff, back up and migrate with tools you already have, and no application upgrade can strand the data. With Trilium you depend on the application to read its own database, and on the upgrade path staying intact. If your notes are a long-term archive you intend to outlive any single program, that dependency is the cost of the features above.

Licence, maintenance and what an upgrade actually costs

TriliumNext/Trilium is licensed under AGPL-3.0. That is a strong copyleft licence, and it applies to the server component you would self-host and to the network service it exposes. The practical consequence for most readers is that running it for yourself is uncomplicated, while modifying it and offering it to others over a network carries source-disclosure obligations. This is a description of the licence family, not legal advice; if you plan to build on it commercially, read the LICENSE file in the repository root and take your own advice.

The repository is not archived, and the last push was on 2026-08-19, which is under a month before today. Releases are frequent: v0.104.0 on 2026-07-18, v0.104.1 on 2026-07-25, and v0.105.0 on 2026-08-19. A project on this cadence is actively developed, and the README also documents a nightly build tagged nightly that it describes as unstable and updated daily.

The upgrade cost is not the download. It is the sync version. The README states that versions up to and including v0.90.4 are compatible with zadam/trilium v0.63.7, and that later versions increment the sync version and prevent direct migration. If you run a desktop client, a server and a sync server, all three need to move together. The compose file's default latest tag works against that discipline, since it can change the server version without your involvement.

Editorial conclusion

Adopt Trilium if you keep tens of thousands of interlinked notes and want the data on a server you control, with per-note encryption and a REST API for automation. Do not adopt it if you need a native mobile app and nothing else, or if you expect plain Markdown files on disk. Before committing, verify the sync version boundary: the README states that versions after v0.90.4 increment the sync version, which prevents direct migration from zadam/trilium, so check that every instance you run sits on the same side of that line.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes