This post is merely a cheatsheet focused on XM Cloud DevOps and deployment, which I left for myself to have all the important Sitecore CLI commands in one place.
SitecoreAI gives teams three paths for managing deployments: the DeployApp web UI in the Cloud Portal, the Deploy API REST endpoints, and the Sitecore CLI with the SitecoreAI plugin. This post focuses exclusively on the CLI path. Whether you are wiring up a GitHub Actions workflow, an Azure DevOps pipeline, or scripting a repeatable release process, the commands below are your complete reference.
Content
Authentication
Before any CLI command can talk to Sitecore Cloud, you need an authenticated session. There are two modes.
Interactive login (developer workstations)
Opens a browser-based login flow, ideal for local development:
dotnet sitecore cloud login
Non-interactive login (CI/CD pipelines)
Pass client credentials directly with no browser prompt. This is the right option for automated pipeline steps:
dotnet sitecore cloud login --client-credentials --client-id <your-client-id> --client-secret <your-client-secret>
Permission requirement: The authenticating identity must hold the Organization Admin or Organization Owner role in the Sitecore Cloud Portal. Without it, project and environment creation commands will be rejected.
Project and Environment Hierarchy
SitecoreAI organizes resources in a three-level hierarchy: Project, Environment, and Deployment. Each level must exist before you can create the next.
Create a project
dotnet sitecore cloud project create -n <projectname>
The command returns the project-id you will need for the next step.
Create an environment
# Non-production environment
dotnet sitecore cloud environment create --name <environment-name> --project-id <project-id> --cm-only
# Production environment - add --prod for SLA coverage
dotnet sitecore cloud environment create --name <environment-name> --project-id <project-id> --cm-only --prod
Note on --cm-only: This flag signals a CM-only authoring environment topology. Deployment architecture options have evolved with the January 2026 decoupled model, so always verify the exact flag behaviour against the CLI plugin version in your project, as options may differ across releases.
Key Deployment Commands
Authoring environment (CM) deployment
This is the primary command to deploy your XM Cloud authoring environment. The --upload flag packages and uploads your repository directly from the CLI:
dotnet sitecore cloud deployment create --environment-id <environment-id> --upload
Editing host deployment
From January 2026 onward, the editing host is deployed as a separate unit. This command targets the editing host component independently:
dotnet sitecore cloud editinghost deploy --environment-id <environment-id> --upload
Repository size limit: The maximum repository size for --upload deployments is 500 MB. Plan your build pipeline to stay under this threshold, or use the Deploy API with a pre-built artifact URL for larger repositories.
Retrieving logs
There are two separate log surfaces worth knowing about: runtime environment logs and deployment-specific logs. Both are accessible via the CLI without touching the portal.
To list available log files for an environment:
Since the decoupled model produces independent logs per component, you will want to check environment logs for CM runtime issues and deployment logs for build or provisioning failures separately.list -id <environment-id> --latest
To print a runtime-specific log file directly to the console:
dotnet sitecore cloud environment log view -id <environment-id> --log <log-file-name>
You can also download a log file to a local path instead, which may be helpful for the cases oа implementing a "log drain" feature:
dotnet sitecore cloud environment log download -id <environment-id> --log <log-file-name> -o <output-path>
For deployment-specific logs (useful when diagnosing a failed or stuck deployment), use the deployment log command:
dotnet sitecore cloud deployment log -id <deployment-id> -o <output-path>
Note: Since the decoupled model produces independent logs per component, you will want to check environment logs for CM runtime issues and deployment logs for build or provisioning failures separately.
Decoupled Deployments Explained
The recommended deployment model since January 2026 separates the CM authoring environment from the Editing Host. Each component is deployed independently using its own CLI command:
- Authoring (CM):
cloud deployment create --upload
- Editing Host (EH):
cloud editinghost deploy --upload
The practical benefits of this approach:
- Faster release cycles - deploy the CM without rebuilding the EH, and vice versa
- Independent rollback - revert one layer without touching the other
- Granular observability - each component produces its own deployment logs, making root-cause analysis faster
- Pipeline flexibility - CI/CD stages can be parallelised or gated independently per component
Serialization and Publishing Workflow
Code deployment covers the application layer. Content serialization and Edge publishing are separate steps that run after the environment is live.
Step 1: Push serialized content to the CM
Sync your Sitecore Content Serialization items into the target environment:
dotnet sitecore serialization push -n <environmentName>
Step 2: Publish to Experience Edge
Once content is in the CM, publish it to Experience Edge so your head application can consume the updated data:
dotnet sitecore publish --pt Edge -n <environmentName>
Important Notes
- Repository size limit: 500 MB maximum for CLI uploads via
--upload.
- Auto-deploy option: DeployApp offers a "Trigger deployment on commit to branch" setting. For pure CLI pipelines, replicate this by calling
deployment create from a git webhook or pipeline trigger.
- Required role: Organization Admin or Organization Owner in the Sitecore Cloud Portal is required for creating projects and environments.
- Decoupled model: CM and EH deployed separately is the recommended approach since January 2026. Favour this for all new projects.
- Plugin version: Always run
dotnet sitecore --version to confirm your XM Cloud plugin is current. Flag behaviour such as --cm-only may differ across plugin releases.
Are you using CLI or DeployApp for your CI/CD pipeline? Share your setup in the comments below!