The Big Picture

  • You write posts in Obsidian.

  • The Blog Publisher plugin decides what can be published.

  • Publishing sends files to a Git repository.

  • Vercel notices the GitHub change and rebuilds the Astro site.

  • The live site serves the new result.

flowchart LR
  A["You in Obsidian"] --> B["Blog Publisher plugin (panel UI + checks)"]
  B --> C["Post processor (frontmatter, images, payload)"]
  C --> D["Git publisher (blobs -> tree -> commit -> ref update)"]
  D --> E["Git repository"]
  E --> F["Hosting deploy hook"]
  F --> G["Astro static build"]
  G --> H["Live site"]
  B --> I["Theme publish path"] --> E
  B --> J["Unpublish path"] --> E

What Lives Where

  • Writing and editing: your notes vault
  • Plugin source code: plugin project repo
  • Installed plugin output: your local Obsidian plugins folder
  • Website source repo: site project repo
  • Remote deploy target: Git hosting + auto-deploy

What the Plugin Actually Does

When you open a blog post, the side panel:

  • Reads frontmatter (title, date, status, slug, tags, etc.)

  • Shows a publish state (Draft or Published)

  • Runs checks (frontmatter, slug, links, images, build readiness)

  • Lets you publish, unpublish, and update theme

On publish, it:

  • Builds markdown + image payload

  • Pushes post and image files to the GitHub repo

  • Writes publish metadata back to frontmatter (publishedAt, publishedCommit, publishedHash)

On unpublish, it:

  • Deletes post and related image files from the GitHub repo

  • Removes publish metadata fields from frontmatter

Why This Design

This setup keeps authoring simple and deployment reliable:

  • Obsidian is the editor of truth for drafts

  • GitHub is the source of truth for what gets deployed

  • Vercel is the automated builder/host

  • The plugin is the bridge between writing and shipping

Mental Model (Short Version)

  • Obsidian = workshop

  • Plugin = shipping desk

  • GitHub = warehouse ledger

  • Vercel = printing press

  • Live site = storefront