---
title: Deployment types reference for docs contributors
description: Reference for docs contributors on Elastic's deployment types: what they are, the stack components and flavors available on each, and where user-facing tasks differ across them.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6745/contribute-docs/how-to/deployment-types/about
---

# Deployment types reference for docs contributors
Deployment types define the supported ways to provision and run the Elastic Stack across different infrastructures and platforms: where and how to deploy.
- Deployment types are independent of [Elastic Solutions](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6745/solutions) (Search, Security, Observability). Solutions focus on use cases and functionality. Deployment types focus on infrastructure, lifecycle, and operational model.
- Some deployment types automate parts of the platform and Elastic Stack lifecycle.
- Not all deployment types allow deploying every stack component.

This page provides a lightweight overview of the deployment types, how they relate to Elastic Stack components and flavors, and a primer on where the same task can require different steps on different deployment types.

## The deployment types

The supported deployment types differ by where the Elastic Stack runs and how much of the platform Elastic operates.

| Deployment type                   | Where and how to deploy                                                           |
|-----------------------------------|-----------------------------------------------------------------------------------|
| Self-managed                      | On your own premises, hardware, VMs, or cloud VMs with no orchestration           |
| Elastic Cloud Hosted (ECH)        | On Elastic Cloud (SaaS, platform handled by Elastic)                              |
| Elastic Cloud Serverless          | On Elastic Cloud, fully managed (platform and stack lifecycle handled by Elastic) |
| Elastic Cloud Enterprise (ECE)    | Self-managed orchestrator similar to ECH, but owned by you                        |
| Elastic Cloud on Kubernetes (ECK) | On Kubernetes                                                                     |

For a user-facing overview, refer to [Deployment options](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6745/get-started/deployment-options). For the full user-facing deployment documentation, refer to [Deploy and manage](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6745/deploy-manage).

### Deployments in detail

Review the following sections to learn the basics of each deployment type, and what's distinctive about it.
<dropdown title="Self-managed">
  Users own the platform and the Elastic Stack, with no orchestration or automation. Installation, configuration, and upgrades are all manual. In this context, the term "cluster" is used more often than "deployment", even though components other than Elasticsearch are not part of a cluster directly.
</dropdown>

<dropdown title="Elastic Cloud Hosted (ECH)">
  Elastic's SaaS offering: Elastic operates the platform, users own their deployments. Deployments are discrete instances of the Elastic Stack (such as an Elasticsearch cluster + Kibana + Integrations Server) that are provisioned through the Elastic Cloud Console or API, using hardware profiles and Elasticsearch architectures offered by Elastic.
  - **Configuration**: Partly automated (for example, communication between components). Some settings aren't user-configurable. Keystore settings, user settings, bundles, and plugins use higher-level abstractions.
  - **Platform features**: Automatic snapshots, one-click upgrades, autoscaling, and private connectivity.
  ECH is not a fully managed service. Users retain significant responsibility for their deployment.ECH is hosted on Elastic Cloud, which is a common platform that it shares with Serverless and certain services offered through [cloud connect](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6745/deploy-manage/cloud-connect). This means that some configurations can be managed centrally, and then shared between ECH deployments and Serverless projects. Common areas include, but are not limited to, user management, network security, and billing.
</dropdown>

<dropdown title="Elastic Cloud Enterprise (ECE)">
  The self-managed version of the ECH platform, built on the same software. ECE lets organizations offer an ECH-like experience on their own infrastructure.Not all ECH features are available in ECE: plugins, bundles, private links, and agentless integrations differ or are ECH-only. Unlike ECH, where the platform layer is Elastic SRE's responsibility and isn't documented, ECE platform administration is the customer's responsibility and is fully documented.
</dropdown>

<dropdown title="Elastic Cloud on Kubernetes (ECK)">
  A self-managed orchestrator that deploys Elastic Stack components on Kubernetes, with no platform UI similar to ECH or ECE. There are almost no restrictions on configuration flexibility, though mechanisms are adapted to Kubernetes: files are added through volumes and volume mounts; plugins are added through init containers.Connectivity, authentication, and authorization between components are applied automatically by the operator but can be customized.
</dropdown>

