Docs/Publishing/Publish a folder or vault

Publish a folder or vault

Publishing serves part of your vault — a single note, a folder, or the whole vault — as a read-only web page, hosted by Solomon (app.lomon.dev). The files stay in your vault; publishing is a projection, not a copy you have to keep in sync by hand.

Requirements

Cloud sync must be on for the vault. Publishing reads from the synced copy server-side, so a local-only vault has nothing to publish from.
You must be the vault owner. Editors and viewers can't manage publishing — ask the owner, or have them transfer ownership.
The org must be entitled to publish. Entitlement resolves in this order: an explicit org allowlist (SOLOMON_PUBLISH_ALLOWLIST, an ops escape hatch) → the global SOLOMON_PUBLISH_ENABLED flag → a paid (Pro or Team, active) Stripe plan. If none of those hold, publishing is off for that org — fails closed.

In the desktop app this all lives in the vault's Publish panel (Settings).

Scope: what you're publishing

Pick one of three scopes when you set up a publish config:

Scope	What's exposed
`vault`	Every note in the vault (minus `_private/`).
`folder`	Every note whose path is under a folder you choose.
`file`	One specific note.

So publishing a subdirectory — not just an entire vault — is a first-class option: pick folder scope and give it the folder's vault-relative path (e.g. Docs/). _private/ is refused as a publish target outright, and _private/ notes are excluded even under a vault-scope publish.

Each vault can have multiple publish configs at once (different scopes, different slugs) — e.g. a public Docs/ folder alongside a restricted Projects/Client X/ folder.

Audience: who can read it

Audience	Who can read
`public`	Anyone with the link — no credential needed.
`people`	Specific people you grant, by account.
`agents`	Agent tokens you grant (per-vault agent credentials).
`people_agents`	Both of the above.

Non-public audiences need explicit read grants — see [[Reader keys and audiences]] for how a restricted publication is actually unlocked, and why every failure mode (wrong slug, no credential, ungranted credential) comes back as a plain 404.

Where it's served

A publish config gets a unique, globally-namespaced slug ([a-z0-9-]{1,60}). The human-readable page renders at https://app.lomon.dev/p/<slug> (and any nested notes under /p/<slug>/<path>); the same content is available as JSON from the versioned read API at /api/v1/pub/<slug>/... — see [[The published API and SDKs]].

Management is a small REST surface at /api/vault/{vaultId}/publish: GET lists your configs + grants, PUT upserts one (keyed by scope + target path), DELETE removes one. An owner can always unpublish (the DELETE isn't itself gated by the entitlement check), even if publishing later gets disabled for the org.

What's gated vs. live