/provisioning

name: cloud-provisioning
description: >
  Provision and operate Elastic Cloud infrastructure: create, connect to, update,
  and delete Serverless projects (Elasticsearch, Observability, Security); manage
  traffic filters (IP and AWS PrivateLink network security); and manage the lifecycle
  of Elastic Cloud Hosted deployments. Use when creating or performing day-2 operations
  on serverless projects or hosted deployments, or restricting their network access.
compatibility: >
  Requires the `elastic` CLI (>= 0.2) with `cloud serverless` and `cloud hosted` support
  and network access to the Elastic Cloud API (api.elastic-cloud.com). Serverless
  operations apply to Elastic Cloud Serverless; deployment operations apply to Elastic
  Cloud Hosted. Depends on a configured Cloud context (see cloud-onboarding).
metadata:
  author: elastic
  version: 0.3.0
  universal: true

Cloud Provisioning

Provision and run Elastic Cloud infrastructure through the Cloud API: **Serverless projects** (create and day-2 operations), **traffic filters** (network security for those projects), and **Elastic Cloud Hosted deployments**. For configuring Cloud authentication and managing organization access, use the **cloud-onboarding** skill.

<!-- begin-partial: cloud-preamble -->

Environment Configuration

This skill operates the Elastic Cloud control plane through the `elastic` CLI. If the [`elastic` CLI](https://github.com/elastic/cli#configuration) is not installed, tell the user what it is needed for. Do not guess credentials, bypass the CLI to call the HTTP API directly, or attempt other workarounds.

Control-plane operations authenticate against the Elastic Cloud API (organization scope), not a single stack deployment. The `elastic` CLI reads this from its active context, which stores an Elastic Cloud API key in the OS keychain. If a control-plane call fails with an authentication error, the context is missing or lacks a Cloud API key — instruct the user to add one, and **never** ask the user to paste an API key into the chat:

> "Configure an Elastic Cloud context for the `elastic` CLI, then re-run. Generate an Organization-level key at > [Elastic Cloud API keys](https://cloud.elastic.co/account/keys) and register it without echoing the secret in chat."

This skill references control-plane operations in HTTP-shorthand form with the `cloud:` prefix (e.g., `GET cloud:/api/v1/organizations`, `POST cloud:/api/v1/serverless/projects/elasticsearch`). The [Operations](#operations) table at the end of this document maps each shorthand to the equivalent `elastic cloud` command — always use the CLI rather than calling the HTTP API directly. Discover the organization ID from `GET cloud:/api/v1/organizations`; do not ask the user for it.

<!-- end-partial: cloud-preamble -->

Critical principles

• **Never display secrets in chat.** Do not echo, log, or repeat passwords or API keys in conversation or agent

thinking. Persist credentials into a CLI context (OS keychain) and direct the user there.

• **Confirm before creating or destroying.** A project's or deployment's region is permanent; deletion is irreversible.

Present the configuration and get explicit confirmation before creating, deleting, or resetting credentials.

• **Admin credentials are bootstrap-only.** The `admin` password returned on creation or reset exists solely to create a

scoped API key. Never use admin credentials for ongoing Elasticsearch operations — mint a scoped key first.

• **Wait for readiness.** A new project or deployment starts `initializing`; wait until `initialized` before using it.
• **Two kinds of credentials.** The **Cloud context** (Cloud API key) authorizes control-plane operations here. A

project's or deployment's **Elasticsearch API key** authorizes data-plane operations against its Elasticsearch endpoint — do not confuse the two. See [references/credentials-and-context.md](references/credentials-and-context.md).

---

Serverless projects

Project types

| Type | Description | Included services | | --------------- | ----------------------------------------- | -------------------------------- | | `elasticsearch` | Search, analytics, and vector workloads | Elasticsearch, Kibana | | `observability` | Logs, metrics, traces, and APM | Elasticsearch, Kibana, APM, OTLP | | `security` | SIEM, endpoint protection, cloud security | Elasticsearch, Kibana, OTLP |

Map the user's request to the correct type; never silently default — infer from context and confirm, or ask when ambiguous. "search"/"elasticsearch"/vector search → `elasticsearch`; "o11y"/logs/metrics/traces/APM → `observability`; "SIEM"/detections/endpoint → `security`.

**Tiers and optimization.** Elasticsearch: set `optimized_for` to `general_purpose` (default) unless the user explicitly requests `vector`. Observability: set `product_tier` to `complete` (default) or `logs_essentials`. Security: set `product_types` tiers to `complete` (default) or `essentials` per product line (`security`, `cloud`, `endpoint`). See [references/api-reference.md](references/api-reference.md) for the full request-body schema of each type.

Process: create a serverless project

1. **Confirm the project type.** Infer it from the conversation and propose it, or ask the user to choose. Do not proceed on an assumed type. 2. **Confirm the configuration.** Present a summary — name (required; ask if missing), region (default `gcp-us-central1`), and the tier/optimization for the type — and get explicit confirmation. If the region is uncertain, list options with `GET cloud:/api/v1/serverless/regions` first; only regions with `project_creation_enabled: true` accept new projects. Region is permanent. 3. **Create the project.** Call `POST cloud:/api/v1/serverless/projects/{type}` with the confirmed body. Wait for the `initialized` phase and persist the returned credentials int