<dropdown title="Elastic Cloud Serverless">
  An evolution of ECH on the same platform, aimed at being a fully managed version of Elasticsearch and Kibana. Users interact with Elastic Cloud Serverless through "projects" rather than deployments.Compared to ECH orchestration:
  - Some things are **automated / managed**: scaling, server security
  - Some things are **opinionated**: cross project user management only
  - Some things are **limited**: no custom plugins or bundles
  - Some things are **not yet available** (but planned): no user-controlled snapshot/restore, BYOK (++)
  Serverless is hosted on Elastic Cloud, which is a common platform that it shares with ECH and certain services offered through [cloud connect](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6745/deploy-manage/cloud-connect). This means that some configurations can be managed centrally, and then shared between ECH deployments and Serverless projects. Common areas include, but are not limited to, user management, network security, and billing.
</dropdown>

<warning>
  Some people refer to everything not hosted on Elastic Cloud as "self-managed" (grouping ECK, ECE, and self-managed together). **Don't use this grouping in our docs.** ECK, ECE, and self-managed differ in meaningful ways that the grouping obscures. Always name the specific deployment type.
</warning>


## Deployments and the stack

The Elastic Stack has two flavors:
- **Versioned stack**: Elastic Stack products released on a single cadence with a shared versioning pattern, designed to work tightly together based on a compatibility matrix. Often referred to as just "the stack."
- **Serverless**: Managed, unversioned, continuously delivered equivalents of some Elastic Stack products, hosted by Elastic. Only Elasticsearch, Kibana, and Fleet Server have a Serverless equivalent today.

Some versioned and Serverless products work together. For example, versioned Logstash or Elastic Agent can send data to Serverless Elasticsearch.
In other cases, versioned Elastic Stack components deployed on a particular orchestrator can work together with components deployed by other means. For example, you can manually deploy Logstash, or deploy it with Elastic Cloud on Kubernetes, and have it send data to Elasticsearch deployed on ECE.
Highly orchestrated deployments of the versioned stack, such as ECH and ECE, and managed versions of the stack (Elastic Cloud Serverless), concentrate on core and server-side components. Client-side components (which usually feed data to the stack) don't need to be hosted on the same platform to perform their functions.

| Deployment type          | Stack components available                                                                     | Stack flavor    |
|--------------------------|------------------------------------------------------------------------------------------------|-----------------|
| Self-managed             | All components (manual install)                                                                | Versioned stack |
| ECH                      | Elasticsearch, Kibana, Integrations Server (Fleet Server + APM Server), agentless integrations | Versioned stack |
| ECE                      | Same as ECH                                                                                    | Versioned stack |
| ECK                      | All components                                                                                 | Versioned stack |
| Elastic Cloud Serverless | Elasticsearch, Kibana, Fleet Server (Serverless versions)                                      | Serverless      |

<tip>
  - `serverless` can appear in both the Stack/Serverless dimension and the Deployment dimension. This is because Serverless acts as both a "version" or "flavor" of the stack (like `stack`), and a unique deployment type with specialized management processes (like `ece` or `eck`).
  - The versioned Elastic Stack (`stack`) can be deployed across ECE, ECK, ECH, and self-managed clusters. When deployment, configuration, or management tasks are available or consistent across these deployment types (often because they're built into Elasticsearch), use `stack` in the Stack/Serverless dimension rather than specifying each deployment type individually.
  For details, refer to [Dimensions](/elastic/docs-content/pull/6745/contribute-docs/how-to/cumulative-docs/guidelines#dimensions).
</tip>


## Configuration tasks across deployment types

Even when a task is conceptually the same, the steps often differ across deployment types.
*In general*, **feature usage** is usually the **same** across deployment types (with some exceptions for Serverless), while **admin tasks** are usually **different** or have exceptions.

| Task                                                        | Same or different?                                                                                                                   |
|-------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|
| Configure an `elasticsearch.yml` setting                    | **Different.** Steps depend on deployment type, because the configuration file isn't directly available in orchestrated deployments. |
| Configure something in the Kibana UI                        | **Same** across deployment types (exceptions for Serverless).                                                                        |
| Configure an Elasticsearch cluster-level or dynamic setting | **Same** across deployment types, because it's done through the Elasticsearch API (exceptions for Serverless).                       |
| Add a config file to your Elasticsearch instance            | **Different.** Steps depend on deployment type.                                                                                      |
| Install an Elastic Agent to send data to Elasticsearch      | **Same** across deployment types. Action is performed on clients.                                                                    |
| Integrate a custom application using client libraries       | **Same** across deployment types. Action is performed in client code.                                                                |
| Configure ILM policies                                      | **Same** across deployment types; unavailable in Serverless.                                                                         |


## Next steps

Now that you know the basics of each deployment type, you can learn more about [how to document features that vary by deployment type](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6745/contribute-docs/how-to/deployment-types/strategies).