Deploy self-managed projects

Xperience supports traditional self-managed hosting options. You can run Xperience on dedicated or virtual servers or manage your hosting on the Microsoft Azure platform, including Azure SQL, Azure Storage, and other services.

Deploy the project

Xperience is a standard .NET project, so its code and other files support any compatible deployment process or pipeline. For general information, see the Host and deploy chapter of the .NET documentation.

Map parts of the file system to a shared storage

Some deployment environments, like Microsoft Azure for example, don’t provide a persistent file system. This can potentially lead to a loss of certain binary files when running new deployments, swapping slots, switching servers, etc. To prevent the possible loss, we recommend to map the following folders from your project’s file system to a shared storage:

  • ~/assets/ – contains content item assets and media libraries
  • ~/BizFormFiles/ – contains files uploaded from users using the Upload file form component

Xperience already provides built-in support for mapping of these folders to Azure Blob or Amazon S3 cloud-based storage.

For more information, see Azure Blob storage and Amazon S3.

Deploy the database

Prepare the Xperience database within your development environment, and then use a standard backup&restore process to move the database to the target environment.

If you wish to deploy an empty database with default data necessary to run Xperience by Kentico, create a project using the kentico-xperience-mvc boilerplate template and run the kentico-xperience-dbmanager CLI utility. See Installation.

To update database content as part of later deployments, we recommend using the Xperience Continuous Deployment feature. Note that CD data does not include license keys, which need to be added manually after the deployment.

Database server time zones

To ensure consistent handling of time values, the server running your Xperience by Kentico application must be configured to use the same time zone as the database server.

If possible, use the same time zone for both your local environment and the production server hosting your database. Otherwise you may encounter time shift problems with the deployed data.

Update the Xperience version of deployments

To learn how to update a deployment to a newer version of Xperience by Kentico, see Update Xperience by Kentico projects.

Microsoft Azure deployment

For most self-managed deployments to Microsoft Azure, we recommend Azure Web Apps. Azure Web Apps are quick to create and easy to set up and manage.

Xperience applications that require a lot of customization may benefit from Azure Virtual Machine deployments, where developers have the ability to control every aspect of the environment.

Azure SQL Database tier recommendations

Microsoft Azure provides the following purchasing models for Azure SQL databases:

Each model is further divided into tiers and performance levels. See the corresponding Microsoft documentation for details.

Recommendations for running Xperience databases in Azure SQL:

Project demands

DTU-based tier

vCore-based tier


Projects in development


General purpose

The lowest Standard level is suitable only for projects that are not in production and have only small performance demands.

Even though Xperience runs in the DTU-based Basic tier, we do not recommend using this tier as it severely restricts database performance.

Read-only projects


General purpose

For small Xperience projects only.

Larger read/write intensive projects


Business critical

Websites expecting a large amount of visitors and database requests.

We also recommend that you perform a load test when switching to a new Azure SQL tier to make sure the database provides satisfactory performance. Choosing performance levels that do not cover your project demands can cause slow database response times and generally low performance.

You can switch between deployment models and adjust their configuration on the Azure Management Portal → Select your database → Configure tab.

Azure SQL database elastic pools

In environments where multiple independent projects each use a single database, you can store individual databases in an elastic pool. The databases in an elastic pool are on a single Azure SQL Database server and share a set number of dynamically allocated resources (DTUs or vCores), which helps minimize overall expenses. See the Elastic pools Microsoft documentation for more information.