DXP Environment Roles

By Optimizely Education
Published: Mar 6, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Focus: Understand how Integration, Pre-production, and Production serve different roles in the DXP lifecycle.
Core idea: As code moves upward through DXP, infrastructure behavior, indexing, email handling, and operational expectations change.
Developer shift: In DXP, developers spend less effort managing servers directly and more effort managing environment-aware configuration.
Practical outcome: Reliable deployments depend on respecting isolation, using the right environment for the right job, and coding with environment awareness.

Expanding your deployment strategy from a single local machine to the Optimizely Digital Experience Platform (DXP) introduces a structured environment hierarchy. This multi-environment approach—comprising Integration, Pre-production, and Production—is designed to decouple the volatility of daily development from the stability required by live business operations.

For a DXP developer, understanding the technical roles and behavioral shifts between these environments is critical for managing performance, security, and the reliability of content delivery.

1. The DXP Lifecycle: Environment Hierarchy

Optimizely’s PaaS architecture provides distinct, isolated environments that mirror the software development lifecycle (SDLC). Each level of the hierarchy serves a specific business and technical intent.

Integration (Inte): The Functional Sandbox

The Integration environment is the first cloud-based destination for your code. It acts as the gateway between a developer's local machine and the managed platform.

Primary Role: Continuous integration, daily builds, validating external API connections (for example, ERP and CRM), and functional testing.
Infrastructure: Usually runs on a fixed, non-scaling plan. It is not intended for load testing but rather for confirming that the cloud-awareness logic handled by EPiServer.CloudPlatform.Cms is functioning correctly.
CDN Behavior: In DXP, Cloudflare sits in front of all sites. However, the Integration environment (*inte.dxcloud.episerver.net) is configured to bypass CDN polishing features. This allows developers to see changes instantly without the lag of global cache propagation.

Pre-production (Pre): The Staging Mirror

The Pre-production environment is a mission-critical bridge. Its primary objective is to replicate the Production state as closely as possible to minimize last-mile deployment risks.

Primary Role: User Acceptance Testing (UAT), performance benchmarking, load testing, and security auditing such as penetration testing.
Infrastructure: Unlike Integration, Pre-production is auto-scaling. If your load test simulates a surge in users, the Azure App Service plan will scale out to meet the demand, allowing you to validate your scaling logic before going live.
Constraint: Security Isolation. A common mistake is sharing API keys or database tokens between Pre-production and Production. Optimizely strictly advises against this to prevent cross-contamination of analytics or transactional data.

Production (Prod): The Public Delivery Hub

This is the final destination where editors author live content and visitors consume your experience.

Primary Role: Live visitor traffic and content authoring.
Infrastructure: Premium auto-scaling Azure resources managed by Optimizely’s Site Reliability Engineering (SRE) team.
Proactive Scaling: For predictable surges such as Black Friday or high-budget marketing campaigns, developers should open a support ticket 3–4 weeks in advance. While DXP is auto-scaling, proactive pre-warming of resources provides a smoother experience for massive, global events.

2. Technical Shifts Across the Stack

As code moves up the chain, several platform components change their behavior. Developers must account for these shifts in their configuration patterns.

Search and Indexing (Search & Navigation and Graph)

In CMS 13, indexing logic is strictly isolated per environment. This design ensures that development activities never degrade the quality of the production search experience.

Multi-tenant Indexing: Each environment (Inte, Pre, Prod) has its own dedicated search index. This prevents a re-index job in the Integration environment from wiping out the search results on your live production site.
Synchronization: The Production environment is configured for continuous event-based indexing. In lower environments, you may need to manually trigger the Content Indexing Job after significant content migrations or convention changes in C#.

Outgoing Traffic and Email

Optimizely DXP includes SendGrid for transactional emails. Configuration here is vital to avoid spamming real users with test data.

Sandbox Mode: In Integration and Pre-production, developers often implement logic to suppress real emails or redirect them to a test mailbox such as Mailtrap to avoid accidentally emailing real customers during a QA cycle.
IP Whitelisting: If your CMS needs to call a backend service such as an internal SAP instance, the outgoing static IPs for each environment are different. You must collect the IPs for all three environments from the PaaS Portal to ensure connectivity persists as the build progresses toward Production.

3. Reference: Environment Comparison Matrix

Feature	Integration (Inte)	Pre-production (Pre)	Production (Prod)
URL Pattern	`inte.dxcloud.episerver.net`	`pre.dxcloud.episerver.net`	Custom hostnames (for example, .com)
Auto-Scaling	No (Fixed Capacity)	Yes (Automatic)	Yes (Premium Elastic)
CDN Cache	Bypassed / Minimal Delay	Standard Cloudflare	Optimized Global Edge
Indexing Policy	Manual / On-Demand	Manual / Scheduled	Continuous Automatic
Target Use Case	Dev Builds & API Integration	UAT & Load Testing	Live Traffic & Authoring

4. Coding for Environment Awareness

CMS 13 builds on ASP.NET Core’s IWebHostEnvironment. Avoid hardcoding environment names as strings; instead, use the standard .NET constants which DXP automatically populates via environment variables.

Best Practice

Use dependency injection to access the environment and apply logic based on the EnvironmentName property.

public class EnvironmentLogicSample
{
    private readonly IWebHostEnvironment _env;

    public EnvironmentLogicSample(IWebHostEnvironment env)
    {
        _env = env;
    }

    public void ProcessConfiguration()
    {
        if (_env.IsDevelopment())
        {
            // Local dev specific logic (e.g., Debug logging level)
        }
        else if (_env.IsEnvironment("Integration"))
        {
            // Inte-specific logic: Use Mock Payment Providers
        }
        else if (_env.IsProduction())
        {
            // Only runs on the live prod instance: Enable Real Transactions
        }
    }
}
    

By leveraging appsettings.Integration.json and appsettings.Production.json, you can inject specific API endpoints for each stage of the hierarchy without any manual file changes during deployment.

Conclusion

In the DXP ecosystem, your role as a developer shifts from managing server files to managing environment configuration. By respecting the isolation of the Integration sandbox and utilizing the auto-scaling power of the Pre-production mirror, you help ensure that your CMS 13 code is resilient, secure, and ready for the global scale of the Production environment.