docs-builder
Loading

Applies to

Starting with Elastic Stack 9.0, ECE 4.0, and ECK 3.0, documentation follows a cumulative approach: instead of creating separate pages for each product and release, we update a single page with product- and version-specific details over time.

To support this, source files use a tagging system to indicate:

  • Which Elastic products and deployment models the content applies to.
  • When a feature changes state relative to the base version.

This is what the applies_to metadata is for. It can be used at the page, section, or inline level to specify applicability with precision.

Note

For detailed guidance, refer to Write cumulative documentation.

The applies_to metadata supports an exhaustive list of keys.

When you write or edit documentation, only specify the keys that apply to that content. Each key accepts values with the following syntax:

<key>: <lifecycle> [version], <lifecycle> [version], ...

Where:

  • The lifecycle is mandatory.
  • The version is optional.

Page level annotations are added in the YAML frontmatter, starting with the applies_to key and following the key-value reference. For example:

---
applies_to:
  stack: ga
  deployment:
    ece: ga
---

For more examples, refer to Page annotation examples.

Important

All documentation pages must include an applies_to tag in the YAML frontmatter.

A header can be followed by an {applies_to} directive which contextualizes the applicability of the section further.

Section-level {applies_to} directives require triple backticks because their content is literal. Refer to Syntax guide > Literal directives for more information.

```{applies_to}
stack: ga 9.1
```

To play even better with Markdown editors the following is also supported:

```yaml {applies_to}
stack: ga 9.1
```

This allows the YAML inside the {applies_to} directive to be fully highlighted.

For more examples, refer to Section annotation examples.

Note

Section-level {applies_to} directives must be preceded by a heading directly.

You can add inline applies annotations to any line using the following syntax:

This can live inline {applies_to}`section: <life-cycle> [version]`

A specialized {preview} role exists to quickly mark something as a technical preview. It takes a required version number as an argument.

Property {preview}`<version>`
:   definition body

For more examples, refer to Inline annotation examples.

Use the following key-value reference to find the appropriate key and value for your applicability statements.

applies_to accepts the following keys in this structure.

Note

The product key and its subkeys are used to indicate feature availability and applicability. The similarly named products frontmatter field is used to drive elastic.co search filters.

applies_to accepts the following lifecycle states:

  • preview
  • beta
  • ga
  • deprecated
  • removed
  • unavailable

applies_to accepts the following version formats:

  • Major.Minor
  • Major.Minor.Patch

Regardless of the version format used in the source file, the version number is always rendered in the Major.Minor.Patch format.

Note

Automatic Version Sorting: When you specify multiple versions for the same product, the build system automatically sorts them in descending order (highest version first) regardless of the order you write them in the source file. For example, stack: ga 8.18.6, ga 9.1.2, ga 8.19.2, ga 9.0.6 will be displayed as stack: ga 9.1.2, ga 9.0.6, ga 8.19.2, ga 8.18.6. Items without versions (like ga without a version or all) are sorted last.

Versioned products require a version tag to be used with the lifecycle tag:

applies_to:
  stack: preview 9.1, ga 9.4
  deployment:
    ece: deprecated 9.2, removed 9.8

Unversioned products use lifecycle tags without a version:

applies_to:
  serverless:
    elasticsearch: beta
    observability: removed

Applies To Model

The previous model is projected to the following structured YAML.

applies_to badges are displayed in a consistent order regardless of how they appear in your source files. This ensures users always see badges in a predictable hierarchy:

  1. Stack - Elastic Stack
  2. Serverless - Elastic Cloud Serverless offerings
  3. Deployment - Deployment options (ECH, ECK, ECE, Self-Managed)
  4. ProductApplicability - Specialized tools and agents (ECCTL, Curator, EDOT, APM Agents)
  5. Product (generic) - Generic product applicability

Within the ProductApplicability category, EDOT and APM Agent items are sorted alphabetically for better scanning.

Note

Inline applies annotations are rendered in the order they appear in the source file.