Can I use bkywksj/knowledge-base commercially?

Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.

Is bkywksj/knowledge-base still maintained?

Yes. The repository last received commits 5 days ago.

What programming language is bkywksj/knowledge-base written in?

Mainly TypeScript, according to GitHub's language statistics.

bkywksj/knowledge-base: local-first Markdown KB

At a glance

What is it?: A local-first Markdown knowledge base built on Tauri 2.x, React 19, Rust and SQLite, with FTS5 full-text search, a knowledge graph, incremental WebDAV or S3 sync and an OpenAI-compatible AI layer. The AGPL-3.0 licence is the first thing to check before you build on it.
Who is it for?: Adopt it if you want a self-hosted Markdown vault with FTS5 search, wikilinks and file-level sync you control, and you are comfortable with AGPL-3.0 or willing to buy the commercial licence. Do not adopt it if you need a documented public API, a stable plugin ecosystem, or a licence you can embed in closed-source software without paying.
Can I use it commercially?: Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?: Yes. The repository last received commits 5 days ago.
What is it written in?: Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 16, 2026 · bkywksj/knowledge-base

What bkywksj/knowledge-base is for

This is a desktop application for people who keep notes as Markdown files and want search, linking and sync without handing the corpus to a hosted service. The README describes it as a local knowledge base desktop app with full-text search, bidirectional links and a knowledge graph, and the repository topics list fts5, webdav, sqlite, tauri and markdown alongside ai-assistant. The stated design goal is zero cloud dependency.

The audience is narrower than the phrase knowledge base software suggests. It suits an individual or a small team that already thinks in folders of .md files and wants an editor, a graph view and an index on top of those files. It does not suit an organisation looking for a multi-tenant help centre with public article URLs, because nothing in the README describes a web publishing surface. The homepage at kb.ruoyi.plus is the documentation site, not a hosted product.

The import path is broader than Markdown alone. The repository description lists .md, .txt, .pdf and .docx with automatic encoding sniffing, so a mixed archive of exported documents can be pulled in. That is the practical entry point for most people: point it at a folder, let it sniff encodings, then rely on FTS5 rather than folder names to find things again.

Architecture: Tauri shell, Rust core, SQLite with FTS5

The stack is split in a way that matters for anyone evaluating maintenance cost. The frontend is React 19 with TypeScript, built by Vite, and the native shell is Tauri 2.x. The package.json shows CodeMirror 6 packages for Markdown editing, TipTap extensions for a rich editing mode, AntV G6 for graph rendering, Excalidraw for diagrams and TanStack Virtual for long lists. The Rust side lives in src-tauri and owns SQLite, where FTS5 provides the full-text index.

So the data flow is: files on disk, an index in SQLite, a React UI reading through Tauri commands. Search is not a scan over the filesystem at query time; it queries the FTS5 index. Bidirectional links and the knowledge graph are derived from note content and stored so the graph view can render without re-parsing everything.

Sync is the part with the most design decisions. The repository description gives note-level granular incremental sync with automatic bidirectional scheduling, plus whole-vault ZIP backup, over WebDAV, S3 or a sync folder. Note-level granularity is a deliberate trade-off: it avoids uploading a monolithic database file that would conflict when two machines write at once, but it means the sync layer has to reason about per-note conflicts rather than deferring to the storage provider. The README does not describe a conflict resolution policy, which is the gap to probe before trusting it with two active machines.

Installing bkywksj/knowledge-base and taking a first note

The README documents the development path rather than a binary download. It gives pnpm install followed by pnpm tauri dev, and pnpm tauri build for a release build. The package.json confirms the tauri script and adds tauri:dev and tauri:build as aliases, so either spelling works. There is an INSTALL.md at the repository root, which is where platform-specific prerequisites should live; the README itself does not list them, so read that file before assuming a toolchain is complete.

bash

pnpm install
pnpm tauri dev

Running the second command compiles the Rust side and opens the desktop window. Expect a first build to take a while, since Tauri compiles the native crate. The dev script also has a dev:clean variant that kills port 1421 first, which tells you the Vite dev server uses that port if it is already occupied.

bash

pnpm tauri build

The build command produces the distributable application. The repository description mentions in-app auto-update, and @tauri-apps/plugin-updater is present in the dependencies, so release builds are the ones that can receive updates. A dev build is not the thing you test update behaviour with.

Once the window is open, the first real task is pointing the app at your notes. The repository description lists a custom data directory, so the vault location is configurable rather than fixed. Import is the second step: .md and .txt files come in directly, and .pdf and .docx go through the importer with encoding detection. After import, search goes through FTS5, so you search for words you remember rather than browsing a tree.

bash

pnpm test

If you are modifying the frontend, the vitest suite runs with pnpm test and watches with pnpm test:watch. There is also build:mcp, which builds an MCP bundle from scripts/build-mcp.mjs; the README does not explain what consumes it, so treat that as an open question rather than a documented feature.

The AGPL-3.0 licence is the real adoption gate

The README is unusually direct about licensing, and this is the section most evaluators should read first. The project is dual-licensed: AGPL-3.0 plus a commercial option. The README's own table says personal, research and non-commercial use is free under AGPL-3.0; internal enterprise tools that are not distributed are free; and open-source derivative work must stay AGPL-3.0. Closed-source commercial distribution, SaaS deployment without publishing source, and embedding into proprietary software for redistribution all require a paid commercial licence.

