Try our conversational search powered by Generative AI!

Johan Björnfot
Dec 5, 2013
(0 votes)

Deployment and Cloud support

This post is most an overview of the changes we have done around deployment and how a site is “packaged”. There are much more information about deployment and cloud support in the CMS SDK under “Developer Guide/Deployment”. For example can information/examples about deployments to Azure and Amazon be found there.

XCopy enabled deployment

In EPiServer 7.5 we have changed how a site is “packaged” so deployment of an EPiServer CMS site can be done through XCOPY deployment simply by copying application files. An XCOPY-style file transfer simplifies deployment and maintenance of EPiServer sites since no registry entries are created, and no shared components are registered. Examples of XCOPY-style hosting is Azure Web Sites and Amazon Elastic Beanstalk, where basically only a IIS instance is provided, and it is not possible to run an installation setup procedure.

Note: We do not say that you should use XCOPY deployment as such, you should of course use the deployment that suits your hosting environment. But making deployment copy enabled should benefit other deployments as well like e.g. MSDeploy, FTP and external deployment tools.

Another benefit of the XCOPY architecture in EPiServer CMS is that there is no machine- or site-specific information stored in configuration files, making it possible to use a shared folder for multiple servers. During development in a shared environment with source control, developers can keep configuration files checked in and still be able to create a site which can be duplicated in a multi-site deployment.

Another change that is related to copy enabled deployment is that we have removed the usage of Windows service for CMS. This means that the scheduled jobs are maintained within the web application it self.


Cloud support

Another change we have done to make it easier to scale an EPiServer installation by adding/removing IIS instances/machines is that we have changed so “services” like Blob storage (replaces previously used VPP based files) and event management (between sites) is provider based. The idea is that one IIS instance running the site only have knowledge about the services and not direct knowledge about other running web site instances. Then it is possible to add/remove one instance without having to touch the other running instance. A conceptual picture of this is:


There are separate NuGet packages EPiServer.Azure and EPiServer.Amazon in our feed that contain Blob providers and event providers for each of those environments.

Dec 05, 2013


Please login to comment.
Latest blogs
Headless forms reloaded (beta)

Forms is used on the vast majority of CMS installations. But using Forms in a headless setup is a bit of pain since the rendering pipeline is based...

MartinOttosen | Mar 1, 2024

Uploading blobs to Optimizely DXP via PowerShell

We had a client moving from an On-Prem v11 Optimizely instance to DXP v12 and we had a lot of blobs (over 40 GB) needing uploading to DXP as a part...

Nick Hamlin | Mar 1, 2024 | Syndicated blog

DbLocalizationProvider v8.0 Released

I’m pleased to announce that Localization Provider v8.0 is finally out.

valdis | Feb 28, 2024 | Syndicated blog

Epinova DXP deployment extension – With Octopus deploy

Example how you can use Epinova DXP deployment extension in Octopus deployment.

Ove Lartelius | Feb 28, 2024 | Syndicated blog

Identify Azure web app instance id's for an Optimizely CMS site

When running Optimizely CMS in Azure, you will be using an instance bound cloud license. What instances are counted, and how can you check them? Le...

Tomas Hensrud Gulla | Feb 27, 2024 | Syndicated blog

Introducing Image Transformer - AI Assistant for Optimizely

We've got something super cool to share with you, and it's all about giving your images a fresh spin. Image Transformer, the latest feature from ou...

Luc Gosso (MVP) | Feb 26, 2024 | Syndicated blog