DXP Cloud Environment
Outline
- Three-stage topology: Integration → Preproduction → Production
- Promotion-based deployments: Promote the same artifact forward - no rebuild on promotion
- Config is environment-scoped: Same compiled app, different injected values per environment
- Clear responsibility split: Optimizely runs the platform; your team owns code, correctness, and discipline
Introduction
Optimizely Digital Experience Platform (DXP) is a managed cloud hosting model built specifically for enterprise-grade digital experience solutions. When working with CMS 12 on DXP, developers are not deploying to arbitrary infrastructure. They are deploying into a structured, controlled, and managed environment with clearly defined lifecycle stages.
Understanding DXP environments is not only about knowing where code is deployed. It is about understanding:
- Why environment separation exists
- How deployments move between environments
- How configuration is isolated per environment
- How infrastructure responsibilities are divided between Optimizely and the development team
What is Optimizely DXP?
Optimizely DXP is a Platform-as-a-Service offering that provides a managed cloud foundation for running Optimizely CMS 12 solutions. It is built on Microsoft Azure and removes operational infrastructure complexity from development teams. DXP provides managed Azure infrastructure, load-balanced application instances, managed SQL databases, blob storage, CDN integration, automated deployment pipelines, and monitoring and logging.
In a traditional self-hosted model, development teams are responsible for provisioning servers, configuring networking, managing scaling rules, applying security patches, and maintaining database backups. With DXP, these infrastructure concerns are managed by Optimizely. The development team focuses on application behavior, configuration correctness, and deployment workflow discipline - which improves reliability, security posture, and long-term maintainability.
Standard DXP Environment Topology
A typical DXP solution includes three primary environments, each with a clearly defined role in the deployment lifecycle.
DXP Environments
Select an environment to expand and read the details.
Integration ▼
The Integration environment is the first cloud-based validation stage after local development. It mirrors production infrastructure patterns but is not intended for public-facing traffic, and may contain test data and experimental deployments.
It is used for: continuous integration testing, automated test validation, early QA verification, infrastructure configuration validation, and initial verification of deployments in a cloud context.
This environment is where developers confirm that the build artifact deploys successfully, application startup behaves correctly in cloud, configuration bindings work as expected, and no environment-specific assumptions exist in the codebase.
Preproduction ▼
The Preproduction environment serves as the final validation gate before going live. It is designed to mirror Production as closely as possible - infrastructure sizing, configuration structure, and integrations should match production settings.
Its primary purposes are: User Acceptance Testing (UAT), stakeholder validation, performance testing, content verification, and regression validation. Only validated builds should be promoted to Preproduction.
Production ▼
The Production environment serves live user traffic. It is optimized for high availability, horizontal scalability, operational monitoring, and traffic resilience.
Deployments to Production are controlled and promoted from Preproduction to ensure artifact consistency. Production is protected by strict deployment governance and must never receive untested builds.
Why Deploy to DXP?
CMS 12 can be hosted on infrastructure managed by the organization itself (on-premises, private cloud, or public cloud configured by internal ops), or deployed to Optimizely DXP. The choice depends on operational maturity, compliance requirements, and DevOps capability. DXP offers significant advantages for most enterprise scenarios.
- Infrastructure standardization: All DXP environments follow a standardized Azure-based architecture, eliminating configuration drift and reducing environment-specific inconsistencies. Developers do not need to manually replicate production-like infrastructure for testing environments.
- Managed scalability and availability: DXP environments are provisioned with load balancing and scaling strategies aligned with enterprise traffic patterns. Scaling is handled at the infrastructure layer without requiring application code changes.
- Deployment governance: The promotion-based model ensures the same artifact is used across environments, environment drift is minimized, and release governance is enforced - greatly reducing deployment-related incidents.
- Security and compliance: DXP includes managed networking, infrastructure patching, monitoring, and operational controls aligned with enterprise standards, reducing the operational burden on development teams.
The DXP Deployment Lifecycle
Deployments in DXP follow a promotion-based artifact workflow designed to ensure consistency and repeatability. The lifecycle flows from local development through CI build artifact generation, Integration deployment and validation, Preproduction promotion and validation, and finally Production promotion.
No rebuild occurs during promotion. The same binary artifact is reused at every stage - which guarantees that Production receives exactly what was validated in Preproduction. This structured approach prevents environment drift, reduces risk, and enforces disciplined release management.
Deploying Applications to DXP
DXP deployments are performed using the Optimizely CLI and deployment APIs.
Deployment Steps
Select a step to expand and see the command.
Step 1: Authenticate with DXP ▼
Authenticate the developer against the DXP project before any other operations.
Step 2: Build and package the application ▼
Generate a deployment artifact using the .NET publish process. This produces a compiled, deployment-ready package.
Step 3: Deploy to Integration ▼
Upload the artifact to the Integration environment. DXP validates the package before activating it.
Step 4: Promote to Preproduction ▼
After Integration validation, promote the exact same artifact to Preproduction. No rebuild occurs.
Step 5: Promote to Production ▼
After final validation in Preproduction, promote to Production. The same tested artifact is reused - no rebuild. This guarantees environment consistency.
Environment Configuration Management
Each DXP environment supports environment-specific configuration values while reusing the same compiled application artifact. Configuration differences typically include database connection strings, search endpoints, external API URLs, feature flags, and storage settings.
Configuration follows ASP.NET Core conventions using appsettings.json for base values. In DXP, environment-specific values are injected through platform configuration rather than requiring code changes or separate builds:
This approach ensures the same artifact can be deployed across all three environments, sensitive values are never hardcoded, and configuration differences are traceable and controlled. This separation between code and configuration is central to the DXP deployment philosophy.
Code versus Content Separation
DXP strictly separates code deployments from content and database state. Code deployments do not overwrite content data. Content is managed through editorial workflows and database management processes. This separation protects production data from accidental overwrites during deployments.
Note: Database synchronization between environments (for example, copying a production database snapshot to Preproduction for UAT) is a separate process managed via the DXP self-service portal, not via code deployment. Never assume a code deployment has any effect on content data.
Infrastructure Responsibilities
In DXP, infrastructure responsibilities are divided clearly. Understanding this boundary is critical to designing stable cloud-based CMS solutions.
Responsibility Split
Select a party to expand and see their responsibilities.
Optimizely manages ▼
- Azure hosting infrastructure
- Application instance scaling and load balancing
- SQL database provisioning, patching, and backups
- Blob storage
- Monitoring, logging, and security patching
Development teams manage ▼
- Application code and build artifacts
- Configuration correctness across environments
- Deployment discipline and promotion workflow
- Content modeling and editorial governance
Best Practices for Working with DXP Environments
- Avoid environment-specific code branching. Configuration should differ between environments, not code. Environment-specific code branches introduce risk and undermine the artifact consistency model.
- Use configuration overrides rather than hardcoded values. All environment-specific values should be injected via platform configuration, not embedded in the codebase.
- Validate integration points in Integration first. Confirm that all cloud-based dependencies, third-party APIs, and CMS services behave correctly before promoting forward.
- Treat Preproduction as a production rehearsal. Infrastructure sizing, configuration, and integrations should match production as closely as possible.
- Never deploy untested builds directly to Production. Performance, security, and stability all depend on disciplined environment usage.
Conclusion
DXP Cloud environments provide a structured, enterprise-grade deployment model for Optimizely CMS 12 PaaS solutions. Integration supports technical validation and early testing. Preproduction provides final release assurance and production-like validation. Production serves live traffic under controlled governance.
By understanding environment separation, deployment promotion workflows, configuration management, and infrastructure boundaries, developers can deploy CMS 12 solutions confidently and predictably. DXP is not merely hosting - it is an operational framework designed to enforce reliability, scalability, and disciplined release management at enterprise scale.