Documenting deployment types

Elastic ships the same products across very different operational models. The same task, such as changing a setting, configuring a feature, or creating a snapshot of a cluster, can require completely different workflows depending on how the user deployed Elastic.

This page is the entry point for writing and reviewing documentation that spans deployment types. It covers what the deployment types are, how to recognize when content is deployment-sensitive, and where to find the patterns we use to handle that variation.

• Signals: how to recognize deployment context — signs that a doc, PR, or procedure is about a specific deployment type
• Strategies for deployment-type variation — choose an editorial approach based on how much content varies
• Review checklist — symptoms to look for in PRs and audits

• Write cumulative documentation — how to tag content with applies_to
• Deployment options — reader-facing overview
• Deploy and manage — full reader-facing deployment documentation

Deployment types differ mainly in who operates the platform and how much of the stack lifecycle is automated. For cues that signal a piece of content is rooted in a specific deployment type, refer to Signals: how to recognize deployment context.

ECH, ECE, ECK, and self-managed run the versioned flavor of the Elastic Stack — they share the same versioning and compatibility model, though each orchestrator exposes a different subset of stack configuration and features. Elastic Cloud Serverless runs the serverless flavor — unversioned and continuously delivered. For how flavors map to applies_to tags, refer to Dimensions.

Not every component is available on every deployment type. For the component matrix, refer to Deployment options.

Sometimes, people refer to everything not hosted on Elastic Cloud as "self-managed" (meaning self-managed, ECE, and ECK together). Don't use this in published documentation. Self-managed, ECE, and ECK differ in meaningful ways that the grouping obscures. Always name the specific deployment type.

serverless appears in both the Stack/Serverless and Deployment dimensions of applies_to. This is because Serverless acts as both:

• A flavor of the Elastic Stack — unversioned, continuously delivered, behaves differently from the versioned Elastic Stack
• A deployment type — projects are created, scaled, and managed differently from any other deployment type

When tagging, use serverless in whichever dimension matches your page's primary focus. For more on dimension choice, refer to Dimensions.

The most common writer mistake is assuming a task that's universal in concept is also universal in procedure. It usually isn't.

When writing or reviewing a page, ask one question: how deployment-sensitive is this content?

The sensitivity level determines which strategy to apply. The classification itself is the most important review skill: if you can't name the sensitivity, you can't choose the right approach.