One Obsidian Vault for Multiple Web Project CMSs: Live Preview, a Single Source of Truth, and Clear Git Boundaries

When you maintain two, three, or more websites, writing is rarely the part that becomes unmanageable. The trouble gathers around it: every project has its own editing entry point, asset folders, preview process, AI setup, and Git routine. Copying content between those places can feel efficient for a week, then leave you wondering which version is actually current.

I now use a local-first setup instead. Each website keeps its own repository, content, assets, build, and deployment. One Obsidian Vault becomes the shared content workspace. It does not replace the website or take over Git; it simply makes editing, browsing, and review more pleasant.

To make the “see the real page from Obsidian” step repeatable, I also open-sourced CMS Live Preview. It is a desktop-only, local-first Obsidian plugin that maps supported content files to their local website routes, checks the preview server, and can start or stop a configured development server only after you explicitly ask it to. This is an early release with a deliberately narrow and documented scope, which is exactly how I want the tool to remain.

A Vault Should Be a Workspace, Not a Second Content Repository

The important move is not to pull every project into one directory. It is to give each part of the workflow a clear responsibility.

Location	What it should own
Obsidian Vault	Browsing, editing, search, and editorial review
Each project’s Git repository	The real MDX files, assets, code, and history
The project’s local development server	The real route, components, styling, and SEO output
Each project’s Git, CI, and deployment flow	Testing, commits, releases, and rollback

Viewed this way, Obsidian is not another CMS database. It is a more comfortable doorway into the CMS you already have. The source of truth remains inside the original project.

Connect Projects with Symbolic Links, Not Copies

Imagine two websites that already live in separate Git repositories. They have different content folders, asset folders, and build commands. Do not copy them into the Vault. Link only the directories you actually need to edit.

Content-CMS/
├── Project-A  → Project A content directory
├── Project-B  → Project B content directory
└── assets/
    ├── project-a → Project A asset directory
    └── project-b → Project B asset directory

A symbolic link looks and opens like a folder, but it does not store a second copy of its target. It tells the system to read the files from their real location.

That means an edit to Project-A/en/example.mdx in Obsidian—whether you change the title, rewrite a paragraph, or insert an image—lands directly in Project A’s Git repository. There is no export step, no write-back step, and no shadow copy waiting to drift.

That is what “one entry point, one source of truth” means in practice.

Why Content Should Not Be Copied into Obsidian

Several familiar approaches can work at first, but their long-term costs differ sharply.

Approach	Are articles copied?	Can versions drift?	Does Git see the change directly?	Long-term cost
One Vault per project	No	No	Yes	More context switching
Copy content into a knowledge base	Yes	Yes	No	Constant version checking
Export or synchronization tool	Usually	Depends on the rules	Not directly	Rules to maintain
One Vault + symbolic links	No	No	Yes	The lightest option

The real cost of copying is not a little extra disk space. It turns “write a good article” into “manage the relationship between several articles.” Instead of judging the content, you first have to decide which version is real.

That leads to a useful, slightly counterintuitive rule:

In multi-project content operations, the best synchronization is often no synchronization at all.

Preview Through the Real Website, Not an Obsidian Simulation

Seeing an MDX file inside Obsidian is not the same as seeing the page your reader will receive. The final page includes the project’s components, styles, image handling, routes, locale rules, and SEO structure. Asking Obsidian to simulate all of that would turn a lightweight editor into an incomplete website runtime.

A more reliable review loop looks like this:

Edit the current MDX in Obsidian
        ↓
Identify the project and article slug
        ↓
Open that project's running local preview route
        ↓
Review the real page in an Obsidian tab or system browser

The open-source CMS Live Preview fits between those steps. The current release maps articles from the supported Glowise and Bible Note content folders to their routes, checks server health, and keeps Start, Stop, Refresh, Open, and server logs in one preview interface. It runs a configured local command only after you choose Start, and it can fall back to the system browser when a page cannot be embedded.

That boundary matters: the plugin gets you to the real preview; it does not take over how a project runs. Its repository is the source of truth for the supported layouts, installation, and configuration requirements.

Use AI in the Vault, but Do Not Load Everything into It

If you use Codex, Claude, or another agent in your Vault, it is tempting to load every available skill. In practice, the agent can spend its limited context on irrelevant instructions before it has even started on the article.

I prefer a small allowlist of capabilities that genuinely support content work:

Obsidian Markdown
Obsidian CLI
Web search and reading
PDF reading
Blog Writer

There is no need to copy a separate Skill bundle into every Vault either. Reference the same source files instead: update a rule once and the next session uses it; unrelated capabilities do not consume context.

Unified Editing Does Not Mean Unified Git

Three boundaries are still essential.

First, do not mount an entire repository in the Vault. In most cases, you need only the content directories and the necessary asset directories. node_modules, build outputs, and caches add noise rather than value.

Second, Git still belongs to the original project. Even if one Vault lets you edit content for several sites, testing, commits, previews, deployments, and rollbacks must stay in each repository’s own workflow.

Third, if Obsidian does not show a newly mounted directory immediately, refresh its index or reopen the Vault. The data is usually not missing; the file watcher has simply not caught up. Keep the Vault’s own .obsidian configuration out of project history when appropriate.

Closing

One Vault does not turn several projects into one project. It gives the editorial layer a unified and comfortable interface without hiding the fact that every site still has its own code, runtime, and deployment boundary.

Let projects remain projects. Let Git manage versions. Let each website render the real page. Let Obsidian focus on what it does best: providing an always-ready, searchable, review-friendly place to work with content. If you manage a code-backed CMS too, CMS Live Preview is a practical starting point for this workflow.