DXP Cloud Hosting - Optimizely Digital Experience Platform

Exam Area: Content Area 2 – Installation, Operation & Configuration (20%)
Source: https://academy.optimizely.com/student/path/3128969/activity/4970335
Published: Feb 14, 2026

---

Overview (Academy Key Points)

• 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.
• Responsibility split: Optimizely runs the platform; the team owns code + correctness + discipline.

---

1. What Is DXP? (Academy – 4970335)

DXP (Digital Experience Platform) is Optimizely's managed PaaS cloud hosting for CMS 12, built on Microsoft Azure. It removes operational infrastructure complexity from development teams.

DXP provides:

• Managed Azure infrastructure (App Service, SQL, Blob, CDN)
• Load-balanced application instances
• Automated deployment pipelines
• Monitoring and logging

---

2. Standard DXP Environment Topology (Academy – 4970335)

Key rule: Only after Preproduction validation is the artifact promoted to Production — no rebuild occurs.

---

3. The DXP Deployment Lifecycle (Academy – 4970335)

Local Dev → CI Build artifact → Deploy to Integration → Validate
→ Promote to Preproduction → UAT + Perf → Promote to Production

• Artifact is immutable: the same binary is reused across all environments
• Code deployments do NOT overwrite content/database

---

4. Infrastructure

DXP Components:

• Azure App Service – Web hosting
• Azure SQL Database – Managed database
• Azure Blob Storage – File/media storage
• Azure CDN – Content delivery
• Azure Application Insights – Monitoring

Infrastructure responsibilities:

---

5. Environment Configuration Management (Academy – 4970335)

Same compiled app — different injected configuration values per environment:

{
  "ConnectionStrings": {
    "EPiServerDB": "<env-specific-connection-string>"
  }
}

Configuration differences (DB, search endpoints, API URLs, feature flags) are injected via platform configuration — NOT via conditional code.

Best practice: Never hardcode environment-specific values; never use environment-specific code branching.

---

6. Deployment API

# Create a deployment package
dotnet publish -c Release -o ./publish

# Authenticate
epi cloud login

# Deploy to Integration
epi cloud deploy --projectId <project-id> --environment Integration --package <package-path>

# Promote Integration → Preproduction
epi cloud promote --projectId <project-id> --source Integration --target Preproduction

# Promote Preproduction → Production
epi cloud promote --projectId <project-id> --source Preproduction --target Production

---

7. Self-Service Management Portal

URL: https://paasportal.episerver.net

• Deploy code between environments
• View logs (Application, Event)
• Manage connection strings
• Restart the application
• Reset environments

---

8. Backup and Recovery

• Database: Automated daily backups (Azure SQL)
• Blob Storage: Geo-redundant storage (GRS)
• Point-in-time restore: 7–35 days

---

9. Deployment Best Practices (Academy – 4970335)

• Avoid environment-specific code branching
• Use configuration overrides rather than hardcoded values
• Validate integration points in Integration first
• Treat Preproduction as a production rehearsal
• Never deploy untested builds directly to Production
• Validate content types and property mappings before upgrading

---

10. Self-Service Management Portal (PaaS Portal)

URL: https://paasportal.episerver.net

Features:

• Deploy code between environments
• Reset environments
• View logs (Application, Event logs)
• Manage connection strings
• Configure environment settings
• Restart the application

---

11. CDN Configuration

Optimizely integrates CDN:

• Automatically caches static assets
• Purges cache when new content is published
• Configuration in appsettings.json:

{
  "EPiServer": {
    "CMS": {
      "CDNUrl": "https://cdn.example.com"
    }
  }
}

---

12. Load Balancing in DXP

DXP uses Azure App Service with built-in load balancing:

Key considerations:

• Sticky sessions are not recommended
• Shared cache via Redis or Azure Cache
• Event routing for multi-instance deployments

// Configure Redis for shared cache
builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = "my-redis.redis.cache.windows.net:6380,password=...,ssl=True";
});

---

13. Deployment Best Practices

1. Do not use AutoUpdateDatabaseSchema in Production
2. Schema migrations should run as a separate step
3. Blue-green deployment via DXP slots
4. Smoke tests after each deployment
5. Always have a rollback plan ready

---

14. DXP Requirements

---

Review Questions

1. How many environments does DXP have? (3: Integration, Preproduction, Production)
2. What does promotion-based workflow mean? (The same artifact is promoted forward — no rebuild)
3. What is the Integration environment used for? (First cloud-based validation: CI tests, config binding, infrastructure compatibility)
4. Why should you avoid environment-specific code branching? (The same binary must run in all environments — config differences are handled via platform configuration)
5. What does DXP manage? (Azure infrastructure, scaling, SQL, Blob, Monitoring — the team manages code + correctness)
6. What is the Deployment API endpoint? (https://paasportal.episerver.net/api/v1.0/)
7. Should AutoUpdateDatabaseSchema be enabled in Production? (No)
8. Where is the self-service portal accessed? (https://paasportal.episerver.net)