Deploying C1 CMS on Azure App Services

Make use of Azure App Services for C1 CMS multiple-instance support

There are a number of things you need to consider when deploying a C1 CMS solution on a App Service.

Multiple-instance support and CM/CD deployments

An out-of-the-box C1 CMS deployment does not support multiple instances for the C1 console.

The frontend, however, does support them, and for a high throughput we recommend having 2 deployments with different configurations:

  • Content management (CM) deployment. A single-instance deployment that C1 CMS administrators / content editors will use to update their website's content.
  • Content delivery (CD) deployment.  A multiple-instance deployment for the frontend website.

To publish changes from CM to CD instance, the Cloud Publisher package can be configured.

Cloud Publisher allows pushing file changes from a CM instance to a GIT repository, and an Azure App Service can be configured to pick up new commits from a GIT repository automatically.

 graph TD;

subgraph DNS
cm_hostname[Content management hostname]
cd_hostname[Public website hostname]

subgraph azure[Azure App Services]
   cm_website[Content management CM<br>Single instance and minimal caching]
   appservciebuild[App Service Build Service]
   cd_website[Content delivery website<br>Multi-instance and caching enabled]

cm_hostname -- CNAME or A record ---> cm_website
cd_hostname -- A Record--> cd_website

subgraph GIT
   git[GIT repository with website]
   cm_website -- Cloud Publisher --> git

   appservciebuild -- Reads changes from --> git
   appservciebuild -- Pushes changes to --> cd_website

To host a GIT repository, you can use one of the following:

  • GitHub: A personal access token (PAT) can be used for this repository host at the moment when configuring Cloud Publisher
  • Azure DevOps.  A PAT and Git Credentials can be used for this repository host at the moment when configuring Cloud Publisher

Important. Azure DevOps must be linked to the same Azure subscription as used by the related App Service.

Service creation

The target ASP.NET version must be 4.8.

DNS mapping and SSL certificates

The built-in Azure DNS for App Services fails under high load, therefore for the public website hostname it is recommended that an "A" record be used instead of a "CNAME" record.

Registering a custom domain on an App Service requires access to the DNS service as creating a TXT record is needed to confirm the domain ownership.

Redirecting from non-"www." to "www." hostname

Many websites should be accessible both with and without "www." hostname prefix, for example: and

  1. Make sure both hostnames are configured in the "Custom domains" section of the Azure App Service in use, and an SSL certificate is attached to each.
  2. Create a redirect from the non-"www" website to the "www" website.

Note. Some DNS services provide a built-in redirect functionality. It may not, however, work when the non-www domain is accessed via HTTPS.

Continuous deployment

When connecting to a GIT repository from your App Service, specify the build provider to be an "App Service Build Service".

Default document

To make sure that requests to the root of the website are handled correctly, specify the default documents in the "Settings" -> "Configuration -> "Default documents" to be:

  • Default.aspx
  • hostingstart.html
  • index.html

Important. Note that the order is important, and default.aspx has to appear first.

Instance count

The number of instances can be increase to reduce request queueing, even if the CPU usage is less than 50%.

Updating config, XML and ASPX files live

All the instances of the same App Service share the same network drive.

When implementing custom code, it is necessary to take this fact into account. So if one instance holds a write lock on a file, other instances will not be able to read it.

The App Service Editor allows editing the deployed files live. When editing live, please consider the following:

  • Changes to the /Bin folder, /web.config or /App_Config/*.config files will trigger a website restart, which may lead to short downtime (from 30 seconds to 1 or 2 minutes)
  • Changes to XML data files /App_Data/Composite/DataStores/*.xml are usually picked up automatically, without the restart. However, any custom implementation here may cache some of the data, and a restart may be needed for the change to have an effect.
  • Any changes to *.aspx files may stop the affected ASPX pages from working, until the App Service is restarted.