Instances and Environments with the Sitecore ASP.NET CMS

This blog post explains the concepts of Sitecore instances, which are individual installations of the Sitecore ASP.NET web Content Management System (CMS), and environments, which are groups of one or more Sitecore instances that serve specific functions. You can learn more about the terminology used in this blog post from the resources linked at the bottom of this page.

An Sitecore instance is a single installation of the Sitecore ASP.NET CMS. Each Sitecore instance requires a number of components:

  • An IIS web site, including binding criteria such as hostname or DNS entry to bind HTTP requests to that site
  • An IIS application pool to manage the ASP.NET application in the IIS web site
  • A document root subdirectory for the IIS web site to host; this subdirectory contains the Sitecore application files
  • A supporting file system for logs and other data that does not belong under the document root subdirectory, including the Sitecore license file

You can install any number of Sitecore instances on a single physical server, but each consumes some machine resources and requires a separate Sitecore license (unless you have a written agreement from Sitecore that overrides this requirement).

A Sitecore environment consists of a single instance or some number of load-balanced Sitecore instances. While multiple instances on a server can share file systems, you would have to resolve the licensing issue, because the instances would share a license file by default. If multiple instances share file systems, you may encounter issues if those instances concurrently write to those file systems, such as the media cache, the Sitecore logs, or the Lucene indexes. In general, Sitecore recommends separate file systems for each instance.

By default, each environment provides both content management (CM, for CMS users) and content delivery (CD, for visitors to the published sites) facilities. A typical organization creates a number of instances, with some dedicated to development, some for various forms of testing, some for production content management, some for production content delivery (CD, for visitors to the published sites), some for evaluating upgrades, and some for other projects. For organizations that load-balance the production content management environment, an organization can dedicate an instance solely to publishing, or include that instance in the load balance that services the CMS user population.

You can host any number of logical web sites on a single Sitecore instance and hence in a single Sitecore environment. You typically use the IIS management console to bind the DNS entries and host names associated with each managed site to the IIS site, and then use the /configuration/sitecore/sites/site elements in the Web.config file to specify properties for each. You can use a single CM environment to manage the instances and deploy them to separate content delivery environments, or you can use a single CD environment to deliver those managed sites as well.


  • I have several questions on MongoDb on-prem: 1) What is the typical bandwidth of the DMS pushing data to a Mongo Db; trying to determine sizing of needs per our environment. 2) You article points to separate Mongo instances (does this mean servers?) to track session data separate from DMS or xDB data. Is this needed? 3) Your article recommends using a seperate Mongo instance in each cluster. Is cluster the same as environment? (ie. a set of servers serving up a Sitecore instance) So, if we had two environments; we would need to double our MongoDb purchase?

  • Hi Jeff - Let me see if I can answer your questions for you...  1.  Looking at some testing we have done with a live site connected to the xDB in the cloud, we are seeing about 2.6kb per interaction (an interaction being a visit).  2..  Let's take this as two different database zones.  The first being the session db, which can either be InProc (default and used for a single CD), MongoDB or SQL Server (multiple CDs sharing a session server).  The session server allows for localized collection at the point of delivery.  You should have a session state server located at each geographically dispersed web farm.  The second is the collection database or xDB.  This is MongoDB and there is only one in the system.  Ideally this one instance of MongoDB is actually a minimum of 3 physical servers run as a replica set for high availability.  3.  For the session servers, there should be a session server associated with each web farm. It can be either MongoDB or SQL Server.  For on-premise, I would recommend the following (not including the session state server(s)) to be located all in the same datacenter for collection and reporting:  - Minimum of 3 MongoDB servers configured as a replica set - 1 SQL Server for the reporting database - 1 Server running SOLR for indexing - 1 Server for running aggregation and reporting services (this is a Sitecore instance)  Hope that helps.  Dan Brown Head of Technical Consulting Sitecore Corporation

  • Can it be hosted on linux/Unix server?

  • @Mit: If you mean CMS, Sitecore depends on the Windows/IIS/ASP.NET software stack, though things might change in the future of ASP.NET. If you mean Mongo, assuming ASP.NET itself has no issues with alternate underlying platforms for Mongo, I don't see why Sitecore would. I would have to ask someone else for certainty.

  • Jonh, MongoDb can run on many different platforms. And, according to their architects, there is virtually no performance difference between Linux and Microsoft Server.

  • Hi I have a question. If a Sitecore implementation has 3 instances (Dev, Test and Prod) is there an auto refresh facility? Meaning is there an option to refresh the Dev with Prod data every 2-3 months?? If this is not there in SiteCore right now, is it possible to do this if a client needs it?

  • @Mona: For content in the Sitecore Master database, you can schedule publishing at any frequency, where publishing clears caches as needed. You can can also use a workflow action to publish, publish manually, use APIs, and so forth. You can configure publishing to trigger file system synchronization operations using any Windows technology. Guide.aspx

  • We currently have a 6.5 version that I'm trying to separate out between CM and CD.  Previously both were set up on the same IIS site for our development server.  I changed that to be two separate sites (with different paths) on the same IIS/Server, and each have their own app pool.  When I turn the Eventqueue on via the ScalabilitySettings.config and try to publish, however, I then get an SQLException Invalid column name 'Stamp'.  If I leave it disabled, I'm able to publish but the CD does not show the change until I turn  on and off the app pools.  So am wondering if this is considered to be multi-instance due to different app pools and different paths even though they are both dealing with the same content/db's?

  • Hi,

    I am new to Sitecore and our org. has recently published a new site on Sitecore. My question is - How many  IIS Websites can be hosted on a single server, single Sitecore instance and single license, of Sitecore.