Content Operations
Your code moves from dev to test to production through a pipeline. Content Operations gives your content the same path: pull it, check it, sync it to another instance and prove it arrived, from your terminal or your CI.

The Agility CLI
Your code has a pipeline. Why doesn't your content?
If you run more than one Agility instance, one per environment, brand or region, you know the routine: build the model in dev, rebuild it by hand in test, do it again in production, and hope nobody missed a field. DevOps solved this for code a decade ago. The Agility CLI solves it for content, and moves models, components, content, pages and assets between instances in one run.
How it works
Four steps, and two of them are checks
Pull takes a snapshot of an instance to disk. Preflight writes nothing: it reports every create, update and skip a sync would make, and lists any item missing a required field, so you see the problems before anything is written. Sync copies what you chose into the target, with everything it depends on, scoped to a few models, one page, one container or one locale if you like. Verify compares the target with the source, field by field, and lists every difference. Two of the four steps change nothing, because a sync you can't check before and after isn't one you'll run on production.
What you get
Everything you'd otherwise do by hand
Each command works on its own, and together they're a pipeline you can run from a laptop or a CI job.
Pull
Snapshot an instance to disk, for a backup, a diff or the start of a sync.
Sync with dependencies
Copy a model and everything that uses it, one page and its children, or one container, and nothing else.
Preflight
See every create, update and skip a sync would make, and any item missing a required field, before it writes anything.
Verify
Compare the target with the source and get a report of every difference, separate from the sync's own logs.
Reverse sync
Send edits made in the target back to the source, using the mappings from the original sync.
Workflows in bulk
Publish, unpublish, approve or decline synced content and pages in one command.
Built for CI
A JSON summary and exit codes your pipeline can read, and a headless mode that logs to a file.
Personal Access Tokens
Sign in from scripts and CI without a browser. Each token is tied to the person who made it, and stops working when their access is removed.
Nothing gets deleted
A sync adds and updates. Anything that exists only in the target stays where it is.
Who it's for
Most teams run one instance per project, often with a sandbox on the side, and that's all they need. It's still good to know this is here, and it's built for the teams who run more.
- 01
Working with a sandbox
Build a model or a page in your sandbox and move it into your main instance, or bring production content back into the sandbox to test against.
- 02
A new project from a template
Use a previous instance as the template for a new project, with its models, Components and pages already in place. Agencies do this for every new client.
- 03
Lower environments, brands and regions
The model change that ships with your code reaches dev, QA, UAT and production with it, and one change rolls out to every brand and region in a single run.
- 04
Developers and DevOps engineers
Content changes scripted, reviewed in a pull request and run from CI, with a JSON summary and a pass or fail at the end.
- 05
The CLI or the MCP server?
The MCP server can move content between instances too, and it's great for a one-off move. The CLI keeps a mapping log with versions and conflict detection, so it's the right tool for syncs you run again and again.
- 06
What you need
Two Agility instances, an Org Admin, Instance Admin or Manager role on both, Node.js, and a developer. For CI, a Personal Access Token: the Personal Access Tokens guide walks through creating one.
Questions about Content Operations
What teams usually ask before their first sync.
Is there a button for Content Operations in the Content Manager?
Not yet. Today Content Operations runs from the Agility CLI, in a terminal or a CI job, on top of the Management API. Copying pages and items between instances from the Content Manager is on our roadmap.
What does an Agility CLI sync copy?
Models, components, content, pages, page templates, assets, galleries and URL redirections, per locale. You can sync all of it or scope it to a few models, pages, containers or locales.
Will a sync overwrite changes someone made in the target instance?
Not by default. If a target item has its own changes, the CLI skips it and reports a conflict. Pass --overwrite when you want the source version to win. Sync never deletes anything in the target.
How do I run the Agility CLI in CI without a browser login?
Create a Personal Access Token and pass it with --token or the AGILITY_TOKEN environment variable. A token lasts up to two years, and the CI/CD guide in the docs has a working pipeline to start from. Each token belongs to the person who created it, and stops working when that person's access is removed.
Can edits flow back from the target instance to the source?
Yes. The reverse-sync command sends changes made in the target back to the source, using the mappings from the original sync, so synced items are updated rather than duplicated. Run it with --preflight first.
Tell us how your instances are set up
Dev, test and production, or one instance per brand or region: show us how you work today and we'll map out the content pipeline for it.