Update and version history
To update an existing document, use the post ID:
opendocs update revised-doc.md --post-id abc123
How to find the post ID
Use:
opendocs list --json
or:
opendocs get abc123
What update changes
The current CLI update flow can change:
- raw Markdown content
- title
- visibility, when
--visibilityis passed - tags, when
--tagsis passed
It keeps the same canonical URL, so existing readers do not need a new link.
If --visibility or --tags are omitted, the existing visibility and tags are
left unchanged.
Like opendocs publish, update uploads supported local images referenced from
the Markdown file before sending the new version. Local image files must live
inside the same directory as the Markdown file, and the same 10 MB per-image
cap applies.
Update flags
| Flag | Meaning |
|---|---|
--post-id <postId> | Required. The post to update |
--title <title> | Override the title |
--visibility <visibility> | private, workspace, or public; omit to preserve current visibility |
--tags <tags> | Comma-separated tags; omit to preserve current tags |
--confirm-public | Required when moving to public |
--json | Global flag for machine-readable output |
Example
opendocs update release-plan.md \
--post-id abc123 \
--visibility workspace \
--tags roadmap,release \
--json
Example response:
{
"postId": "abc123",
"versionId": "ver_456",
"versionNumber": 4,
"slug": "release-plan",
"title": "Release plan",
"visibility": "workspace"
}
Version history
Each successful update creates a new server-side version number.
That means:
- the URL remains stable
- the current reader view points to the latest version
- historical versions are preserved internally
The public CLI today is focused on update and pull workflows rather than a full rollback command, so version history is primarily something OpenDocs stores and tracks for you.
Recommended workflow
- Find the post with
opendocs list --json - Pull the current content if needed:
opendocs pull abc123 --stdout
- Edit locally
- Run
opendocs update ... --post-id abc123