The package.json declares AGPL-3.0-or-later, while the repository metadata reports NOASSERTION, which is what GitHub shows when it cannot match the LICENSE file to a known identifier. The README and package.json agree with each other; the metadata field is the outlier. If licence terms decide your adoption, read LICENSE and COMMERCIAL-LICENSE.md directly rather than the sidebar badge. I am not giving legal advice here, and the AGPL network clause is exactly the kind of thing your counsel should read, not a summary.

The contribution terms compound this. CONTRIBUTING.md requires a CLA, and the README states that pull requests without the CLA checkbox will not be reviewed. That is a coherent position for a dual-licensed project, since the maintainer needs the right to relicense contributions commercially. It also means external contributors give up more than they would under a plain inbound-equals-outbound licence. Weigh that before planning to fork and upstream fixes.

Where it is the wrong tool, and what to use instead

The clearest limitation is the absence of a documented public API or plugin interface in the README. There is an MCP build script, and the AI layer has a tool-calling framework, but nothing in the README describes a stable extension surface for third parties. If your requirement is scripting the knowledge base from outside, or writing plugins that survive upgrades, this project does not promise that.

Sync conflict handling is the second gap. Note-level incremental sync is a reasonable design, and whole-vault ZIP backup is a sensible escape hatch, but the repository description does not state what happens when the same note is edited on two machines before either syncs. Anyone running it on a laptop and a desktop should test that scenario deliberately before trusting it.

The natural alternative is Obsidian. Obsidian also works on a folder of Markdown files, also has backlinks and a graph view, and has a large plugin ecosystem with a documented API. The difference in approach is where the logic lives: Obsidian's extensibility is in JavaScript plugins running in the app, while this project puts search, indexing and sync in a Rust core with SQLite and FTS5 underneath. If you want to write your own plugins, Obsidian is the better fit. If you want the index and the sync engine to be native code you can read in src-tauri, this project is the more inspectable one. The other difference is cost and licence: Obsidian is not AGPL, so the licensing calculus is entirely different.

A second alternative for the search layer alone is a plain FTS5 index you build yourself over a notes directory. That gives you exactly the query semantics you want with no application attached, at the cost of writing the editor, the graph and the sync yourself.

Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-11. Releases are frequent: v1.62.0 on 2026-09-01, v1.52.0 on 2026-08-05, and v1.51.0 the day before that. The version in package.json is 1.62.0, matching the latest release tag, so the manifest and the release line are in step. A cadence of roughly a release per month with occasional same-week pairs suggests active work, and the minor version jumps between 1.51 and 1.62 over a month indicate feature-level changes rather than patch-only maintenance.

That cadence is also the upgrade cost. For a user of release builds, @tauri-apps/plugin-updater means updates arrive in-app, so the cost is low. For someone building from source, each upgrade means pulling and rebuilding the Rust crate, which is the slow part of pnpm tauri build. For someone who has forked, the CLA and the AGPL relicensing requirement shape how much of your work you can keep private.

The dependency surface is wide: CodeMirror, TipTap, AntV G6, Excalidraw, dnd-kit, Ant Design icons and a dozen Tauri plugins. Each is a moving part you inherit. The mitigating factor is that the lockfile (pnpm-lock.yaml) is committed, so a build is reproducible until you run pnpm update. If you are pinning for a team, pin the lockfile and treat dependency bumps as their own change, not as part of a feature pull.

Editorial conclusion

Adopt it if you want a self-hosted Markdown vault with FTS5 search, wikilinks and file-level sync you control, and you are comfortable with AGPL-3.0 or willing to buy the commercial licence. Do not adopt it if you need a documented public API, a stable plugin ecosystem, or a licence you can embed in closed-source software without paying. Before committing, verify three things: that INSTALL.md covers your platform, that your sync target (WebDAV or S3) is one the app actually supports, and that the CLA requirement in CONTRIBUTING.md is acceptable to your contributors, because unapproved PRs are not reviewed.

Frequently asked questions

What is bkywksj/knowledge-base an example of?

It is an example of a local-first desktop knowledge base: Markdown files on disk, an FTS5 index in SQLite, and a Tauri 2.x shell around a React 19 frontend. The README describes it as a desktop app for full-text search, bidirectional links and a knowledge graph, with zero cloud dependency.

What does the AI layer in bkywksj/knowledge-base do?

The repository description lists AI question answering and planning through OpenAI-compatible endpoints, Ollama or a custom provider, built on a tool-calling framework. The README does not document the available tools or how the provider is configured, so that detail has to come from the documentation site.

Which is correct, knowledgebase or knowledge base?

The project uses the two-word form in its README title, and the package name is knowledge_base with an underscore. The repository name on GitHub is knowledge-base with a hyphen. Pick one form for your own writing and stay consistent; the project itself is not consistent across these three places.

What is the best knowledge base for local Markdown files?

That depends on whether you want native code or plugins. bkywksj/knowledge-base puts search, indexing and sync in a Rust core with SQLite and FTS5, while Obsidian keeps extensibility in JavaScript plugins running inside the app. The README does not make a comparison claim either way.

How do I use Obsidian as a knowledge base, and how does bkywksj/knowledge-base differ?

Both work on a folder of Markdown files with backlinks and a graph view. The difference is where the logic lives: Obsidian's extension model is JavaScript plugins with a documented API, while this project keeps the index and sync engine in the Rust side under src-tauri and does not document a plugin interface.

How do I use AI to create a knowledge base with bkywksj/knowledge-base?

The repository description lists an AI question-answering and planning layer with a tool-calling framework, configurable against OpenAI-compatible endpoints, Ollama or a custom provider. The README does not give setup steps for a provider, so check the documentation site before assuming a default.

Official sources

Community notes