Environment Management
Why environment management matters
Section titled “Why environment management matters”Pushing code directly to production is a recipe for outages. A structured environment model gives your team a safe place to develop, a staging area for validation, and a production environment that only receives verified changes. Understanding how Optimizely Cloud separates these concerns helps you build a reliable delivery process and avoid surprises on launch day.
The three-environment model
Section titled “The three-environment model”Every Optimizely Cloud project includes three environments that form a promotion pipeline:
Integration
Section titled “Integration”The development sandbox. Code pushed here builds and deploys automatically. Use Integration for day-to-day development, testing new features, and verifying that your application starts correctly.
- Purpose — Early testing and development
- Deploys — Automatic on every push to the configured branch
- Database — Separate instance, often reset or refreshed from production
- Who uses it — Developers
Preproduction
Section titled “Preproduction”The staging environment. Code is promoted here from Integration after passing initial validation. Preproduction should mirror production as closely as possible in configuration, data, and infrastructure.
- Purpose — Final validation before production
- Deploys — Manual promotion from Integration
- Database — Separate instance, periodically synced from production
- Who uses it — QA engineers, product owners, stakeholders
Production
Section titled “Production”The live environment serving real users. Code reaches Production only after passing through Integration and Preproduction. Deployments here follow zero-downtime patterns.
- Purpose — Live site serving end users
- Deploys — Manual promotion from Preproduction
- Database — Production data with automated backups
- Who uses it — End users
Environment isolation
Section titled “Environment isolation”Each environment is fully isolated at the infrastructure level:
| Resource | Shared or isolated |
|---|---|
| Web instances | Isolated per environment |
| SQL database | Isolated per environment |
| Blob storage | Shared storage account, isolated containers |
| CDN configuration | Isolated per environment |
| Custom domains | Isolated per environment |
| Environment variables | Isolated per environment |
This isolation means a failed deployment in Integration cannot affect Production. Database schema changes in Preproduction do not touch Production data. Each environment has its own connection strings, API keys, and feature flags.
Configuration per environment
Section titled “Configuration per environment”Applications need different settings in each environment — database connections, API endpoints, logging levels, and feature toggles. Optimizely Cloud provides several mechanisms for per-environment configuration.
Environment variables
Section titled “Environment variables”Set through the management portal or API. These override values in your application configuration files without requiring code changes.
Common environment-specific settings:
- Connection strings — Database, search, and cache endpoints
- API keys — Third-party service credentials
- Feature flags — Enable or disable features per environment
- Logging level — Verbose in Integration, warnings-only in Production
- CDN settings — Cache durations and purge behavior
Configuration transforms
Section titled “Configuration transforms”For .NET applications, web.config transforms apply environment-specific overrides at deploy time. The platform recognizes transform files named by environment:
web.Integration.configweb.Preproduction.configweb.Production.config
AppSettings files
Section titled “AppSettings files”ASP.NET Core applications use the standard appsettings.{Environment}.json pattern. The platform sets the ASPNETCORE_ENVIRONMENT variable automatically to match the current environment name.
Content synchronization
Section titled “Content synchronization”Code flows forward (Integration to Preproduction to Production), but content sometimes needs to flow backward. Production content — the pages, media, and data that editors create — is often needed in lower environments for realistic testing.
Database export/import
Section titled “Database export/import”You can export a production database backup and import it into Integration or Preproduction through the management portal. This gives developers and testers real content to work with.
Best practices:
- Refresh lower environments regularly so tests run against realistic data
- Sanitize sensitive data (customer emails, payment details) after importing
- Document the refresh schedule so teams know how current their test data is
Blob storage sync
Section titled “Blob storage sync”Media files stored in blob storage can be synchronized from Production to lower environments. The management portal provides tools for this, or you can configure your application to read from the production blob storage endpoint in lower environments (read-only).
Environment-specific URLs
Section titled “Environment-specific URLs”Each environment gets a default hostname:
| Environment | Default URL pattern |
|---|---|
| Integration | {project}.inte.optimizely.cloud |
| Preproduction | {project}.prep.optimizely.cloud |
| Production | {project}.optimizely.cloud |
Custom domains are supported on all environments. Production typically uses your public domain. Preproduction and Integration can use subdomains for stakeholder access.
Access control
Section titled “Access control”Environment-level access controls determine who can deploy, who can view logs, and who can manage configuration.
- Developers — Typically have full access to Integration, read access to Preproduction and Production
- QA/Staging reviewers — Access to Preproduction for validation
- Operations — Full access to all environments for deployment and troubleshooting
- Editors — CMS access on all environments, but typically work in Production