Dual-Track Setup

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

Track 1: Local baseline for fast learning, debugging, content modeling, and rendering work
Track 2: DXP production path for cloud-aware deployment, scale, and operational reliability
Developer mindset: Learn core CMS mechanics locally, then harden the solution for distributed PaaS execution
End goal: Move from workstation confidence to production-grade composable delivery

Introduction

Setting up Optimizely CMS 13 requires a modular approach that balances rapid developer feedback with production-grade cloud reliability. For learners and developers, it helps to distinguish between a baseline local setup, which is ideal for mastering CMS mechanics, content modeling, and rendering, and the DXP cloud integration path, which is required for production-grade, composable experiences.

This module walks through both tracks so that you can scale from a single workstation to a global PaaS infrastructure without losing the plot halfway through.

1. Part 1: The Local Explorer Path (Comprehensive Setup)

The Local Explorer Path is intended for developers who want to master the fundamental CMS 13 APIs, build content architecture, and test property rendering without immediately taking on the extra operational overhead of cloud services such as Optimizely Graph or Opti ID.

This local-first approach supports high-velocity coding and debugging in a tightly controlled environment.

1.1 Environment Preparation & Prerequisites

Before scaffolding the project, the host machine needs to be ready for modern .NET development. Unlike older CMS generations, there is no bulky installer here. The platform is package-managed.

.NET 10 SDK & Runtime: This is the core engine. Verify the environment with dotnet --version. Your IDE should also support the latest C# features.
Database Host: Visual Studio LocalDB is fine for a starter setup, but many developers prefer SQL Server Express or a local Dockerized SQL instance for more realistic workloads.
The Optimizely NuGet Feed: Optimizely packages are distributed through a dedicated feed, so it must be registered before package restore can work cleanly.

dotnet nuget add source https://nuget.optimizely.com/feed/packages.svc/ -n Optimizely

1.2 Scaffolding with the .NET CLI

Modern Optimizely development is CLI-first. Start by installing the project templates so that dotnet new can scaffold CMS 13 solutions.

dotnet new install EPiServer.Templates

For a clean starting point, many developers use the epi-cms-empty template:

dotnet new epi-cms-empty --name MyLocalCms --output ./src/MyLocalCms

1.3 Database Strategy: The Managed Schema Approach

In CMS 13, manual SQL scripting is no longer the normal path for bootstrapping the schema. The application manages its own schema state.

Start by defining the connection string in appsettings.Development.json:

{
  "ConnectionStrings": {
    "EPiServerDB": "Server=(localdb)\\mssqllocaldb;Database=MyLocalCms;Trusted_Connection=True;MultipleActiveResultSets=true"
  }
}

Then explicitly allow the CMS to update database compatibility automatically:

services.Configure<DataAccessOptions>(options => 
{
    // Synchronizes the database schema with the assembly version of your NuGet packages
    options.UpdateDatabaseCompatibilityLevel = true;
});

1.4 Identity Bootstrapping: The First Launch Experience

Since the local track skips cloud-based Opti ID, you still need a secure way to create the first editor or admin account. CMS 13 supports a registration flow for the first launch experience.

services.AddAdminUserRegistration(options => 
{
    // Restricts account creation to localhost requested to ensure security integrity
    options.Behavior = RegisterAdminUserBehaviors.Enabled | 
                       RegisterAdminUserBehaviors.LocalRequestsOnly;
});

The action: Run the app, navigate to /EPiServer/CMS, and the system will redirect you to the first-user registration flow where you can define local admin credentials.

2. Part 2: The DXP Professional Path (Pushing to Cloud)

Once the local foundation is solid, the next step is preparing the solution for Digital Experience Platform (DXP). This means making the application cloud-aware and switching from local convenience to artifact-based deployment discipline.

2.1 Code-Level Cloud Awareness: The Integration Package

To run reliably in a distributed Azure-based environment, the solution needs cloud platform support. This is typically introduced conditionally so local development remains lightweight.

public void ConfigureServices(IServiceCollection services, IWebHostEnvironment env)
{
    services.AddCms();
    
    // Condition check ensures local development remains performant
    if (!env.IsDevelopment())
    {
        // AddCmsCloudPlatformSupport maps the environment variables provided by PaaS
        services.AddCmsCloudPlatformSupport(_configuration);
    }
}

2.2 Building the Verifiable Deployment Artifact

Deployment to PaaS is artifact-based. You generate a release-ready package that the cloud build pipeline can process into a deployable unit.

Release Build: Run dotnet publish -c Release -o ./publish.
Packaging: Zip the full contents of the /publish directory.
Renaming: Change the resulting suffix to .nupkg, which is the expected deployment package format.

2.3 Deployment Orchestration via PowerShell

The EpiCloud PowerShell module is commonly used in CI/CD automation so deployments stay repeatable, auditable, and much less dependent on heroic manual clicking.

# 1. Establish a secure session with DXP API
Connect-EpiCloud -ProjectId "dxp-project-guid" -ClientKey "api-key" -ClientSecret "api-secret"

# 2. Acquire a Temporary SAS Link and upload your package
$sasUrl = Get-EpiDeploymentPackageLocation
Add-EpiDeploymentPackage -SasUrl $sasUrl -Path .\MyProject.cms.app.1.0.0.nupkg

# 3. Request a Direct Deployment to the 'Integration' environment
Start-EpiDeployment -DeploymentPackage "MyProject.cms.app.1.0.0.nupkg" -TargetEnvironment "Integration" -DirectDeploy

The Vision

While local development provides the high-velocity sandbox required for coding and debugging the core CMS 13 APIs, the platform reaches its ultimate potential only when deployed to DXP with Optimizely Graph and Opti ID enabled. This powerful trio transforms the CMS from a simple Content Repository into a Composable Content Intelligence hub. By leveraging Optimizely Graph as the high-performance delivery layer, developers can deliver sub-second multi-channel experiences that bypass traditional database bottlenecks. Simultaneously, Opti ID standardizes institutional security, allowing teams to transition seamlessly between Optimizely products while ensuring that developers spend less time managing local identity stores and more time innovating on customer-facing features.

Conclusion

The dual-track model gives developers a practical way to learn and build without confusing local experimentation with production readiness. The local baseline is where you understand the platform. DXP is where you prove the solution can survive the real world. Both matter, and skipping either one usually ends with either fragile code or very confident confusion.