# Logseq: a knowledge base that tells you data loss is possible

> logseq/logseq is a Clojure and ClojureScript note-taking and collaboration platform licensed AGPL-3.0, shipping a desktop beta, an iOS alpha and a nightly build. Its own README says the DB version can lose data and sends DB bug reports to a different repository, which is the most important thing to read before you put notes in it.

**logseq/logseq** — GitHub describes it as A privacy-first, open-source platform for knowledge management and collaboration. Download link: http://github.com/logseq/logseq/releases. roadmap: https://logseq.io/p/NX4mc ggEV. The repository metadata lists Clojure as its primary language. The metadata lists the AGPL-3.0 license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/logseq/logseq
- Website: https://logseq.com
- Stars: 45,105 · Forks: 2,828
- Language: Clojure
- License: AGPL-3.0
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/logseq-logseq

## The DB version is in beta and the README says data loss is possible

The most consequential sentence in this README is a warning. The DB version is in beta while the new mobile app and the RTC sync approach are in alpha, and the text says plainly that data loss is possible. The advice that follows is to set up automated backups or regular SQLite DB backups, and to create a dedicated test graph and choose one project that is not crucial to you.

That is the project's own instruction, not an editorial caution, and it changes what kind of tool Logseq is in 2026. The DB version introduced DB graphs, and the sync story is a new approach called RTC, Real Time Collaboration, which is in alpha behind its own sign-up form. The mobile app for DB graphs exists on iOS with Android described as coming soon.

So the practical reading is: the file format you trust and the graphs you have accumulated are not the same thing as the current database. Treat a migration as a project with a rollback, and take the backup advice as a requirement rather than a precaution.

## DB bugs go to logseq/db-test, and feature requests go to a Discord channel

The reporting routes are split, and not where you would look first. Bug reports for the DB version are filed at github.com/logseq/db-test/issues, which is a different repository from the one you cloned. Feature and enhancement requests go to the #db-feedback channel on Discord, and discussions are spread across #db-chat for general topics, #sync-test for sync and RTC, and #mobile-test for mobile.

The consequence is practical for anyone adopting this. Watching the issue tracker of logseq/logseq does not surface DB version bugs, and a feature request that lives in a chat channel has no issue number, no status and no search history you can return to in six months. If you are evaluating the DB version, the logseq/db-test issue list is the more honest signal of its state, and it is a different URL to bookmark.

The community routes follow the same split. The README links a forum at discuss.logseq.com and a Discord invite at discord.gg/KpN4eHY, plus a roadmap page at logseq.io/p/NX4mc_ggEV that is a Logseq page rather than a document in this repository.

## test/db and master are two different products on two update clocks

If you build from source, the README asks you to choose a branch deliberately, and it describes both in terms of bugs and update frequency. Use test/db for stable releases: fewer bugs, slower updates, an update frequency of days or weeks. Use master for the latest changes as they are developed: expect more bugs and faster changes, an update frequency of hours or days.

That is an unusually honest pair of descriptions, and it tells you the project itself considers master a different product from what most users should run. The default branch of the repository is master, so a clone with no arguments gives you the fast one.

The trap is that the containerised build ignores your choice. The Dockerfile clones the master branch from GitHub directly, so a Docker image built from a test/db working tree still contains master. Anyone using that image to evaluate the stable line is measuring the wrong thing unless they edit the branch in the Dockerfile first.

## The Docker build clones master from GitHub and edits a release channel by hand

The Dockerfile begins with three NOTE comments that describe its own maintenance problem: keep it in sync with the .github pipelines, change the branch during testing, and before running the build-docker GitHub action, edit build-docker.yml and change the release channel from :latest to :testing. The image is not parameterised; a behaviour change is a source edit in two files.

What the build does is worth knowing. The builder stage starts from clojure:temurin-11-tools-deps-1.11.1.1208-bullseye-slim, installs the C and Cairo toolchain, then pulls Node from nodesource setup_24.x and activates pnpm 10.33.0 through corepack. It then throws away whatever tree you are standing in:

```dockerfile
# build Logseq static resources
RUN git clone -b master https://github.com/logseq/logseq.git .
```

The install is given a raised network timeout, and the build ends by running the release script:

```bash
RUN pnpm install --config.network-timeout=240000
RUN pnpm release
```

The final stage is nginx:1.24.0-alpine3.17 with the built static files copied into the web root. So the artifact is a static web app behind nginx, not a desktop build, and the image content is decided by whatever master was when the clone ran.

## Java 11 builds the ClojureScript, Node 24 builds the front end, and the floor is 22.20.0

Two toolchains, and they are not the same age. The container compiles Clojure and ClojureScript on a Java 11 Temurin image, installs libcairo2-dev, libpango1.0-dev, libjpeg-dev, libgif-dev and librsvg2-dev for rendering, and only then installs Node 24 from the nodesource repository and turns on corepack for pnpm 10.33.0.

The manifest states its own floor lower than that. package.json sets engines node to >=22.20.0 and pins packageManager to pnpm@10.33.0, which matches what the image activates, so the pnpm side is consistent while the Node side is not pinned to the version the build uses. A developer on Node 22 satisfies the manifest and is not on the version the container installs.

This is a polyglot build tree rather than a single-language project. There is deps.edn and bb.edn for the Clojure side, shadow-cljs.edn for the ClojureScript compiler, a pnpm workspace with pnpm-workspace.yaml and pnpm-lock.yaml, capacitor.config.ts with ios/ and android/ directories for the mobile shells, fastlane/ for store automation, and a Dockerfile for the web app. A first-time contributor is installing a Clojure toolchain, a Node toolchain and a mobile toolchain before writing a line.

