Skip to main content
Use primo publish to make a hosted site’s saved changes public. Use primo push --publish to upload local files first, then publish them.

Before you start

You need:
  • primo-cli 0.2.1 or later, on a supported Node.js version.
  • A deployed Primo server that supports the CLI publication API. CLI version alone does not add this support to an older server; update the CMS if publication status is unavailable.
  • An account with permission to edit and publish the site.
  • A connected hostname to view the published result.
Log in to the server you want to publish to:
The CLI reuses credentials saved for that server. For scripts, --token supplies an explicit token; the CLI does not automatically read a PRIMO_TOKEN environment variable.
Publishing includes the whole site’s saved draft, including changes on other pages. Save open CMS dialogs and review collaborators’ changes before publishing.
When CLI publishing uses the primo-mcp 0.1.10 compiler, it drops inline formatting, links, and code-block formatting from rich text stored as TipTap JSON. This affects primo publish and primo push --publish. Until your compiler includes a fix, use browser publishing for sites with formatted rich text. The separate primo build command in CLI 0.2.1 preserves this formatting.

Publish saved CMS changes

Run these commands from your workspace root. Replace my-site with the folder name under sites/:
1

Check the hosted draft

This reads the hosted publication state without uploading files. The CLI uses the server configured in your workspace; pass --server https://cms.example.com to select it explicitly.
2

Publish the site

The CLI builds the saved hosted draft and activates the result. It does not upload your local files. You do not need to pull CMS edits before publishing them.
3

Verify the result

Expect current when the saved draft matches the successful publication. Open the site’s public hostname and check your changed page, navigation, images, and interactions.
To select a site folder directly from the workspace root, use --dir:
From inside the site folder itself, run primo publish without --only or --dir. Without a local checkout, select the server and site ID explicitly:
Find the site ID in the site’s site.yaml after a pull, or use a known site ID from your CMS.
From a workspace root, primo publish without --only selects every site in that workspace. Use --only my-site when you intend to publish one site.

Upload and publish local changes

After editing local files, run from your workspace root:
Push safety still applies. A refused push does not publish anything. If a push succeeds but publication fails, the uploaded draft remains saved in the CMS; fix the reported problem and retry with primo publish --only my-site. If someone edits the hosted draft between your upload and publication, the CLI stops instead of publishing a different revision. Review the new changes before retrying.

Options

primo publish [server] accepts: primo status --hosted accepts the same target, directory, token, and JSON options. --server also enables hosted status. To combine upload and publication, use the push options with --publish. For an automated check:
Publication failures and uncertain results return a nonzero exit status. Check the result before starting any follow-up deployment steps.

Understand publication status

Troubleshooting

Publication status is unavailable, or the endpoint returns 404: Update the CMS to a release that supports the publication API and verify the server URL and site ID. Until then, use Publish in the browser editor. Permission denied: Run primo login again if your saved session expired. Confirm that your account can edit and publish this site. The draft changed: Review the latest hosted changes. If you also have local edits, save them before pulling, then follow push recovery. Do not force an overwrite just to publish. A build fails: Fix the block, page, or asset reported in the error. Successfully uploaded files remain in the hosted draft; retry with primo publish after the fix. The connection drops or the result is unknown: Run primo status --hosted for the same site and inspect the public result before retrying. A lost response does not prove publication failed. The build succeeds but no public URL is assigned: Connect a hostname in the dashboard, then verify the public site there.