CD, CM, CE, Oh My!

Recently a coworker asked me a question:

Hey Ed, the client is referring to their "CE" environment... what's a CE environment?

I'm sure everyone reading this knows what CD and CM mean, but CE was a new one to me as well. I checked and was able to confirm that CE stood for "Content Editing" and was being used by the client as the same thing as CM.

However, in this context "CE" is not an environment but a server role. Environments are groups of servers that comprise an entire system. Servers within an environment have specific roles they are responsible for.

I'm sure this is not the first time someone has asked what a specific environment/server acronym stood for. Here's a list of common environment/server names/acronyms you'll probably see in Sitecore development (N.B. odds are your architecture does not have all of these, and that's normal):

Server roles:

  • CD: Content delivery servers face the public Internet and are the servers that site visitors access to see the site. Most sites have more than one of these servers. Usually these have a URL like "".
  • Front end: Same as CD, though "front end" also refers to HTML/CSS/JavaScript technology (a "front end developer" is a dev who specializes in HTML/CSS/JavaScript). Because of this ambiguity, you should probably avoid using this term in this way.
  • CM: Content management servers are where authors, editors, and administrators access the Sitecore backend (i.e. /sitecore). These servers are usually hidden from the public Internet by a firewall. These servers usually have URLs like "" or "".
  • CE: Content editing (or content entry) servers are (usually) synonymous with CM servers.
  • Backend/Authoring: Same as CM
  • Search/Solr/Coveo: Search servers are where the search service lives. Often times this server might be called for the name of the search technology (e.g. Solr, Coveo). These servers are usually hidden from the public Internet by a firewall.
  • DB: Database servers are where - surprise - the database lives. These servers are usually hidden from the public Internet by a firewall.
  • xConnect: xConnect is Sitecore's more modern analytics platform. Modern Sitecore installations can have several different xConnect servers (e.g. "xc-search", "xc-collect", "xc-refdata"). These should all have names prefixed with "xc". To make things complicated, the various xConnect roles can be combined on servers in many different ways; check the roles configuration to check what each server is responsible for. The "collection" server must be open to the public web, but the other servers are usually hidden from the public Internet by a firewall.
  • OMS/DMS/xDB/Analytics: Database servers that host the analytics databases. (OMS and DMS are names of Sitecore's older analytics tools. Hopefully you won't see these anymore). These servers are usually hidden from the public Internet by a firewall.
  • App/API: Servers that host various other apps for a site. Sometimes these servers host the search provider, sometimes they host custom APIs, sometimes many things. These may be open to the public Internet or may not be, depending on what they are actually doing.
  • LB: Load balancers are dedicated appliances, servers, or cloud entities that manage spreading load between more than one CD server.
  • WAF (Web Application Firewall): Azure PaaS environments often have a Web Application Firewall (FWIW I've rarely seen this abbreviated to WAF) that controls access among servers (e.g. allowing CD servers to be accessed by the public Internet, but locking down CM servers to only the CD server and the IP address whitelist).
    • I am not an Azure PaaS master, so I'm sure there are some important Azure resources I am neglecting. However, the firewall is the one I hear about most often.


  • Production/Live: What the public sees. Don't mess this up.
  • Staging: Servers that mimic production but are used as the ultimate testing location before production. This environment should be as close to production as possible in terms of architecture.
    • N.B. Azure PaaS uses the names "Production" and "Staging" to denote swappable web roles. In my experience, different companies handle these roles differently. Consult your coworkers/managers/IT/clients to make sure you know your terms.
  • DR: Disaster recovery servers are hot-swappable servers that mirror production servers but are hosted at a separate location. Usually "DR" is used as a prefix (e.g. "DR-CM" would be the disaster recovery CM server). Often the DR environment has fewer/smaller servers than production to save money (think of the "donut" spare tire vs. a full-size spare tire).
  • UAT: "User Acceptance Testing" (often pronounced "you-at" or spelled out "you-ay-tee") environment exists for the stakeholders to experience tested work and use the features they asked for. This environment should be fairly stable (no auto-deploy).
  • QA: "Quality Assurance" environment is where QA engineers (you do have a dedicated QA team, yes?) test developed work. This environment often has a lot of extra and test content. This environment should be fairly stable (no auto-deploy).
  • Dev/Support/[ProjectName]: Depending on the project and team, there may be one or many environments at this level, named for the ongoing development effort. The most common name is "Dev". "Support" may be used for ongoing support development. When multiple projects are being developed at the same time, these environments are named for the project being developed on.
  • Local: Works on my machine ;).

Important note: Clients may have unique terminology or architecture for their environments. I had one client where their "QA server" functioned as a CM server. Be sure to clarify with your client the actual use of all servers/environments.

This isn't a complete list, because I'm sure some teams have some esoteric or rare environments or servers that I'm not aware of. However, if I am missing something common, let me know and I'll update this list.

EDIT: Fixed a typo and added "content entry" as a meaning for CE. Thanks Chris and Sean!

EDIT 2: Added sample URLs and an important note about nonstandard nomenclature, fixed another typo, and updated the differences between environments and servers. Thanks Kyle for prompting me to add more details!