The Cloud Portal Operations Handbook: Environments, Builds, Backups, and Self-Service

The SAP Commerce Cloud Portal is the cockpit for a CCv2 subscription: builds, deployments, environment management, endpoints, backups, and monitoring all run from it, and an ops team's fluency with it is the difference between a subscription that runs smoothly and one that surprises everyone at the worst moment. The first-deployment guide covers getting your first build out the door; this handbook is the standing operations reference: what the environments are and how they are sized, how the build pipeline actually behaves, the storage and database rules that shape what you can safely do, and the backup discipline that decides whether a bad deployment is a rollback or a disaster.

The Three Environments#

A subscription provisions three environment types (extra instances purchasable), each a fixed-footprint Kubernetes cluster plus an Azure SQL database, sized by role:

• Development: the smallest tier, for integration and developer-shared testing. Modest cluster, a standard database. Not production-shaped, so performance numbers here mean little (the hAC benchmark caveat from the power-user guide).
• Stage: production-like, the environment where you prove deployments and run load tests. Larger cluster, a higher database tier. This is the environment the go-live guide insists must be production-equivalent for a deployment rehearsal to mean anything.
• Production: the largest footprint, with a premium database tier offering better reliability and asynchronous replication to another data center for disaster recovery.

Two facts govern everything you do with them. First, all cluster resources (CPU/RAM per node per aspect) are fixed and managed exclusively by SAP, which is why only horizontal scaling (more nodes) is supported and vertical scaling (bigger nodes) is not, the clustering guide's design-for-horizontal rule stated as an operational constraint. Second, exact node sizes evolve as SAP tunes the platform, so treat specific VM sizes as current-documentation facts rather than architecture you depend on.

The Build Pipeline#

Builds are manifest-driven and deliberately constrained, and understanding the constraints prevents the classic on-premise-habit failures:

• The build uses the standard commerce build process, configured by manifest.json, and nothing else. Alternative or custom recipes from on-premise do not apply; teams migrating recipes must express them as manifest configuration.
• Build customization is limited to what the manifest and standard build support. Build callbacks and other customizations carry real incompatibility risk, and the guidance is blunt: keep build customization minimal and test it thoroughly, because a larger customization surface means a larger chance the CCv2 build rejects it. This is a recurring migration surprise, so audit build callbacks early.
• The build produces Docker images from your designated code plus required extensions, deployed to the cluster per the manifest's aspect configuration (the clustering guide's aspect model). One base image, different aspects, individual scaling per node group.
• Build failures live in the build log in the portal's build details, which is your first stop when a build goes red. Configuration reuse in the manifest is worth setting up because it also simplifies local development (the local dev guide).

The operational loop is: commit to the tracked branch, trigger a build (manually in the portal or via the Commerce Cloud APIs from your CI, per the continuous delivery guide), watch the build log, then deploy the successful build to a target environment with a chosen deployment mode.

The Ephemeral Storage Rule#

The single most important infrastructure fact for anyone writing code on CCv2: application server disks are ephemeral. Kubernetes replaces nodes routinely, and anything written to local disk vanishes when it does. Consequences that break naive code:

• Never rely on local files persisting. A job that writes a file expecting to read it back later, a cache on disk, an upload landing on the node: all wrong on CCv2. Files that must outlive a node go to cloud storage.
• Cloud Hot Folders replace the SFTP drop (the cloud hot folders guide): file-based integration rides Azure Blob Storage, not a local directory, precisely because there is no durable local directory.
• Media and generated assets live in the platform's media storage (cloud-backed), not on the node.
• Logs stream to the centralized logging (the logging guide) because a node's local log dies with the node.

Auditing existing code for disk-persistence assumptions is a mandatory migration step; it is the on-premise habit that fails silently until a node recycle deletes something someone needed.

Database: Backup, Restore, and Disaster Recovery#

The database is Azure SQL, and two distinct safety mechanisms exist that teams routinely confuse:

• Data Backup and Restore (self-service, in the portal): you save the database state and can restore it later. This is your rollback tool. The discipline: back up before any large deployment that changes the data model, because a type-system change plus a day's orders is exactly the situation the go-live guide warns cannot be cleanly reversed except by fix-forward or a restore-with-a-cost. Periodic backups plus a pre-deployment backup are the baseline.
• Disaster Recovery (in your subscription, the premium production tier's async replication): this covers infrastructure failure, the main data center becoming unavailable. It is not a rollback mechanism. DR will not undo a bad deployment; it exists so a data-center outage does not end your business.

The rule to internalize: DR is for their failures, backup/restore is for yours. Confusing them (assuming DR will save you from a botched deployment) is a nasty surprise mid-incident. And restores take real time, so a restore-based rollback is a decision with a cost that must be rehearsed once (the go-live guide's rollback drill), not attempted for the first time under fire.

Also: SAP Commerce Cloud standardizes on Azure SQL, so any direct SQL your project writes must be reviewed for compatibility, and the persistence guide's rule stands doubly here (do not manipulate data with raw SQL; use platform tools so the cache layer stays coherent).

Web Tier and Endpoints from the Portal#

The portal is where you configure the web-tier surfaces the web architecture guide details: endpoints (virtual hosts mapping domains to applications), IP filter sets, SSL certificates, redirects, and maintenance pages. Operationally these are living configuration: certificate renewals (self-service, minutes, and monitor expiry), filter-set reviews at every partner change, and maintenance-page readiness before any window. Treat the endpoint and certificate state as documented configuration in your runbook, exported from the portal, not portal folklore.

Self-Service Operations, Day to Day#

The operations an ops team runs from the portal without a support ticket:

• Deploy a build to an environment, choosing the deployment mode (rolling for zero-downtime code-only changes, the ceremony modes for data-model changes; the go-live guide's rolling-versus-full distinction).
• Trigger deployments and builds via the portal or the management APIs for pipeline automation.
• Back up the database before risky changes; restore when rolling back.
• Manage endpoints, certificates, IP filters, redirects, maintenance pages.
• Read build and deploy logs, monitor environment health and the platform metrics surfaced in the portal (complemented by Dynatrace and the logging stack, per the observability guide).
• Manage user access to the portal itself with appropriate roles, so who can deploy to production is a governed, least-privilege decision (the security hardening guide's ethic applied to the operations plane).

The Operations Checklist#

• Team fluent in the three environments' roles; stage kept production-equivalent for rehearsals
• Build customization (callbacks, manifest) minimized and tested; build-log triage is a known routine
• Code audited for ephemeral-storage assumptions; files/media/logs go to cloud storage, not local disk
• Pre-deployment database backups mandatory before data-model changes; backup/restore-as-rollback rehearsed once
• Disaster Recovery understood as infrastructure-failure cover, not rollback; the distinction documented
• Direct SQL reviewed for Azure SQL compatibility and cache coherence
• Endpoints, certificates, and filter sets exported to the runbook; certificate expiry monitored
• Portal access governed by least-privilege roles; production deploy rights restricted and logged

The Cloud Portal rewards the same operational maturity every platform does: know your environments, respect the fixed footprint, never trust the local disk, back up before you break things, and keep who-can-do-what deliberate. SAP runs the infrastructure so your team can run the operations, and this handbook is the shape of that job.