--- title: Deploy DXP slug: dxp/cms12-docs docTags: createdAt: 2026-06-01T17:39:49.147Z --- You can deploy solutions from your development environment to any cloud environment as [code packages](doc\:deploy-using-code-packages). You can also move databases and BLOBs between environments using the [source environment API](docId:9v-46N7q90ivFSSprj4u0). See also [DXL Cloud API](https://world.optimizely.com/documentation/class-libraries/rest-apis/dxc-service/) for Deployment REST APIs, :::hint{type="warning"} **Caution** After going live, you can no longer overwrite the production database using the deployment API. ::: Optimizely takes care of the following as part of the service: - Set up of environments. - Initial troubleshooting and roll-back if issues arise. ## Deploy to production The following image illustrates deployment from a local development environment to *Production*. In this scenario, the production environment is "empty" initially. You first create code and content in your local development environment and then push this to your *Integration* environment. You then deploy to *Preproduction* and validate that everything works as expected. When ready, you can deploy to *Production*. ![](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/Phz0Zpyu4oI90u3pc3VcU-20260826-135100.png) ## Continuous deployment After the first deployment, website users edit content in the Production environment. As part of the upgrade process, you can move content from Production back to the Preproduction and Integration environments, where developers can add solution updates. ![](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/9QRTnXsEZgWm00Or5bdyv-20260826-135100.png) ## Deployment methods You can deploy using deployment tools for a version-controlled team development environment or through Visual Studio using the Optimizely extensions and publish profiles. In both cases, you need to contact Optimizely for the first time before you deploy to get the needed information on deployment integration settings. You can use any deployment tool that supports Azure Resource Manager (ARM), such as Octopus Deploy, Visual Studio Team Foundation Server, or TeamCity. - **Deploy using Deployment API** – Deploying the code changes using the Deployment API is currently the recommended approach for publishing application code to a DXP Environment. See [Deployment API](docId\:w5bAkyj80j03bZV7GNlrb) for an overview and instructions on how to use the API. - **Deploy from a version-controlled environment** – Work in a development team using version control for your source code. You can use any deployment tool such as :::Iframe{code=""} ::: Octopus Deploy, :::Iframe{code=""} ::: Visual Studio Team Services, or [Azure DevOps and Optimizely deployment API](https://world.optimizely.com/blogs/anders-wahlqvist/dates/2019/10/azure-devops-and-episerver-deployment-api/) (blog post by Anders Wahlqvist) for instructions on how to integrate Deployment API to CI/CD pipeline such as Azure DevOps. :::Paragraph{indent="2"} ::: :::Paragraph{indent="2"} ::: ![](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/neRPVzL-NXZAJ_ApMuhFV-20260722-203650.png) :::Paragraph{indent="1"} **Related blog post:** [Azure DevOps and Episerver (Optimizely) deployment API](https://world.optimizely.com/blogs/anders-wahlqvist/dates/2019/10/azure-devops-and-episerver-deployment-api/) (Anders Wahlqvist) ::: ## Deploy code changes between environments In Optimizely Digital Experience Platform (DXP), manage deployments using the [DXP Management Portal](docId\:jsjQEdJu2vU33eXzlbTzz). Optimizely's deployment automation engine performs the following steps when deploying. 1. **Package code from the source environment** – Creates a deployment package of the code in the source environment. :::hint{type="info"} **Note** - Files with the `.log` extension are not included. - If a `.txt` file cannot be read, (for example, it is locked by another process), it is skipped. - Locked files under `*wwwroot\App_Data\` are ignored. - Everything under `wwwroot\App_Data\Blobs` is excluded (should not be used in Azure). ::: 2. **Create a slot on the target environment** – This slot has the same configuration as the current production slot. Other settings, such as logging to BLOB storage, are also configured according to DXP standards. At this stage, the slot is in a *stopped* state. 3. **Deploy code to the slot** – The code package created in step one is deployed. 4. **Prepare monitoring and extensions** – Extensions for application performance monitoring are installed on the slot and configured according to DXP standards. 5. **Apply configuration transforms** – Any configuration transforms included in the code package matching the target environment are applied on the target. See [Environment configurations](docId\:MATFL0bRew1vNbAQAKWcV). 6. **Configure warmup for the target slot** – The deployment engine checks for an `` section in `web.config`; if none exists, it is created. See [Warm up sites](docId\:DlSMeX-axf38oouC5dQLk). 7. **Start the slot and prepare for "Go Live"** – The slot is started and initiates a "swap with preview." The deployment engine monitors the site until it completely starts and warm-up finishes for its instances. The slot scales to the same level as the current production site to handle the production traffic load after the swap. 8. **Validate the site** – A manual "smoke test" is performed to verify that the site works as expected. For this to work, configure your Optimizely site to respond to the slot address. See [Before going live step 1 in the Going live section](docId\:xvdQls3io4LX4U7gr66Q3). 9. **Go Live/Reset** – If the site works as expected, it is swapped into the site's production slot of the current target environment (Preproduction or Production), and the old slot is stopped. If the site in the slot does not behave as expected, the swap is aborted, and the slot site is stopped. The files are saved for troubleshooting or until a new deployment is attempted. ## Important notifications :::hint{type="info"} **Note** Read through and follow the recommendations below to make deployment as smooth as possible. ::: - Make sure that the software you deploy supports Azure Web Apps. See [Requirements](docId\:tH8LtpR9f_RAt-J55B8Hj) for supported software and components. - To avoid data loss or corruption, if you have breaking changes where the old version of the sites' code cannot work with the new database version, deploy using *maintenance page* when you deploy **database schema updates** or **changes to content types**. The target site is then taken offline, showing the ([customizable](docId\:MATFL0bRew1vNbAQAKWcV)) maintenance page. If a deployment contains these types of changes, inform Optimizely when ordering deployment to production. You should also ensure that the major or minor version is incremented to trigger the initialization module to make the necessary updates. :::hint{type="info"} **Note** If your changes are additive and do not break the sites when the old and the new code runs in parallel during deployment, you can deploy without using *maintenance page*. ::: - When you deploy to a production environment, apply the correct configurations. **Never** use credentials, tokens, or endpoints from a *Preproduction* environment, in *Production*. You can set up environment-specific configurations that automatically apply depending on the environment; see [Environment configurations](docId\:MATFL0bRew1vNbAQAKWcV). - If you use **add-ons** on the site, ensure that you include the *modules* and *modulesbin* folders in the project so that these are published. Publish the *database schema* on the first publish operation *only*. - You must install **add-on modules** to the \_Integration \_environment through NuGet to work with the DXC Service deployment process. The default configuration prevents users from installing add-ons on a production website; do not change this. - Before you deploy, add a wildcard binding to the site in the **Manage Websites**screen. This helps to prevent failures due to URL-dependent code when migrating the database between environments. See the following image, which shows an example of this binding. 1. Select **Admin > Configuration > Manage Sites**. 2. Click **Add** and add a wildcard (\*) Host Name. ![](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/h8YPWwbm_4ow-ydeKv_9F_c4346cb-wildcard-binding.png) ## Related topics - [Create a CMS site and deploy](docId\:RIn0cobbPnEmEafa16av8) - [Deploy a CMS site](docId\:O-u0L3gdPwwJMi0xCFRLL) - [Deploy a Commerce (PaaS) site](docId:8-95xFJ5mAnWvik2jIIhy) - [Deploy code changes](docId:6ye02seInCDkMBQOyQJ1I) - Blog post: [Setting up Continuous Integration with Azure DevOps and Episerver DXC Service (Optimizely DXP)](https://world.optimizely.com/blogs/stephan-lonntorp/dates/2018/11/setting-up-continuous-integration-with-azure-devops-and-episerver-dxc-service/)