Nested vaults - usage and risks

The developers strongly advise against any use of nested vaults, warning that the program is not designed to cope with them and things may break.

(Nested vaults are vaults located within another vault. As with any folders, It is possible to have many layers of vaults.)

They do however, have some uses:

  • They allow the same vault to be open in more than one window.
  • They allow sub-folders (aka nested vaults) to use a different CSS to other vaults, and to have its own saved workspace etc.
  • They make it easier to focus on the material in the nested vault without being distracted by other files and folders.
  • They are very useful for projects where most of the sources and writing is project specific.

To a vault at the top of the hierarchy, the vaults nested within simply look like folders, and all normal Obsidian functions are possible.
The nested vaults beneath cannot see, or be aware of, vaults above or to the side of it in the folder hierarchy.

My preferences, based on observations thus far, are:

  1. Avoid nesting a vault unless the gain from having one is clear.
  2. Editing and linking at the top level should be safe for everything.
  3. Unique file names are essential - but clashes may not be pointed out in a lower level vault - so have another way of checking uniqueness if creating new files in a nested vault.
  4. Using links in a lower level vault is likely to lose data except when the links used are all within the vault. If you try to use a link to a file in another vault, it cannot be found and can trigger the creation of a new file of the same name within the vault. Therefore only use and make links with files in the vault.
  5. Conversely, it is best for each vault to have its own attachment folder. This keeps everything relevant in one place, making it easier to manage from the OS file system and works perfectly well from higher level vaults.
  6. There is no risk when a nested vault is used only in preview mode; this can be useful when you want to read in one window and write in another.
  7. Have a robust backup routine.
  8. Have programs that can compare files in folders and identify changes - if there’s a problem, version control ala Dropbox etc may not be sufficient to recover the situation.
  9. They work best where the material in the nested vault has little interaction with other vaults. Little but not none - if it were none there would be no reason for it not to be a completely separate folder. And a lot of interaction means it would be better to have access to them all.

I don’t use markdown links and I use shortest path (usually) - I can see that either of those might make a difference.

I would be keen on corrections, additions and observations. This is a topic rarely discussed, presumably to avoid encouraging users to do something inherently unsafe. Equally, I’m aware that a number of people use the technique, so establishing safe boundaries and known risks may be useful.


Interesting, I was thinking about the opportunity to use a nested vault for the publish thing, so I check the graph on the nested vault and see only the links pertaining to the published material and at the same time to link some content in the nested public vault from my private top level vault that I would use for organizing my work.What do you think, it is something than can work?

1 Like

Depends on whether I understand you properly.

Boundaries around each vault are impenetrable.
So the nested vault can’t link to anything in your top level vault.
When you are in your top level vault, the nested vault is only a folder so you can link all you want.

I don’t have Publish, so can’t test, but if I understand you right it should work.

1 Like

Yes it’s exactly what I was trying to say, but my bad English doesn’t help. From what you said it seems that could work and could be also a perfect solution for my use case. Thanks a lot for giving me some inspiration!

1 Like

Pefect, thank you for putting this together @Dor I’ve been doing this, but wasn’t aware of some of the cautions to take.

backing things up with git version control is perhaps the most important thing to do, specially when testing this kind of stuff.

to point out what @madz00 said

In future versions of obsidian will this nested vault approach become a more frequent practice?

when I got obsidian publish, I found the nested vault the only clean approach to only publish one sub-folder of notes. I can imagine this becoming the best practice for obsidian publish, unless there’s something I’m missing

What do current users of obsidian publish think about this?

1 Like

I’d like it if it was, but so far Licat has advised against doing it. I assume there’s ways of protecting against some or all of the risks, but I don’t know.

The firm barrier around each vault brings advantages as well as disadvantages.


got you, I’ll keep an eye for any news on this, I suspect things will change, specially as obsidian publish grows.

thanks again for the help

oh god thank you so much for listing all of this out. playing with fire


Quick update which I’ll add to first post.

They are very helpful for projects.
For instance, academic research or papers with a mix of broader (intro, discussion) and deeper (experiments). All the deeper is most effectively done within the project vault and the broader can be added and linked from a higher level vault. Once the project is completed, the project vault just becomes a sub-folder unless it is ever needed again.

Have an attachment folder for each vault. This keeps all vault specific attachments in a sub-folder which makes it easier to access and manage from the OS file system should that ever be needed. All the attachments and links are accessible from both the nested vault and higher level vaults.

I also noted the reference with the new block links that using ^^ might be slow in massive vaults. Nested vaults would be one way of managing this where only a smaller and specific group of files needed to be searched for potential linking.