Nolebase: a VitePress knowledge base you can also open in Obsidian

Every page is a Markdown file, and that is the point

Nolebase describes itself as a place to record memories, knowledge and ideas, and the name is explained in the README. It is written Nolebase, read as nole-base, taken from the Quenya word for knowledge and the English word for base, so the name means knowledge base. The features list has four items. There are varied themes and content, since the knowledge base and the pages it generates are maintained by the creators and cover many areas of life, including memories and musings as well as knowledge. Everything is Markdown, written and recorded with Markdown and Markdown extension syntax, so every page is a Markdown file. The site is driven by VitePress, a static documentation generator based on Vite that generates the pages of the knowledge base with themes and tooling. And the notes are driven by Obsidian, a knowledge base management tool with a large plugin and extension ecosystem. The primary language of the repository is recorded as Markdown, which is unusual and correct for this kind of project, since the content is the deliverable.

It runs offline, and that changes who can use it

The README makes a point that is easy to miss and that shapes the whole project. Nolebase can be used completely locally with no network at all. You can download or clone it and open it with knowledge base software such as Obsidian and Logseq, or open it with a Markdown editor such as Typora to browse and edit. The stated consequence is that even someone with no programming skills can use the knowledge base, or borrow its classification and organisation methods. The same property is what makes the GitHub download instructions exist at all, since the README suggests using GitHub's own download source archive option for readers who are not comfortable with the command line and Git. That is a deliberate design constraint. The site is a rendering of the notes rather than the notes themselves, and the notes stay usable if the site, the author, or the whole toolchain goes away.

How the site is built and deployed

The README compares Nolebase to blogs and static sites driven by Hexo, and explains that it uses a static generator called VitePress, which supports embedding Vue components in Markdown files to enrich the reading and use experience. VitePress and Vue are part of the Node.js ecosystem and both belong to the front end. On the deployment side the site is hosted on free Netlify, and GitHub Actions automatically builds and deploys the notes and knowledge base content to Netlify whenever the content is updated in the GitHub repository, which the README describes as an automation that triggers after each update. The package.json shows the same picture in script form, with the top level commands delegating to the VitePress ones and an update script that runs a TypeScript file:

  "scripts": {
    "dev": "pnpm run docs:dev",
    "build": "pnpm run docs:build",
    "serve": "pnpm run docs:serve",
    "docs:dev": "vitepress dev",
    "docs:build": "vitepress build",
    "docs:serve": "vitepress serve",
    "update": "tsx scripts/update.ts",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

The test script is the default placeholder that fails, which is honest for a content repository, and the update script is the one worth looking at, since it is the piece that regenerates something from the notes.

The plugin list is the real engineering

The dev dependencies in package.json are where the substance sits, and they are a list of VitePress plugins published under the nolebase scope. There is a bidirectional links plugin for the markdown-it layer, an unlazy image plugin, a plugin for enhanced mark handling, one for enhanced readabilities, a git changelog plugin, a plugin to highlight the targeted heading, an index plugin, an inline link preview plugin, a meta plugin, an open graph image plugin, a page properties plugin and a sidebar plugin. There is also a general integrations package, a markdown-it plugin set for HedgeDoc, and a set of Iconify icon collections for EOS, Iconify's own set, Octicon and SVG spinners. What this tells you is that the project is not a thin VitePress theme. It is a compatibility layer, and the list of plugins maps directly onto the features an Obsidian user expects, which is the gap the README spends most of its length discussing.

Why not Obsidian Publish

The README has a section asking how this differs from Obsidian Publish, and answers it in two numbered reasons. The first is cost. Obsidian Publish has to be paid for, while for a static site you can use ready-made infrastructure such as GitHub Pages, Netlify, Vercel and Cloudflare Pages for free. The second is the plugin problem, and it is the serious one. The static pages produced by Obsidian Publish do not support Obsidian's own plugin features, which means documents that use plugin syntax work fine when previewed locally in Obsidian but become unusable once published. The README calls this a critical problem, notes that many users rely heavily on the Obsidian plugin ecosystem, and says there is still no fully satisfactory solution. The project created a separate integrations repository to attempt substitute implementations of common Obsidian plugins for VitePress and Vue, and acknowledges that these substitutes cannot fully replace the originals but can provide similar functionality in part.

When Obsidian Publish is the better answer

The README is even-handed about this, and gives two reasons to choose the hosted service instead. The first is that finding Markdown plugins that work with VitePress is difficult and complex, while Obsidian Publish natively supports all the syntax and plugins Obsidian supports, which saves the research and trial and error. The second is that running and deploying a static site like Nolebase is much harder for an author without code or programming knowledge, while Obsidian Publish requires no code and no technical detail, in the same way that sharing a Notion page does, and deployment is a few clicks. The conclusion in the README is that if you do not have the necessary programming skills, or do not want to spend the time and energy to learn and master them, Obsidian Publish is probably the better choice. That is a fair, and slightly unusual, thing for a project to write about its own main alternative.

A template, and the projects already using it

The README asks whether others are using VitePress as a deployable knowledge base, and answers with a list of projects it found on GitHub. Among them are a personal knowledge base and blog built on VitePress, a notes repository, a learning notes blog, a front end content site with learning paths and a knowledge system, and a personal knowledge base based on Nolebase itself, which is a useful signal that the project is used as a starting point rather than only read. The list also includes documentation sites for specific technologies, which shows the other direction, a VitePress setup used as a manual rather than as a personal notebook. The top level of the repository reflects the same reuse orientation, with a `zh-CN/` directory for the Chinese content, a `metadata/` directory, a `netlify/` directory alongside a `netlify.toml`, a `scripts/` directory, a `.vitepress/` directory, a `.obsidian/` directory holding the Obsidian configuration, a `public/` directory and an `uno.config.ts` with a `vite.config.ts`.

What this is not

The limits are worth stating plainly. First, the content is Chinese, and so is the documentation, so an English speaking reader will find the notes themselves inaccessible even though the structure and the tooling are readable in English. The repository carries a README_EN.md, but the notes are the point and they are in one language. Second, the plugin layer is a partial reimplementation, as the README says, so a note that depends on an Obsidian plugin the integrations project has not covered will not render as intended, and the failure will be silent in the sense that the site still builds. Third, the whole thing assumes you are willing to run a Node toolchain to publish, which the README itself says is much harder than the hosted alternative. Fourth, the plugin set is versioned tightly against the nolebase scope packages, all pinned at 2.18.2 in the dev dependencies, and the integrations package is a fixed 2.18.2, so upgrading means moving that pin. Fifth, the licence situation is two-layer. The code is MIT, and there is a separate Creative Commons licence file in the repository, so the notes and the tooling are covered separately, which is the right arrangement for a knowledge base but worth knowing before you copy either half.

Editorial conclusion

Nolebase fits an author who writes in Obsidian, wants the notes to be plain Markdown files that survive any tool, and is willing to maintain a small VitePress configuration to get a hosted site out of them. It is the wrong choice if you want to publish without touching code, since the README is explicit that running a static site like this is much harder than clicking through Obsidian Publish, and the wrong choice if your notes depend on Obsidian plugins the project has not reimplemented. Before you fork it, read the section on why Obsidian Publish was not used, and look at the integrations project, because that is where the gaps between the two tools live. The last push was on 2026-10-16, the repository publishes no GitHub releases, and the code is MIT licensed with a separate Creative Commons licence for the content.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nolebase/nolebase on GitHub
4. Project website
5. README