## Webpack, Vite, shadow-cljs and gulp run at the same time in one watch script

The devDependencies carry two JavaScript bundlers and a ClojureScript compiler side by side: webpack ^5.106.2, vite ^8.0.10, shadow-cljs ^3.4.6, gulp ^5.0.1, tailwindcss 4.3.0, typescript ^5.9.3, plus playwright and @playwright/test for browser tests. The scripts show which combination is live at once, since watch runs three of them in parallel:

```bash
"watch": "run-p gulp:watch cljs:watch webpack-app-watch"
```

There are sibling scripts for the electron target, the app target and the mobile target, each with a different set of watchers, and a dev script that adds gulp:mobile-watch and cljs:dev-watch. A ClojureScript change goes through the shadow-cljs compiler, styles go through gulp and postcss with tailwind, and the JavaScript bundle comes out of webpack, with vite also in the tree.

Two consequences. First, a broken watcher is hard to localise, because four build processes are writing into the same output tree and a failure in one looks like a failure in the page. Second, better-sqlite3 ^12.9.0 sits in devDependencies, which is a native module: a contributor whose platform has no prebuilt binary compiles it. The e2e suites are split into cli-e2e/ and clj-e2e/, matching the two halves of the build.

## The CLI is private to the app, and an agent skill ships beside it

There is a command line tool, and the manifest is where you learn what it is and who gets it. The package is named logseq, versioned 0.0.1, and marked private, which means nothing is published to the registry under that name. The binary is declared anyway, and the files list shows what would ship:

```json
"packageManager": "pnpm@10.33.0",
"main": "static/electron.js",
"bin": {
  "logseq": "dist/logseq.js"
}
```

The files list covers dist/, static/logseq-cli.js and .agents/skills/logseq-cli/SKILL.md. That last entry is the one to notice: a skill document for the CLI is part of the published surface, sitting in the same .agents/ directory you can see at the root. The CLI is meant to be driven by an agent as well as by a person, and the skill file is how that is described.

For a user the practical consequence is that the CLI is reached through the application install rather than by installing a package, since private means there is nothing on the registry to install. The root also holds cli/, sidecar/, bin/ and scripts/, so the CLI source is in the tree, but there is no registry route to it.

## Version numbers jumped from 0.10 to 2.0, and both are marked beta testing

The release titles are more informative than the numbers. 0.10.15 is Desktop/Android APP 0.10.15 (Beta Testing), published on 2025-12-01. 2.0.1 is Desktop APP 2.0.1 (Beta Testing), published on 2026-07-13. Above both sits a rolling nightly, Desktop app Nightly Release 20260926, published on 2026-09-26. The last push to the default branch, master, was on 2026-09-29, and the repository is not archived.

Read the titles together and the shape is clear. A 0.10 line that covered desktop and Android, a 2.0 line that is desktop only and still labelled beta, and a nightly that is the only thing shipping frequently. The 2.0.1 desktop beta is roughly two and a half months old, which is a long time to be the newest numbered build when a nightly from four days ago is also available.

The licence is AGPL-3.0, the reciprocal GNU licence, and the README does not discuss it. For an individual keeping personal notes that has no practical effect. For a team running a modified Logseq on a server where others reach it, the obligations that licence carries are worth reading in the file itself before you deploy it.

## Conclusion

Logseq suits someone who wants Markdown or Org-mode files they own, tolerates a product in beta, and will run a backup because the README tells them to. It does not suit a team that needs a stable file format, an Android client today, or an issue tracker in this repository, since DB bugs go to logseq/db-test. Verify first whether your notes are safe in the version you install, by testing the documented backup path on a graph you do not mind losing, since the DB version is in beta and the README states data loss is possible.

## FAQ

### What is Logseq used for?

It is a knowledge management and collaboration platform that focuses on privacy, longevity and user control, with tools for notes, collaboration, PDF annotation and task management. It supports Markdown and Org-mode, has a plugin and theme ecosystem, and mobile apps that reach most of the desktop features.

### Is Logseq fully free?

The project is licensed AGPL-3.0 and the README shows no paid tier or pricing. It does ask for support, with sponsor and backer sections pointing at Open Collective alongside the standard GitHub Sponsors route, and the download links in the README go to the GitHub releases page.

### What are Logseq's disadvantages?

The README names them. The DB version is in beta and the mobile app and RTC sync are in alpha, and the text says data loss is possible, which is why it recommends automated or regular SQLite backups. The mobile app for DB graphs is on iOS with Android coming soon, and DB bug reports go to the separate logseq/db-test repository rather than to this one.

### how to install logseq

Download the latest version from the GitHub releases page, install it on the device and launch it. Linux users are pointed at an automated installer script instead of a package, and there is also a web version at app.logseq.com plus a Dockerfile that builds the static web app behind nginx.

### how to use logseq db version

Try it at app.logseq.com for the web build, or download the artifact for your operating system from the nightly release tag. To build from source, use test/db for stable releases with fewer bugs and days or weeks of update frequency, or master for the latest changes with more bugs and hourly or daily updates.

## Sources

- [Official documentation](https://logseq.com)
- [Official README](https://github.com/logseq/logseq#readme)
- [Project repository](https://github.com/logseq/logseq)
- [Release notes](https://github.com/logseq/logseq/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/logseq-logseq