Markdown Publishing: Drafts, Snapshots, and Web Updates

## Release notes

The search shortcut is **Ctrl + K**.

What is a published snapshot?

A snapshot is a copy of the document’s title and content at a particular time. The workspace holds the editable source. The public page reads the published copy. They can contain different text until you publish an update.

Suppose your source file is release-notes.md:

# Release notes

The search shortcut is **Ctrl + K**.

After the first publish, the public page shows that heading and sentence. If you add two bullet points in the editor, the workspace has the new text but the public page still has the original sentence. Saving or syncing the source is not the same operation as updating the publication.

This behavior is useful for handbooks, short tutorials, release notes, and project briefs. For a larger site with navigation, templates, and its own build pipeline, an HTML export or a separate site generator may fit better. The Markdown to HTML guide explains that alternative.

Publish the first version

Start with a document in your signed-in workspace. You need write access, and the workspace owner’s plan must include publishing. A viewer can inspect publishing status but cannot publish changes. Current plan details are on the pricing section.

Review the document in the editor, then open its Publish dialog and choose Publish. The dialog returns a public URL. Open that URL to check what a reader will actually see before you send it to someone else.

The title is taken from the document’s first Markdown H1 when one is present; otherwise it comes from the filename. Give the document a meaningful heading before the first publication. Readers should be able to tell what the page is about without seeing the surrounding workspace.

Publishing creates a readable page for one document. It does not grant access to the rest of your workspace. It also does not turn a local image path into an uploaded image. Check external images and links in the public page, especially when your draft came from a folder on your computer.

Edit the draft without changing the public page

Continue writing in the same file after publishing. For example, expand the release note:

# Release notes

The search shortcut is **Ctrl + K**.

- Search by file name
- Open a result with Enter

At this point, a reader opening the existing public URL still sees the shorter version. You can review the new wording, check the shortcut, or remove a bullet without changing the published copy.

Keep the draft in the same file. Creating release-notes-v2.md creates a different source document, which is unnecessary when your goal is to update an existing publication. Workspaces help keep the source next to the related notes you need for the revision.

Update the page at the same URL

When the draft is ready, open the Publish dialog again and choose Update. EDTR.md copies the current title and content into the existing publication. The public URL remains the same, including when you have changed the document heading.

You can use this sequence as a simple check:

Action	Workspace source	Public page
Publish	Original text	Original text
Edit and save	Revised text	Original text
Update	Revised text	Revised text
Unpublish	Revised text	Unavailable

After updating, reopen or refresh the public page and inspect the actual result. Check the changed paragraph as well as nearby code, tables, and links. A successful publish action confirms that a snapshot was stored; editorial review is still your job.

For a technical guide, run the commands or requests you are documenting before updating the page. Rendering a code block correctly does not establish that the code works. The technical documentation workflow shows a structure for requests, fields, and warnings.

Unpublish while keeping the source file

Choose Unpublish when the page should no longer be available. This removes the publication. It does not delete the source document from your workspace, so you can keep working on it privately.

There is a difference between updating and starting a new publication. Updating preserves the existing URL. Unpublishing removes the record behind that URL. If you publish the file again later, it receives a new publication URL; do not promise readers that the old link will resume working.

Taking a page down also cannot remove a copy someone already downloaded, cached, or captured in a screenshot. Treat publishing as making the current content public, rather than as a temporary private review mechanism.

Check access, images, and private details

Before sharing the link, read the page as someone outside your workspace. A useful review is specific:

• Does the title identify the document without relying on its folder name?
• Are image URLs reachable by the intended reader?
• Do example commands contain placeholders instead of real credentials?
• Are references pointing to public resources rather than private account pages?
• Does the first paragraph explain what the reader can do with the document?

Publishing access follows the workspace owner’s plan. If that plan no longer includes publishing, an existing page remains live until it is unpublished, but updating it requires an eligible plan. Check the dialog’s current status instead of assuming that a billing change took the page down.

A small writing and publishing routine

For recurring documents, keep one source file per subject. Write and preview it, check the facts, publish or update, then verify the public link. Use a separate file when the subject genuinely changes, such as a new month’s release notes, rather than for every revision of the same note.

The Markdown for blogging guide covers headings, frontmatter, images, and links if you are still shaping the draft. Once the content is ready, open EDTR.md and try the publishing sequence with a short document you are comfortable making public.