Below are some concepts that are helpful to know when using Dendron. Note that features with šŸš§ are still under active development and might not be fully implemented.


Dendron supports markdown, a popular markup syntax that is like HTML but 1000x simpler. If you are new to markdown, you can read about the syntax here.


Frontmatter is a convenient way of adding extra information to your documents like a shorthand title or longer description (think any extra information you can use to describe a note). This type of information is generally called metadata and the structure used is called YAML. You can add it to the front of your markdown file and it won't show up in the preview. It was first introduced by jekyll.

You can read more about the frontmatter used in Dendron here


In Dendron, your workspace is the root of where all your files are located. It's set when you first run Dendron: Initialize Workspace. The folder that contains your workspace is also known as your workspace root.

A workspace has a dendron.yml file that specifies its vaults.


Code Workspace

A workspace that is created using dendron.code-workspace file.

Native Workspace

A workspace that is created with a dendron.yml file and lacking a dendron.code-workspace file.

Bare Workspace

A bare workspace is a workspace where all vaults inside are remote vaults (separate git repos). You can have a bare code workspace or a bare native workspace.


Workspace: Add and Commit

Add and commit all notes across all vaults to git.

Workspace: Sync

Synchronizes all notes across all vaults with git. Any changes you made will be pushed back to remote, and any changes in the remote will be pulled.

In more detail: Dendron will first commit all your changes, then pull changes from the remote, and finally push everything back to the remote. This workflow is good in most cases: private notes, internal shared vaults, or your personal writings. This workflow doesn't work as well in some cases however, so we offer per-vault configuration options which you can use to adjust how your notes are synchronized.

You can set these configuration options in your dendron.yml, either for each vault with the sync option, or for all workspace vaults with the workspaceVaultSync option. The configuration will look like this:

... rest of your dendron.yml
workspaceVaultSync: noPush
        fsPath: my-website
        sync: noCommit
            type: git
            url: ''
        fsPath: my-notes
        sync: sync
        type: git
            url: ''

configuration options


Dendron will try to synchronize everything: Dendron will first commit all your changes, then pull changes from the remote, and finally push everything back to the remote. This is the default for regular vaults.


Pull and push updates if the workspace is clean, but don't commit. You manually commit your local changes, but automatically share them once you committed. This is good for vaults where you want to write a meaningful commit message and control what is being committed, for example a shared knowledge base or wiki. This is the default for Workspace Vaults.


Commit any changes and pull updates, but don't push. You can watch the repository and make local changes without sharing them back. This is good if you want to watch the updates in a vault and maybe even note your own thoughts in the vault without sharing them, for example an organization handbook that you don't want to edit yourself.


Don't do any synchronization. This may be useful if you use some other tool to synchronize this vault.

Workspace Types

Dendron recognized 2 types of workspaces, Code and Native. When you initialize your workspace with the Initialize Workspace command, you get a Code workspace. Code workspaces include a dendron.code-workspace file which sets up vaults and recommends installing some useful extensions. Code workspaces are great when you are setting up a knowledge base.

Native workspaces on the other hand don't have a dendron.code-workspace file. They are useful when you are writing notes or documentation, and you want to keep your notes as part of a project rather than a separate knowledge base.

See Native Workspace Setup to see how you can start using a native workspace!


Syncing your workspace with Git

Workspace Sync does not sync the workspace if all your vaults are separate git repos. In order to synchronize your workspace, you need to explicitly do a git pull from the workspace folder.

If you are inside VSCode, you should be able to run > Create Integrated Terminal..., choose the folder containing your workspace, and launch the terminal. After launching, run a git pull inside of it.


Your workspace is made up of one or more vaults. A dendron vault stores a collection of related notes. If you're familiar with git, it's just like a code repo. By default, Dendron creates a vaults folder when you first initialize a workspace. All your notes are stored on a per vault basis.

ā””ā”€ā”€ workspace
    ā”œā”€ā”€ vault.main
    ā”‚   ā”œā”€ā”€
    ā”‚   ā”œā”€ā”€
    ā”‚   ā””ā”€ā”€
    ā””ā”€ā”€ vault.secret (hypothetical)

By default, when you look for notes in Dendron, it will search over all vaults.


Within a vault, your notes are stored hierarchically as . delimited markdown files.

Below is a hypothetical hierarchy for a file tree:

ā””ā”€ā”€ project1/
    ā”œā”€ā”€ project1/designs/
    ā”‚   ā””ā”€ā”€ project1/designs/promotion.png
    ā”œā”€ā”€ project1/paperwork/
    ā”‚   ā””ā”€ā”€ project1/paperwork/
    ā””ā”€ā”€ project1/tasks/
        ā”œā”€ā”€ project1/tasks/
        ā””ā”€ā”€ project1/tasks/

The same hierarchy in Dendron would look like the following:


You can read more about hierarchies here


A domain is the root of a hierarchy. In the example below, project1 would be the domain.



As you end up creating more notes, it can be hard to keep track of it all. This is why Dendron has schemas to help you manage your notes at scale. Think of schemas as an optional type system for your notes. They describe the hierarchy of your data and are themselves, represented as a hierarchy.

Schemas show up as icons next to lookup results.

You can create a schema by adding a YAML file with the following naming scheme {name}.schema.yml to your workspace.

Below is an example of a three-level hierarchy describing cli commands. You don't need to concern yourself with the details of the schema syntax just yet, just know that this schema will match the following glob patterns: cli.*, cli.*.cmd, cli.*.cmd.*, cli.*.env

- id: cli
  desc: command line interface reference
  parent: root
  namespace: true
    - cmd
    - env
- id: env
  desc: variables relevant for command
- id: cmd
  desc: subcommands 
  namespace: true


Stubs are notes that don't exist but that you might want to create. They will show up as suggestions in lookup results. There are two reasons why these suggested notes might show up:

  • they are the uncreated parent of a note deeper in the hierarchy (eg. might be a stub for
  • they are possible notes according to the schema

The + sign next to the suggestion indicates that the note is a stub and does not exist


Pods are the mechanisms Dendron uses to import and export notes. Dendron has a different pod depending on where you are getting and publishing your data to.

Command Palette

The command palette is native to vscode. You can use it to run dendron commands, which will all be prefixed with Dendron:. You can use the following shortcut to open the command palette.

Lookup Bar

The lookup bar is how you interact with notes inside of Dendron. Use it to create, find, and delete notes. You can type > Dendron: Lookup in the Command Palette or use the Ctrl+L shortcut.


Glob Pattern

Glob patterns are a way of pattern matching characters. You can test and see more example of glob patterns here.

Kebab Case

Kebab case is when you replace spaces with dashes and upper case with lower case.

  • Example
    • Hello World -> hello-world