Skip to main content
primo push and primo pull move content and code between your local workspace and an already-deployed Primo server. Use them to keep production in sync with Git, or to grab a copy of a remote site for local development.

Authenticate First

Before pushing or pulling against a hosted server, log in:
The CLI stores credentials per server and reuses them on subsequent commands.

primo pull — Hosted → Local

Pull an entire server (every site plus the shared library) into local files:
Options:
  • -o, --output <dir> — Output directory (defaults to ./<server-hostname>)
  • -t, --token <token> — Auth token (overrides stored credentials)
The result is a complete workspace ready for primo dev. Image files in uploads/ are pulled as real binaries — the directory is self-contained.

primo push — Local → Hosted

Push local changes to a hosted server:
Options:
  • -s, --server <url> — Server URL
  • --site <id> — Push to a specific site ID
  • --only <slug> — Only push the named folder under sites/ (skips library/)
  • -d, --dir <dir> — Workspace directory (default: .)
  • -t, --token <token> — Auth token
  • --preview — Preview-only push (doesn’t publish)
  • --dry-run — Show planned operations without sending requests
Always run primo push --dry-run first when pushing to production. It surfaces import warnings (orphaned uploads, unresolved block references) before they hit the server.

Library-Only Sync

To move just the shared block library between workspaces and servers:
This is useful when curating a block library independently of any particular site.

What Gets Synced

site.yaml metadata (name, group) round-trips. host is treated as per-environment routing config and is never overwritten by file sync.

Common Workflows

Edit in production, snapshot to Git

Edit locally, push to production

Move a site between servers

Next Steps

Deploy

Deploy a workspace as an editable CMS or static site

Local Development

Run the local CMS with file/CMS sync