When Elastic Cloud on Kubernetes fits and when virtual machines fit better
Choose ECK when your team already runs Kubernetes well and wants the Elastic components managed as declared resources. Choose packages on virtual machines when no platform team owns a Kubernetes cluster for security tooling, or when the team wants fewer moving parts to patch. Either path can run the same Elastic Security features, so the deciding factors are operational skill, existing platform ownership and the subscription tier you buy. The Elastic Cloud on Kubernetes (ECK) operator, documented in the Elastic Cloud on Kubernetes guide, automates the lifecycle of Elasticsearch, Kibana, Elastic Agent and Logstash on your cluster. That automation is worth the most when someone on your team already operates Kubernetes upgrades, storage classes and certificate rotation, because ECK adds a control layer on top of those tasks rather than replacing them.
The tier decision is separate from the deployment decision. ECK is offered in Basic and Enterprise tiers, and the Elastic Security features this page discusses depend on that tier, not on whether the stack runs in pods or on hosts. Per Elastic's self-managed subscriptions page, endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise, while Platinum is no longer sold to new customers. Confirm the current tier of each feature on the Elastic subscriptions page before you cost either path, and ask your Elastic representative to confirm which tier applies to ECK deployments in your version.
Before you decide, check three things in your environment. First, whether a Kubernetes platform team already patches the control plane on a supported schedule, since the Kubernetes release lines and version skew rules apply to any cluster hosting the stack. Second, whether your storage tiers for hot, warm and cold data map cleanly to persistent volumes you can back up. Third, whether the people who will respond to node failures can work with Elasticsearch node roles and a three-master-eligible-node quorum. If the answer to any of these is no, packages on virtual machines usually leave a smaller surface to operate. Ask any implementation partner to write down who owns each of these tasks in the scope before work begins.
Elastic Cloud on Kubernetes vs VMs across the factors that decide the choice
This table compares running a self-managed Elastic Security stack through the ECK operator on Kubernetes against installing Elasticsearch packages on virtual machines, across architecture, availability, upgrades, backups, licensing and skills. Read each row as the work your team takes on under each path, and check the items marked for confirmation against Elastic and your own environment before you choose.
| Factor | ECK on Kubernetes | Elasticsearch on virtual machines |
|---|---|---|
| Architecture | ECK runs Elasticsearch, Kibana, Elastic Agent and Logstash as Kubernetes resources managed by an operator | Each Elasticsearch, Kibana and Logstash service is installed and configured directly on the host operating system |
| Node roles and storage tiers | Node roles and hot, warm, cold and frozen tiers are declared per node set, with storage bound through Kubernetes volumes | Node roles are set in each node's configuration file, and tiering depends on how you provision disks on each host |
| Availability | A highly available cluster still needs at least three master-eligible nodes, and the Kubernetes control plane adds its own availability requirements | A highly available cluster also needs at least three master-eligible nodes, with failure domains set by your hypervisor and network layout |
| Upgrades | Elastic and Kubernetes versions are both in scope, and Kubernetes minor upgrades must follow its version skew policy | Elastic package upgrades are applied per host, so rolling order and rollback steps are written by your team |
| Backups | Snapshot repositories must be configured for Elasticsearch, and Kubernetes backups of the operator's resources are a separate concern to confirm | Snapshot repositories are configured for Elasticsearch, and the host image and configuration files need their own backup plan |
| Licensing tier availability | ECK is offered in Basic and Enterprise tiers, so confirm which Elastic Security features your tier includes before design | Elastic Security features follow the same Basic, Enterprise and Platinum split, and Platinum is no longer sold to new customers |
| Skills assumed | Kubernetes administration, RBAC, storage classes and operator lifecycle, alongside Elasticsearch operations | Linux administration, configuration management and Elasticsearch operations, with fewer Kubernetes concepts to learn |
| Infrastructure dependency | A working Kubernetes cluster with etcd backup and control plane high availability, which you must confirm exists in your environment | Virtual machines, load balancing and host-level monitoring, which many teams already run for other platforms |
How Elastic Cloud on Kubernetes lays out nodes compared with VM packages
Running a self-managed Elastic Security stack on Kubernetes with ECK moves node lifecycle into custom resources and the cluster beneath them. On virtual machines, the same roles are laid out by hand across package-managed hosts. The cards below set out each layer that has to be designed, staffed and monitored on either path.
ECK operator and custom resources
ECK is Elastic's Kubernetes operator for Elasticsearch, Kibana, Elastic Agent, Logstash and Beats, and it reconciles the state you declare in custom resources. Node sets, versions and storage claims live in those resources, so changes are reviewed as manifests rather than run as package upgrades on each host. Check which ECK features your subscription tier covers, since ECK is offered in Basic and Enterprise tiers, and confirm the ECK version you run against the Elastic Stack version you plan to deploy.
Kubernetes control plane and etcd
With ECK, the cluster your Elasticsearch nodes run on is a dependency you must operate as well. Its control plane stores cluster state in etcd, and etcd needs an odd number of members, a backup plan and a tested restore path using etcdctl snapshot save and etcdutl. Losing etcd quorum affects the operator and the scheduling of Elastic pods, so ask who on your team owns this layer before you commit to ECK.
Highly available Kubernetes control plane
Kubernetes high availability with a kubeadm-style setup requires at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. Choose between a stacked etcd topology, where etcd shares the control plane nodes, and an external etcd cluster. Two control plane nodes do not give you a quorum to survive a node loss, so size this layer before you size Elasticsearch. Confirm whether your managed Kubernetes service handles these parts for you.
Elasticsearch node roles and tiers
Elasticsearch separates work by node role, including master-eligible, data (with hot, warm, cold and frozen tiers), ingest, machine learning, transform, remote cluster client and coordinating-only. A highly available cluster needs at least three master-eligible nodes. In ECK, each role is a node set in the manifest, so role changes are declarative. On VMs, each role is a configuration file on a host you maintain yourself. Decide your tier layout for hot security data before choosing either path.
VM host layer and package-managed nodes
On virtual machines, each Elasticsearch node is a host with an operating system, a package install, JVM settings, disk layout and patching that your team controls directly. There is no operator reconciling drift, so configuration management and inventory do the job ECK does for you. Storage tiers map to specific disks or volumes you attach and monitor. Check who patches the hosts, how snapshots are taken, and how a failed node is rebuilt and rejoined.
Skills each layer assumes
ECK assumes working knowledge of Kubernetes objects, RBAC, storage classes, persistent volume claims and upgrade sequencing, along with Elastic node roles. The VM path assumes Linux administration, configuration management and Elastic packaging. Most teams underestimate the Kubernetes skills needed to keep the stack healthy during a control plane upgrade. Ask your implementation partner to name who will hold each skill after go-live, and whether that person is on call.
What the ECK operator automates and what it leaves to your team
The ECK operator takes over the Elastic-specific lifecycle work. You declare an Elasticsearch cluster, Kibana, Elastic Agent, Logstash or Beats as a Kubernetes custom resource, and the operator reconciles the running state toward that declaration: it creates the pods and services, wires Kibana to the cluster, and manages Elasticsearch node roles and rolling changes. Elastic's Elastic Cloud on Kubernetes documentation sets out which components are covered and which tier features apply. Confirm in that documentation whether a given feature, such as a specific Enterprise capability, is available under your subscription before you design around it. The operator does not replace the platform team's Kubernetes duties, and it does not manage the cluster beneath it.
Four responsibilities stay with your team. First, Kubernetes control plane upgrades must follow the version skew policy, with kube-apiserver moved one minor version at a time before the other control plane components and kubelets. Second, the etcd datastore needs a tested backup plan: take snapshots with etcdctl snapshot save and restore with etcdutl, and rehearse the restore, because a snapshot that has never been restored is an unverified control. Third, storage classes decide whether Elasticsearch data nodes get durable, performant volumes, so your team must set the classes that back hot, warm and cold data. Fourth, RBAC and secrets are yours to design. Kubernetes stores Secrets unencrypted in etcd by default, so you must enable encryption at rest for etcd or move sensitive values to an external store through the Secrets Store CSI Driver. Elasticsearch passwords, certificates and API keys live in Secrets, so this gap affects the whole SIEM stack.
Before committing, ask a practical question: who on your team can restore etcd, rotate a compromised secret and upgrade the control plane without the Elastic workload being the first thing to break. If the answer is unclear, the VM path keeps those duties closer to the Elasticsearch packages you already operate, while the operator path moves them into the Kubernetes layer. Illustrative example: a team that has never restored etcd should rehearse that restore in a non-production cluster before the first Elastic deployment goes live.
Which path fits each team situation
ECK is usually the better fit when a team already runs production Kubernetes with an established upgrade process, namespace and RBAC model, and monitoring. The operator turns Elasticsearch, Kibana, Elastic Agent and Beats into custom resources, so the same change pipeline and review habits can manage the security stack. Virtual machines are safer when the Kubernetes platform is itself new, shared across many unrelated workloads, or run by a team that has not yet agreed on who owns cluster upgrades.
- Shared control plane risk: A SIEM cluster competing with application workloads for nodes, storage and upgrade windows needs dedicated node pools and clear ownership.
- Storage classes: Confirm that your persistent volume setup offers the disk performance and snapshot behavior the indexing load needs.
- Upgrade coupling: Kubernetes minor version changes and ECK operator changes both affect the stack, so the cadence must be planned together.
- Secrets handling: Kubernetes Secrets are stored unencrypted in etcd by default, so confirm encryption at rest and external secret stores before loading Elastic credentials.
- Support boundaries: Confirm with Elastic which tier and support terms cover ECK in your environment.
Confirm your cluster's ownership model, upgrade cadence and storage classes with your platform team before choosing ECK.
Virtual machines are usually the safer path when the team has little Kubernetes operating experience. Packaged Elasticsearch on VMs keeps the failure modes familiar: service units, disk, memory and JVM settings are managed directly. The cost is that the team must still own every upgrade, certificate rotation and node addition by hand. ECK is worth considering only when a platform or SRE group will own the cluster long term and can staff that skill.
- Learning curve: Operating the control plane, networking, storage classes and the operator alongside Elastic at once is a large skill set for a small team.
- Failure diagnosis: Problems can sit in the operator, the Kubernetes scheduler or the Elastic node, so on-call engineers need to read all three layers.
- Recurring work: Kubernetes releases come about three times per year, and each one needs a check against the ECK version you run.
- Backups and restores: Confirm who runs snapshot repositories and restore drills, since the operator does not replace that discipline.
- Training: Price the training and practice time as an internal cost, not a line item in the license.
Confirm who on the team can diagnose a failed pod and a failed Elasticsearch node before you pick the Kubernetes path.
Either path can run in an isolated network, but the packaging and image supply chain decide the work. ECK needs container images, the operator and Kubernetes components to be mirrored into the enclave and kept current. VM installs need OS packages and Elastic artifacts moved in the same way. Choose ECK here only if your cluster already sits inside the enclave and your registry process can handle operator and image updates on a schedule you control.
- Image mirroring: Confirm how operator and Elastic images are pulled, scanned and promoted inside the restricted network.
- Admission and pod security: Confirm the Pod Security Standards level your cluster enforces, since the Elastic pods must fit within it.
- Air-gapped licensing: Confirm with Elastic how subscription keys and license checks behave without outbound connectivity.
- Hardening baseline: Map your CIS-based configuration checks to both the cluster and the VM hosts, and document which controls you accept.
- Access paths: Confirm how operators reach the Kubernetes API and whether break-glass access is documented.
Confirm the image supply chain and the license verification method for your enclave before you commit to either path.
Elasticsearch data nodes support hot, warm, cold and frozen tiers, and the tier design drives both hardware and operations. On VMs, each tier is a set of hosts with its own disks and roles, which is easy to see and change by hand. On ECK, each tier becomes a node set with its own storage class and resource settings in the custom resource. The ECK path is safer when tiers are defined in code and reviewed like other infrastructure, while VMs are safer when storage is specialized, such as a SAN or local disks that the cluster team cannot easily map to storage classes.
- Node roles: A highly available cluster needs at least three master-eligible nodes, so plan those separately from data tiers.
- Storage classes per tier: Confirm that hot, warm and cold volumes map to distinct storage classes with the performance you expect.
- Frozen tier dependencies: Confirm the snapshot repository and its access model before relying on frozen data.
- Growth path: Adding a tier later is a configuration change on ECK, but it is a host build on VMs, so estimate that change rate.
- Retention rules: Confirm lifecycle policies and who approves retention changes.
Confirm your retention targets, node roles and storage classes with the Elasticsearch and platform owners before you draw the tier map.
How upgrades, backups, monitoring and skills differ between the two paths
This table compares how each path handles upgrades, backups, monitoring and the skills it assumes. Read each row as a question to answer for your own team, and use the support dates in the upgrade rows to plan a release calendar before choosing.
| Area | ECK on Kubernetes | Elasticsearch on virtual machines |
|---|---|---|
| Upgrade sequence | Upgrade kube-apiserver one minor version at a time first, then controller-manager, scheduler and kubelets, under the Kubernetes version skew policy. Elastic components are then rolled by the operator. | Upgrade Elasticsearch, Kibana and Elastic Agent package by package on each host, following Elastic's upgrade order for your release line. No cluster-wide control plane is involved. |
| Kubernetes support window | Kubernetes 1.37 reaches end of life on October 28, 2027, 1.36 on June 28, 2027 and 1.35 on February 28, 2027. Plan cluster upgrades before these dates. | Not applicable to the OS or Kubernetes layer, but the host operating system has its own support lifecycle that you must track separately. |
| Elastic release lines and end of maintenance | Current lines include 9.5.5, 9.4.8 and 8.19.23. End of maintenance for the 9.x line is October 15, 2027 and for 8.x is January 15, 2027, so plan moves to 9.x before these dates. | The same Elastic release lines and end of maintenance dates apply. Confirm with Elastic which patch level your environment should target before each change window. |
| Etcd backups | Kubernetes requires a backup plan for etcd data. Take snapshots with etcdctl snapshot save and restore with etcdutl. Test restores in a non-production cluster. | Not applicable. There is no etcd layer, but cluster state and the Kubernetes API objects must be captured through your own configuration backups. |
| Elasticsearch snapshots | Configure snapshot repositories and lifecycle policies for Elasticsearch data through the operator's resources. Confirm the repository target and retention with your storage team. | Configure snapshot repositories and lifecycle policies directly against the cluster API. Confirm repository access, retention and restore tests with your storage team. |
| Monitoring the platform | Watch pod health, operator logs, persistent volume usage and the Kubernetes control plane alongside Elasticsearch node metrics. Confirm which monitoring stack your cluster already runs. | Watch systemd service state, disk and memory on each host, and Elasticsearch node metrics. Confirm alerting coverage for each host before go-live. |
| Kubernetes skills assumed | Working knowledge of Kubernetes objects, RBAC, namespaces, storage classes and the kubeadm high availability topology. Needed to operate the cluster, not only the Elastic stack. | Not required, but Linux administration, package management and service configuration must be strong in the team. Confirm the skill mix before choosing this path. |
| Linux and storage skills assumed | Node-level Linux tuning still applies to the Kubernetes worker hosts, and storage performance depends on the Kubernetes storage layer. Confirm who owns each layer. | Kernel tuning, filesystem layout, JVM heap sizing and disk management are handled directly on each host. Confirm the team has this experience. |
Which Basic and Enterprise ECK features to verify before you buy
Confirm the tier before you design anything. Elastic offers Elastic Cloud on Kubernetes in Basic and Enterprise tiers, and Elastic's subscriptions page places endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on under Enterprise. Platinum is no longer sold to new customers, so a new buyer chooses between Basic and Enterprise for self-managed work or moves to Elastic Cloud. The Enterprise line decides whether your SSO design is possible at all, because a VM deployment and an ECK deployment can both reach the same Kibana features only if the same tier covers them.
Ask Elastic for the current ECK feature matrix before you sign anything, and read it against your chosen model. Confirm three things: which features the Basic tier includes for ECK specifically, whether operator-specific capabilities such as the managed lifecycle of Elasticsearch, Kibana and Elastic Agent resources differ by tier, and whether the features your detections depend on are licensed in the same way on Kubernetes as on virtual machines. The Elastic subscriptions page is the starting point for the self-managed feature list, but the matrix for the operator is the document that answers the ECK question.
Put the answers in writing with your procurement or account contact. Record the tier name, the features in scope, the support terms that apply to the operator, and any license key handling that changes when you move a cluster between deployment models. Then run a short proof of concept on a non-production cluster to check that the features you need appear under the license you bought, because a feature that is documented for a tier can still be gated by configuration you have not yet set. This check costs little compared with rebuilding a cluster after a licensing mismatch.
The sequence to stand up either path with the same security controls
The ordered phases below show how a team builds an Elastic Security stack on Kubernetes with ECK or on virtual machines, and which controls must exist before detections go live. The sequence is the same in substance on both paths, even though the tooling at each step differs.
Confirm the Elastic release line and support window
Choose the Elastic release line before any build starts, and check its end of maintenance and end of support dates on Elastic's end of life page. The 9.x and 8.x lines carry different dates, so a stack built on the wrong line can reach end of maintenance soon after go-live. Your team decides the target version, and the implementation partner records the decision and the dates in the design document. Done means the version, the support window and the upgrade owner are written down and approved.
Size node roles and storage tiers
Map the expected log volume and retention to Elasticsearch node roles, including master-eligible, hot, warm, cold and frozen data nodes, plus ingest and machine learning nodes if you plan to use anomaly detection. A highly available cluster needs at least three master-eligible nodes, so that count is fixed in the design. On ECK, these roles appear as node set definitions in the custom resource; on virtual machines, they map to node configuration files. Done means a signed sizing sheet shows each role, its count, its storage class and the retention each tier holds.
Build the Kubernetes control plane or the virtual machine hosts
On the ECK path, your platform team builds a highly available Kubernetes control plane, usually with at least three control plane nodes behind a TCP load balancer on port 6443, and sets an etcd backup plan from day one. On the virtual machine path, the same team provisions hosts, storage, time sync and kernel settings for each Elasticsearch role. Done means the control plane or host fleet passes its health checks and a test restore of etcd data, or a test restore of a host snapshot, is recorded.
Configure TLS, realms and role-based access
Enable TLS for transport and HTTP traffic, configure the file and native realms or your directory integration, and define role-based access for analysts, administrators and the service accounts that ship logs. Single sign-on through SAML or OpenID Connect and field- or document-level security are paid features on the self-managed subscription, so confirm the tier before you design around them. On ECK, the operator manages much of the certificate lifecycle; on virtual machines, your team owns certificate issuance and rotation. Done means a login test per role succeeds and a denied-access test fails as designed.
Set Secrets encryption and least-privilege access
Kubernetes stores Secrets unencrypted in etcd by default, so configure encryption at rest for the API server before Elastic credentials, certificates and keystores enter the cluster. Restrict list and watch access to those Secrets with least-privilege RBAC, and decide whether an external secret store fits your environment. On virtual machines, the equivalent work is file permissions, a keystore process and host access controls. Done means a test secret is confirmed encrypted in the datastore and RBAC tests show no unexpected access.
Load detection content and tune it
Install the prebuilt detection rules from the Kibana detection engine, enable only the rule families your use cases need, and document the tuning owner. Elastic publishes its rules in the elastic/detection-rules repository and delivers the latest prebuilt rules to Kibana automatically, so confirm the update process for your air-gapped or locked-down environment before you rely on it. Detection engine, machine learning anomaly detection and case management sit in different subscription tiers, so verify each rule family against your license. Done means each enabled rule has an owner and a test alert, and the disabled set is recorded with a reason.
Validate backups and restores end to end
Take Elasticsearch snapshots to a repository your team controls, restore them into a separate test cluster, and confirm that indexes, security roles, detection rules and Kibana saved objects return intact. On ECK, back up the custom resources and etcd alongside the snapshots; on virtual machines, back up configuration and keystores with the same discipline. Done means a timed restore runs to a written runbook and the result is signed off by the operations owner.
Hand over the operating routine
A fixed-scope implementation usually covers the design, build, hardening, detection load, backup validation and documentation, with the agreed deliverables and dates set in writing before work starts. The client keeps the operating routine: patching within the chosen release line, certificate rotation, capacity reviews, rule tuning, on-call response and periodic restore tests. Ongoing upgrades and testing are available as retainers if you want them outside the project. Done means the runbooks, the owner for each recurring task and the agreed support path are signed by both parties.
What buyers ask before choosing ECK or VMs for Elastic Security
How much does running Elastic Security on ECK cost compared with virtual machines?
Neither path has a published price from the sources we used, so the comparison comes down to who pays for what. Software licensing depends on the Elastic subscription tier you choose (Basic, Enterprise, or Elastic Cloud), and that cost is the same on either path. The difference is infrastructure and labor: ECK needs a Kubernetes control plane, worker nodes, storage classes and an operator to maintain, while VMs need hosts, a configuration management approach and manual upgrade steps. The Elastic subscriptions page lists which security features sit in each tier. Ask any quote to separate one-time build work from recurring operations, support and upgrades, and to state which Kubernetes distribution, storage and tier it assumes.
Can a team run ECK without prior Kubernetes experience?
Not comfortably, if the team has never operated Kubernetes. ECK is a Kubernetes operator, so the team must manage the cluster itself, its networking, persistent volumes, RBAC and upgrades before the Elastic components even start. Kubernetes releases roughly three times per year on a cycle of about 14 weeks, and the project maintains only the three most recent minor releases, so an in-house team must keep pace with that rhythm. A VM-based install asks for different skills, mainly Linux administration and Elasticsearch configuration. Assess your team against both lists, and consider a pilot on a non-production cluster before committing.
How many master-eligible nodes does a highly available Elasticsearch cluster need?
A highly available Elasticsearch cluster needs at least three master-eligible nodes, according to the Elasticsearch node roles documentation. This applies on both ECK and VMs, because the requirement is set by Elasticsearch, not the platform. On ECK, the operator manages node sets, so the count appears in the custom resource definition. On VMs, you configure each node's roles directly and place them across failure domains yourself. Dedicated master nodes are a common choice in larger clusters, but the minimum count is the same. Plan storage tiers (hot, warm, cold, frozen) separately from master roles, since they drive disk cost more than the master count does.
What does the client need to provide for an ECK or VM deployment?
The client needs to provide the infrastructure and the people who will own it. For ECK, that means a Kubernetes cluster in the client's cloud account, data center or air-gapped network, with the storage classes, load balancing, DNS, certificates and identity integration the stack requires. For VMs, it means host capacity, operating system images, network segmentation and backup targets. In both cases the client supplies the access model, such as who may administer the cluster and whether single sign-on uses SAML or OpenID Connect, which Enterprise features require. Confirm each dependency in writing before a fixed-scope engagement starts.
How are upgrades sequenced when Elastic runs on Kubernetes?
Upgrade order matters on both paths, but Kubernetes adds its own sequence. The Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time, before kube-controller-manager, kube-scheduler and kubelets, and kubelets may be up to three minor versions older than kube-apiserver. Elastic also publishes support windows: the Elastic EOL page lists end of maintenance for 8.x on January 15, 2027 and for the 9.x core stack on October 15, 2027. Plan the Kubernetes upgrade, the ECK operator upgrade and the Elastic stack upgrade as separate change windows, and test each on a staging cluster first. On VMs, the Elastic version upgrade is the main sequence to plan.
Is it worth hiring a consultant or implementation partner for this deployment?
It depends on whether your team can absorb the build, the hardening and the ongoing upgrades without slowing security operations. An implementation partner is paid for scoped work, which typically covers planning, deployment, integration, hardening, backup, documentation and handover. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so ask for a quote that lists deliverables, the client's responsibilities and the recurring support items separately.
What should we check in Kubernetes secrets and etcd before using ECK?
Check these before the first production deployment, because they hold the Elastic credentials and configuration. Kubernetes stores Secrets unencrypted in etcd by default, according to the Kubernetes secrets good practices page, so configure encryption at rest and restrict list and watch access with least-privilege RBAC, or use an external store through the Secrets Store CSI Driver. Kubernetes documentation also recommends an odd number of etcd members, with five members in production, and requires a backup plan using etcdctl snapshot save with restores through etcdutl. VM installs carry their own secret handling questions, so compare both against your existing controls and confirm them with your security team.
How DeployOpen scopes, delivers and supports Elastic deployments
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For an Elastic Security stack, that means deciding with you whether ECK or virtual machines fits your Kubernetes and Elasticsearch skills, then delivering that path under a written scope.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which Elastic tier, node roles and storage tiers are covered, including any Basic or Enterprise features.
- Ask for the scope to state who operates the Kubernetes control plane and etcd under the ECK path.
How we build
- Deployment covers the ECK operator or package installs, node role layout, storage tiers and Elastic Agent enrollment, per the agreed scope.
- Hardening covers TLS, role-based access control and secrets handling, with Kubernetes Secrets encryption at rest where ECK is used.
- Integration covers identity single sign-on, log sources and detection content, confirmed against your Elastic subscription.
How we hand over
- Handover includes documentation of the deployed architecture, upgrade steps and the backup and restore procedure for your environment.
- Compliance readiness material is prepared as evidence for your assessors, which DeployOpen does not itself certify or audit.
- Ask for a walkthrough so your platform or security engineers can operate the stack without DeployOpen on call.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial build.
- Retainer scope should cover Elastic version upgrades within maintained release lines and any Kubernetes upgrades on the ECK path.
- Confirm with DeployOpen during quoting how upgrade windows, response expectations and service levels will be written into the retainer.
