Loading

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 (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 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. For the full user-facing deployment documentation, refer to Deploy and manage.

Review the following sections to learn the basics of each deployment type, and what's distinctive about it.

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.

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. 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.

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.

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.

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. 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.

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.

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 - Where stack flavor and deployment type collide
  • 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.

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.

Now that you know the basics of each deployment type, you can learn more about how to document features that vary by deployment type.