mdSilo: a local-first knowledge base where the web build swaps Tauri for IndexedDB
Lightweight Knowledge Base and Feed Reader. Web: https://mdsilo.github.io/mdSilo-app/
At a glance
- What is it?
- mdSilo is a React and Tauri note taking, knowledge base and feed reader that keeps your content in plain text files. Its web version keeps the same front end but replaces the Tauri APIs with IndexedDB stand-ins, which shifts the backup burden onto the user.
- Who is it for?
- mdSilo fits a writer who wants their notes as local plain text files with a full editor, a feed reader and a Kanban board over the same workspace, and who is willing to export a backup regularly. It does not fit a team that needs shared or synchronised notes, or anyone who will clear browser storage without keeping an export.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 6 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 October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Plain files on disk are the actual data model
mdSilo calls itself a local-first mind silo for storing ideas, thought and knowledge with an all-in-one writing tool, and the phrase that matters is local-first. The README states it sits on top of local plain-text files, with no registration required and no privacy issue, and it is available for Windows, macOS and Linux.
Everything else in the feature list hangs off that. The editor offers Markdown, WYSIWYG and MindMap views, with support for tables, math and chemical equations, highlighted code blocks, diagrams through mermaid and echarts, and exports to PDF and PNG. There is a full-text search, a graph view, a timeline described as a chronicle with a GitHub-like activities tracker, and a feed reader that handles RSS and Atom plus podcasts.
The part that gives it a real project-management dimension is the built-in issue tracker, which the README describes as GitHub-like. Issues carry labels, milestones, comments and a timeline, and there are project boards and tables on top of them. Two-way links tie issues to notes, with [[Note]] syntax inside an issue and [#12](issue:12) syntax inside a note, and the whole issue store is kept in an issues.json file in the workspace.
Keeping the issue data in a file next to the notes is the key design decision. It means the tracker is inspectable, greppable and versionable like everything else, and it means a workspace directory can be moved between machines without a sync service.
The technical stack is ProseMirror for the editor, React for the front end and Tauri for the cross-platform shell.
Building the desktop app needs Rust and Node together
The README's build instructions are short and assume two toolchains. You install Rust and Node.js, clone the repository, and run the Tauri build:
git clone https://github.com/mdSilo/mdSilo-app.gitcd mdSilo-appyarn && yarn tauri buildThe npm equivalent is given in the same line, npm install && npm run tauri build, for people who would rather not use Yarn. Either way the result lands in the ./src-tauri/target/release folder.
End users do not do this. The app is distributed as a release on the project's releases page, and there is a hosted demo at mdsilo.com/app/demo plus a Discord community linked from the README.
The package manifest shows how the project is organised underneath. There is a workspace package named mdsmirror that is built before the main bundle, and both the main build and the web build run yarn workspace mdsmirror build first. The manifest version is 0.6.1, and the licence field reads AGPL-3.0-or-later.
The script list also shows the shape of the toolchain. Vite serves and bundles the front end, vitest run is the test command with a coverage variant, eslint is invoked through a lint script that also has a lint-ignore variant which swallows failures, prettier writes formatting, and a tc script builds the workspace and runs tsc.
The web build replaces Tauri APIs with IndexedDB stand-ins
The web version is the more interesting engineering in the repository. It shares the front end code in ./src with the desktop app, but files are stored in the browser in IndexedDB instead of on disk, and no Rust is needed. Two scripts cover it:
yarn start:webwhich runs the dev server on http://localhost:3001, and:
yarn build:webwhich builds to ./dist-web, a static site that any web server can serve. The README notes that you can set MDSILO_WEB_BASE=/sub/path/ to serve it from a sub path.
The mechanism is a substitution rather than a rewrite. vite.web.config.ts replaces the Tauri APIs, @tauri-apps/api/* and @tauri-apps/plugin-dialog, with stand-ins in ./src/platform/web, and those stand-ins handle the same commands as the Rust end in src-tauri/src/lib.rs, but against a virtual file system held in IndexedDB. A service worker at ./web/public/fs-sw.js serves the stored files by URL so that images and attachments can be displayed. Folders and files on your device are imported through the Open Folder and Open File dialogs, and exported files are downloaded by the browser.
This is the pattern to understand about mdSilo. The product logic is written once against a small command surface, and two backends implement it. That is why the front end is shared and why the Rust side only needs to implement the same commands.
In the browser, Export Backup is the only copy of your notes
The README is unusually blunt about the consequence of the web storage model: clearing the site data of the browser deletes the notes. So the backup path is not optional, it is the only copy.
The mechanism is in the mdSilo menu at the top of the sidebar, under Export Backup, which downloads all files as a zip. To restore, you unzip it and import the folder via Open Folder and Import Folder.
That is a workable scheme, and it has the virtue of no server and no account. It also means the durability of your notes depends on a browser storage area that the user can wipe with a single click, on a backup habit, and on remembering that the export is a zip on the download folder rather than a synchronised copy on a second machine.
On the desktop side the same content sits in plain text files in a workspace directory, so a copy of the directory is a backup and a version control system can track it. The README's roadmap still lists version control, git integration as an unfinished item, which suggests the author has not yet built that path into the application itself.
For a note taking application, this asymmetry is the single most important thing to understand before choosing the web build over the desktop app. The features are the same; the failure modes are not.
RSS in a browser is a CORS problem with four fallbacks
The feed reader has one hard obstacle: browsers block most feeds by CORS. The README's solution is a two step fetch, where a feed is fetched directly first and then through a CORS proxy, and then a fallback chain of four proxies in order.
The first is a user setting under Settings and RSS CORS Proxy, where the URL format is https://proxy.example.com/?url={url}, with {url} replaced by the encoded feed URL, or the URL appended otherwise, and none to disable the behaviour entirely. The second is a build time default:
MDSILO_WEB_CORS_PROXY=https://proxy.example.com/?url={url} yarn build:webThe third is the built-in proxy at /__cors_proxy__ of yarn start:web or yarn preview:web, if it is detected. The fourth is a public proxy, allorigins, used on static hosting, and the README notes plainly that this one can see the feed URLs.
If you would rather run the proxy yourself, the README documents two routes with the same API, restricted to GET requests to public http(s) addresses. The Node version has no dependencies:
node web/cors-proxy.mjswith environment variables PORT, defaulting to 8787, HOST and ALLOW_ORIGIN. The Cloudflare Workers version covers static hosting with no server of your own, and the free tier is enough:
npx wrangler deploy web/cors-proxy-worker.mjs --name mdsilo-cors-proxy --compatibility-date 2024-09-01 --var ALLOW_ORIGIN:https://<your site origin>The deployment story follows the same pattern. The workflow .github/workflows/deploy-web.yml builds and deploys to GitHub Pages on push to main, or on demand, once Pages is switched to source GitHub Actions in the repository settings. With the secrets CLOUDFLARE_API_TOKEN, which needs Workers edit permission, and CLOUDFLARE_ACCOUNT_ID, it also deploys the Cloudflare Worker proxy and builds it in as the default. Otherwise you set the repository variable MDSILO_WEB_CORS_PROXY to point at an existing proxy. The other variables are MDSILO_WEB_BASE, defaulting to the repository name, MDSILO_WEB_ORIGIN, defaulting to the owner's github.io origin, and MDSILO_CORS_WORKER_NAME.
Kanban boards are migrated from an older kanban.json
The Projects feature is the part of mdSilo that most resembles a work tracker, and it has a migration story worth knowing. Boards from the old kanban.json file are moved into Projects automatically, with a backup kept as kanban.json.bak.
That is a small detail with a large consequence. When you upgrade an old workspace, the board data moves into the new system on its own, and the original file is left alongside it. If the automatic migration misreads something, the original is still there, and the .bak file means you can also see what the board looked like before the move. For an application that keeps everything in files next to your notes, that kind of reversibility is the point.
The feature list also mentions that Projects exist to make a personal knowledge base a serious project, and the screenshot section describes the Kanban board as a way to manage the process of the knowledge base growing. In other words, the board is not tracking external work items, it is tracking your own writing backlog.
The Issues and Tasks views complete the loop. Tasks can be written as #todo#, #doing# and #done# tags, or as checkboxes in notes, and the README says they are turned into issues that stay in sync. The two-way linking syntax then lets a task point at the note that carries the detail, and the note point back.
ProseMirror, CodeMirror, d3 and fuse.js in one dependency list
The dependency list in package.json shows what each part of the interface is built from. The editor is ProseMirror, with CodeMirror and its markdown and json language modes alongside @codemirror/state and @codemirror/view, plus @lezer/markdown. Tailwind handles styling with a typography plugin and a forms plugin, and @headlessui/react and @popperjs/core cover the interactive pieces.
The graph view is d3. The dependency set includes d3-force for the force simulation, d3-zoom for navigation, d3-drag and d3-selection, which together explain why the graph view can be panned, zoomed and dragged rather than being a static picture.
Search is fuse.js, a fuzzy matching library, and immer appears in the list, which is the usual way to handle immutable state updates in a React application. is-hotkey handles the hotkeys, html2canvas is there for image export, and @react-spring/web covers animation, with @dnd-kit providing drag and drop for the Kanban boards.
The Tauri side is version 2 of the API, with @tauri-apps/api at ^2.12.0 and @tauri-apps/plugin-dialog at ^2.8.0, which is the package that supplies the Open Folder and Open File dialogs on the desktop and the Open Folder import path in the browser build.
The roadmap lists what is not done yet, and it is worth reading as a gap list: viewing and annotating PDF and epub, drawing, block references, flashcards, and version control with git integration. Everything else in the checklist is marked complete.
AGPL, a release gap and where mdSilo is the wrong tool
mdSilo is licensed under AGPL-3.0, and the manifest declares AGPL-3.0-or-later, with the LICENSE file at the root of the repository. For a desktop application and a self-hosted web build, the copyleft obligations attach to what you distribute, so a modified build that you ship carries the requirement to offer the corresponding source under the same terms. Read the file for the exact wording, and this is not legal advice.
The release history has an odd shape. The tagged versions are mdsilo-v0.6.0 on 2026-10-07 and mdsilo-v0.5.10 on 2026-09-21, but before them sits app-v0.5.9 from 2024-03-03, and the naming convention changed with them. The last push was on 2026-10-17 with the repository not archived, so work continues even though the release labels are inconsistent.
The wrong fits are clear. mdSilo is a single-user, local-first tool, so it is the wrong choice for a team that needs shared or synchronised notes, because there is no account, no server and no collaboration model, and the web version only puts a service worker and IndexedDB between you and the browser's storage. It is also the wrong choice for anyone who wants their notes in a standard markdown folder without the application, since the issue tracker and the Kanban boards live in issues.json and in the application, not in markdown files you would read anywhere else.
And the RSS fallback chain deserves one final look. The last resort is a public proxy that can see your feed URLs, which is a reasonable default for a demo and a poor default for a daily reader, so set the proxy deliberately before you start subscribing to anything.
Editorial conclusion
mdSilo fits a writer who wants their notes as local plain text files with a full editor, a feed reader and a Kanban board over the same workspace, and who is willing to export a backup regularly. It does not fit a team that needs shared or synchronised notes, or anyone who will clear browser storage without keeping an export. Before adopting the web build, set up the RSS CORS proxy deliberately, because the fallback order ends at a public proxy that can see your feed URLs.
Frequently asked questions
What is mdSilo and what does it store?
It is a local-first knowledge base and feed reader built with React and Tauri, with a ProseMirror editor offering Markdown, WYSIWYG and MindMap views, plus a feed reader, a graph view and an issue tracker with Kanban project boards. On the desktop the data is plain text files on disk, with the issue store kept in issues.json in the workspace.
How do I build mdSilo from source?
Install Rust and Node.js, clone https://github.com/mdSilo/mdSilo-app.git, change into the mdSilo-app directory, then run yarn && yarn tauri build or npm install && npm run tauri build. The built application ends up in the ./src-tauri/target/release folder.
How does the web version of mdSilo differ from the desktop app?
The web version shares the front end code in ./src but stores files in the browser's IndexedDB instead of on disk, and it needs no Rust. vite.web.config.ts swaps the Tauri APIs for stand-ins in ./src/platform/web that handle the same commands against a virtual file system, with a service worker serving the stored files by URL.
How do I back up notes in the mdSilo web version?
Use the mdSilo menu at the top of the sidebar and choose Export Backup, which downloads all files as a zip. To restore, unzip it and import the folder through Open Folder and Import Folder. The README warns that clearing the browser's site data deletes the notes.
How do RSS feeds work in the mdSilo web version?
Browsers block most feeds by CORS, so a feed is fetched directly first and then through a CORS proxy. There are four fallbacks in order: the RSS CORS Proxy setting, the build time default MDSILO_WEB_CORS_PROXY, the built-in /__cors_proxy__ of the dev or preview server, and finally a public proxy such as allorigins, which can see the feed URLs.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/mdsilo-mdsilo-app)Was this useful?