On this page
The previous post argued why you want a second brain and gave you the one rule: every durable fact has exactly one home. This post builds the home. The substrate is deliberately boring — Git plus Markdown — and boring is the point. Boring outlives every hosted note app that will shut down in the next decade.
Your knowledge base should be plain text under version control. Plain text is readable by any tool forever; version control gives you history, blame, and a single authoritative copy. Everything fancier is a view built on top of this — never a replacement for it.
The commands below use example stand-ins from my lab — don’t paste them verbatim. Substitute your own values first: 10.0.0.76 → your vault host’s IP address; vaultwriter → the username you create; /wiki-data/git → wherever your repo lives; ~/wiki → your chosen local mount point; CT 106 is just my container’s label, yours will differ. Rule of thumb: if a value looks specific to one machine, it’s a placeholder to change — not a literal to copy.
Why this substrate wins
Three properties, and every other choice in this series depends on them:
- Durable: a Markdown file is legible in
cat, in your editor, in a browser, and in whatever tool exists in fifteen years. No proprietary database, no export dance. - Versioned:
git logon a note tells you what changed, when, and — if you write good commit messages — why. You can revert a bad edit and blame a line to a date. (If Git is new to you, the free Pro Git book is the authoritative reference.) - Single copy: the repository is the authority. Obsidian, a published wiki, and a search index are all downstream views of this one repo, never independent forks of the truth.
Where the vault lives
The authoritative repository lives on an always-on machine. In my lab that’s a Proxmox LXC container (call it CT 106) holding a bare Git repo at /wiki-data/git. My laptop never holds the only copy — it mounts the container’s repo over the network and edits the real files in place.
If the vault’s only home is your laptop, the vault is offline whenever the laptop is. Putting the authority on an always-on container means your cluster services, your phone, and later your AI agents can all reach the same single copy — and your laptop becomes just one editing client among several.
Folder taxonomy: PARA with stable URLs
Structure the vault so a page’s location reflects what it is, not what state it’s in. I use a lightly-adapted PARA layout:
wiki/
home.md # the map — links out to every hub
infrastructure.md # hub: hardware, network, storage
services.md # hub: deployed apps
projects.md # hub: finite outcomes in progress
runbooks/ # executable procedures
decisions/ # durable choices + rationale
reference/ # reusable domain knowledge
journal/ # dated evidence, session records
Do not organize by lifecycle. It is tempting to move a page from projects/ to archive/ when a project finishes — don’t. Moving a page changes its URL and breaks every link and bookmark pointing at it. A page’s folder should describe its kind, permanently; its status belongs in frontmatter. We devote a whole post to this later, but adopt the discipline from your first commit.
Frontmatter: structured metadata on every page
Every note opens with a YAML frontmatter block. This is what lets tools reason about your notes — filter by status, build indexes, and (later in this series) generate the graph.
---
title: "Proxmox Cluster"
description: "The 4-node cluster: hosts, quorum, and shared storage."
type: topic
status: active
tags: [infrastructure, proxmox, region/infrastructure]
topic: proxmox-cluster
relates: [storage-layout, cluster-networking]
created: 2026-06-17
updated: 2026-07-15
---
The fields that earn their keep: status (so lifecycle lives in metadata, not the path), topic (the canonical owner id for this subject), and relates (the links that later become the graph’s synapses). We build the generator that consumes topic and relates in a later post.
Editing the vault from your laptop
Here’s the exact pattern I use. The canonical repo lives on the container; the laptop mounts it over SSHFS so Obsidian edits the real files directly — no sync step, no second copy.
# Debian/Ubuntu/openSUSE
sudo zypper install sshfs # or: sudo apt-get install -y sshfs
# Key-based auth to the vault host (no password prompts on mount)
ssh-copy-id vaultwriter@10.0.0.76
mkdir -p ~/wiki
sshfs vaultwriter@10.0.0.76:/wiki-data/git ~/wiki \
-o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3
The reconnect and ServerAlive options keep the mount alive across brief network drops instead of leaving a dead handle.
Rather than a fragile fstab entry, mount lazily from your shell rc so it’s there whenever you open a terminal:
# Mount the canonical vault if it isn't already
if ! mountpoint -q "$HOME/wiki"; then
sshfs vaultwriter@10.0.0.76:/wiki-data/git "$HOME/wiki" \
-o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 2>/dev/null
fi
Open ~/wiki as an Obsidian vault. Obsidian now reads and writes the canonical files directly — graph view, backlinks, and daily notes all operate on the one true copy.
cd ~/wiki
$EDITOR home.md # write your map page
git add home.md
git commit -m "Add vault home page"
For the full copy-paste version with the interface-detection and teardown steps, use the paired playbook: Stand Up a Git + Markdown Vault.
The swap-in box
The principle is tool-agnostic — only the worked example above is mine:
Logseq / Dendron: both are Markdown-on-Git already — point them at the same mounted repo. Notion / Confluence: you can start there, but you don’t own the files; plan an export-to-Markdown escape hatch early. Plain Git, no editor: everything here works with git and $EDITOR alone — Obsidian is a convenience, not a requirement. No always-on host yet: a free-tier VPS or even a Raspberry Pi is enough to hold the canonical repo until you have a cluster.
What you have now
One authoritative, versioned, plain-text vault that you edit from your laptop as if it were local. That’s the substrate. Everything else in this series — the graph, the published wiki, the AI integration — is a view or a guard built on top of it.
The very next thing to get right, before the vault has anything valuable in it, is making sure you never commit a secret to it. That’s the next post.
Related posts:
- Your Homelab Needs a Second Brain — Here’s Why — the case for building this in the first place
- Never Commit a Secret to Your Knowledge Base — the next step: keep credentials out of the vault permanently
- Turn a Pile of Notes Into a Connected Brain — turn the flat vault into a connected graph
- Never Move a Note When a Project Ends — how the folder taxonomy stays stable over time
- Turn Your Git Vault Into a Searchable Wiki.js Site — turn this substrate into a published site
- Why Auto-Syncing Your Notes Repo Will Corrupt It — how to write to this authority safely
- How to Create an LXC Container on Proxmox — stand up the always-on host for the canonical repo
- Tailscale Subnet Router: Remote Access to Your Entire Homelab — reach the vault mount from anywhere
Comments
Comments are powered by GitHub Discussions — sign in with a GitHub account to join the conversation.