Vulnerability in EPiServer.Forms

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
Stop Managing Humans in Your CMS

Too many times, a content management system becomes a people management system. Meaning, an organization uses the CMS to manage all the information...

Deane Barker | Nov 30, 2023

A day in the life of an Optimizely Developer - Optimizely CMS 12: The advantages and considerations when exploring an upgrade

GRAHAM CARR - LEAD .NET DEVELOPER, 28 Nov 2023 In 2022, Optimizely released CMS 12 as part of its ongoing evolution of the platform to help provide...

Graham Carr | Nov 28, 2023

A day in the life of an Optimizely Developer - OptiUKNorth Meetup January 2024

It's time for another UK North Optimizely meet up! After the success of the last one, Ibrar Hussain (26) and Paul Gruffydd (Kin + Carta) will be...

Graham Carr | Nov 28, 2023

Publish content to Optimizely CMS using a custom GPT from OpenAI 🤖

Do you find the traditional editor interface complicated and cluttered? Would you like an editorial AI assistant you can chat with? You can!

Tomas Hensrud Gulla | Nov 28, 2023 | Syndicated blog