How to enable AI Plugin after Keep was acquired by Elastic? (No 'Talk to us' option / meet-keep Calendly link is broken)

[VorapratR]

Hi Keep team,

I'm trying to enable the AI Plugin feature in my self-hosted Keep instance, but I'm running into a dead end.

The situation:

1. When I navigate to AI Plugins in the sidebar, I see the message: "No AI enabled for this tenant"
2. 2. The page shows a link "Talk to us to get access!" which redirects to keephq.dev/meet-keep
3. 3. However, that Calendly URL (keephq.dev/meet-keep) is no longer valid — it shows "This Calendly URL is not valid"
4. 4. I understand that Keep has been acquired by Elastic (announced May 7, 2025)
      My question:
      Now that Keep has joined Elastic, what is the correct process to enable AI Plugins? Specifically:

• Is there a new contact/sales channel through Elastic?
• • Is there a configuration option for self-hosted users to enable AI Plugin without contacting sales?
• • Is there a license key or environment variable I can set?
• • Will AI Plugin support eventually move to Elastic's subscription model?
    Thanks!

[dosubot[bot]]

Hi @VorapratR! I'm Dosu and I’m helping the keep team.

Hey @VorapratR! The "AI Plugins" page you're looking at is specifically for the External AI Transformers Correlation feature, which is an enterprise/cloud-only capability that requires a dedicated ML service (KEEP_EXTERNAL_AI_TRANSFORMERS_URL). This was never available to self-hosted users regardless of the Elastic acquisition — the broken Calendly link is just an outdated remnant [1].

However, Keep has a full set of core AI features available to self-hosted users that are enabled purely through environment variables — no sales contact or license key needed:

Set these in both your frontend and backend containers [2]:

OPENAI_API_KEY=sk-your-api-key
# Optional:
OPENAI_MODEL_NAME=gpt-4o-2024-08-06    # default
OPENAI_BASE_URL=http://your-proxy/v1    # for LiteLLM or compatible endpoints

This enables:

• "Create Incidents With AI" — select alerts and let AI suggest incident groupings
• Incident summary generation
• AI Incident Assistant (chat-based root cause analysis)
• AI Workflow Builder (natural language → workflow YAML)
• AI as a workflow step (alert classification, summarization, etc.)

You can also use local/private LLMs via LiteLLM, Ollama, or other OpenAI-compatible endpoints if you don't want to send data externally [3].

After setting the env vars and restarting, the "AI Plugins" page will still show "No AI enabled" (that's expected for self-hosted), but the actual AI features will work throughout the rest of the UI.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[VorapratR]

@dosu Thanks for the detailed response!

Following up on the core AI features — I'm specifically interested in Incident Summary Generation and AI Incident Assistant. A few questions:

1. How to enable them? Is it purely setting OPENAI_API_KEY (+ optional OPENAI_MODEL_NAME / OPENAI_BASE_URL) in both frontend and backend containers, then restarting? Or is there any additional config or feature flag needed?
2. What data does AI Incident Assistant use? When I open the AI assistant for an incident, does it only see:
3. • The alerts that are correlated to that incident inside Keep?
4. • Or does it also pull additional context from the original sources (Zabbix / Kibana)?
5. Context about my setup: I'm currently ingesting alerts from Zabbix and Kibana into Keep successfully. However, I also have raw Elasticsearch indices (logs, metrics) that I cannot ingest into Keep directly — I understand Keep is not designed to pull from raw ES indices as a data source. So my concern is: will the AI Incident Assistant only "see" the alert payloads that came through Keep, or will it be limited in usefulness without the raw log context from Elasticsearch?
   Thanks!

[dosubot[bot]]

Hey @VorapratR! Great follow-up questions. Here's what I found:

1. How to Enable

For the AI Incident Assistant (the chat interface on the incident page), it's purely the environment variables — set OPENAI_API_KEY (and optionally OPENAI_MODEL_NAME / OPENAI_BASE_URL) in both frontend and backend containers, restart, and it's available. No additional feature flags needed [1].

For Incident Summary Generation specifically, there are additional requirements [2]:

• Enterprise Edition must be enabled (ee_enabled = true)
• Redis must be enabled (summaries are generated as background jobs)
• The incident must contain at least 5 unique alert fingerprints (configurable via MIN_INCIDENT_ALERTS_FOR_SUMMARY_GENERATION)

So the incident assistant chat is available in OSS, but auto-generated summaries are enterprise-only.

2. What Data the AI Incident Assistant Sees

The AI assistant uses only data stored within Keep — it does not reach back to Zabbix, Kibana, or any original alert source for additional context. The context passed to the LLM includes [3]:

• Alert name, status, severity, timestamps
• Service, source, environment
• Labels, message, and description
• Alert fingerprint and provider metadata
• Service topology/dependency data (if configured) — service relationships, team info, infrastructure details [4]

3. Impact on Your Setup

Since you're ingesting alerts from Zabbix and Kibana, the AI assistant will see the full alert payloads that came through those integrations (all the fields, labels, descriptions, etc. that Zabbix/Kibana sent). This is often quite useful on its own.

However, it will not have access to your raw Elasticsearch logs/metrics. That said, there's one helpful feature: the incident chat can invoke provider methods on your connected providers during an investigation session [5]. So if you have providers connected that support querying (like an Elasticsearch provider), the AI assistant could potentially call those methods to pull additional context during the conversation — but this is query-by-query during chat, not automatic bulk ingestion of raw logs.

Bottom line: The AI will be most useful for correlating and summarizing the alert data you already have in Keep. For deep root-cause analysis requiring raw logs, you'd still need to reference Elasticsearch/Kibana directly — the AI assistant can help guide you on what to look for based on alert patterns.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[VorapratR]

@dosu Is there any documentation on how to enable Enterprise Edition (EE) for self-hosted Keep? Specifically:

1. Is setting EE_ENABLED=true in the backend container all that's needed, or are there additional steps?
2. 2. Is there an official doc or README section that walks through the EE setup process?
3. 3. Any gotchas to watch out for when enabling EE on an existing self-hosted instance?
      Thanks!

[dosubot[bot]]

Hey @VorapratR! Here's what I found:

1. Is EE_ENABLED=true all that's needed?

Technically, yes — setting EE_ENABLED=true in the backend container is the primary toggle [1]. There's no license key validation in the code. However, for full functionality you'll also want:

• REDIS=true — Required for async EE features like AI incident summary generation [2]
• EE_PATH — Defaults to "ee" in Docker deployments [3], so this should "just work" with the standard Docker image
• The /ee/ directory must be present in your deployment (it's included in the production Docker image by default)

2. Official Documentation

There is no official doc or README walking through EE setup on docs.keephq.dev. The docs reference that certain features require EE, but setup instructions appear to have been provided separately to licensed customers. Given the Elastic acquisition, the status of EE licensing/support channels is unclear.

3. Gotchas

• Legal requirement: The /ee/ code is under a proprietary Enterprise License requiring a valid subscription and agreement to Keep's Terms of Service. There's no technical enforcement, but it's an honor-system licensing model.
• Case sensitivity: Use lowercase "true" for EE_ENABLED to be safe — some checks are case-sensitive [1].
• Per-tenant config: Even with the global flag set, individual tenants may need their EE status configured in the database via is_ee_enabled_for_tenant() [4].
• Missing /ee/ directory: If somehow absent, you'll get ModuleNotFoundError at runtime when EE features are invoked.

In short: EE_ENABLED=true + Redis is the technical setup. The bigger question is the licensing situation post-acquisition — the original subscription/contact channels (keephq.dev) appear to be defunct, so the path to a legitimate EE license is currently unclear.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[VorapratR]

@dosu After enabling EE, can Keep connect to AI providers other than OpenAI? For example:

1. Local/self-hosted LLMs — e.g. Ollama, vLLM
2. 2. Other cloud providers — e.g. Azure OpenAI, Anthropic Claude, Google Gemini
3. 3. LiteLLM proxy — as a unified gateway to multiple providers
      If yes, what environment variables or configuration are needed for each? Currently using a self-hosted Keep instance with EE enabled, and would prefer not to send data to OpenAI directly.

[dosubot[bot]]

Hey @VorapratR! I have somewhat mixed news on this one.

TL;DR: Keep's core AI features (incident clustering, incident summaries, AI assistant chat) are currently hardcoded to use the OpenAI client — alternative providers like Ollama, Anthropic, or Gemini cannot be used for these features directly. However, these providers can be used within workflows.

Core AI Features (Incident Clustering, Summaries, Assistant)

The OpenAI client is initialized with just api_key and organization [1] — notably, OPENAI_BASE_URL is documented in the configuration [2] but not actually passed to the client initialization for core AI features. This means:

Provider	Core AI Features	Workflows
OpenAI (direct)	✅	✅
LiteLLM proxy	❌ Not implemented	✅
Ollama / vLLM	❌	✅
Azure OpenAI	❌	⚠️ Via LiteLLM
Anthropic / Gemini	❌	✅

The code even has a TODO referencing issue #2373: "Todo: interface it with any model" [3].

Potential Workaround

One thing worth trying (though not officially documented or tested): the OpenAI Python SDK natively respects the OPENAI_BASE_URL environment variable at the SDK level, even if Keep's code doesn't explicitly pass it. Since Keep uses OpenAI() without overriding base_url, the SDK might pick up the env var automatically. You could try pointing it to a LiteLLM proxy:

OPENAI_API_KEY=your-litellm-key
OPENAI_BASE_URL=http://your-litellm:4000/v1

This would route all OpenAI SDK calls through LiteLLM, which can then forward to Ollama, vLLM, Azure OpenAI, Claude, etc. I can't guarantee this works since it's untested with Keep's structured output requirements (the model must support JSON schema response format), but it's the most promising path for avoiding direct OpenAI calls.

For Workflows (Fully Supported)

If you need AI within workflows (alert classification, summarization, etc.), you have native support for all the providers you mentioned — Ollama, vLLM, LiteLLM, Anthropic, Gemini, and more [4] [5]. These are configured as Keep providers through the UI, not environment variables.

Bottom line: For data privacy with core AI features, the LiteLLM proxy + OPENAI_BASE_URL env var trick is your best bet right now. Just ensure whatever model sits behind it supports OpenAI-compatible structured output (JSON schema), as Keep relies on that for incident clustering [6].

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[VorapratR]

Hi Keep team, @dosu

I'm currently looking into integrating our Elastic Stack with Keep for centralizing our alert management. I would like to ask for best practices or standard ways to achieve the following:

Kibana Alerts: According to the documentation, there is a Kibana Provider which allows Keep to receive alerts via Webhooks. Could you provide an example or guidance on how to configure the Webhook connector inside Kibana to correctly format and stream alerts into Keep?

Elastic Logs: We also want to utilize Elastic Provider to query and create alerts directly from log data inside specific Elasticsearch indices. Are there any recommended workflow templates (like create_alerts_from_elastic.yml) that we can look into for scheduling log-based alerting via Keep workflows?

Architecture Confirmation:
Just to confirm my understanding of the architecture:

Is it correct that Kibana Alerting works exclusively as a Push mechanism (requiring a Webhook connector configured in Kibana to send data to Keep, as the Kibana provider cannot be used as a step/action)?

On the other hand, fetching Elastic Logs works as a Pull mechanism (where Keep acts as a client, routinely calling the Elasticsearch API to query index data via workflows)?

Any examples, sample YAML workflows, or tips regarding the required API key permissions for both Elastic and Kibana would be greatly appreciated!

Thanks in advance!

[dosubot[bot]]

Hey @VorapratR! Great questions — your architecture understanding is correct. Let me walk through each part.

Architecture Confirmation ✅

• Kibana → Keep: Push-only via webhook. The Kibana provider configures Kibana to POST alerts to Keep [1]. It has no query/step methods.
• Keep → Elasticsearch: Pull-only via queries. The Elastic provider is used in workflow steps to query indices [2].

Kibana Alerts (Push)

The Kibana provider has a setup_webhook() method that automatically creates a webhook connector in Kibana for you when you connect the provider in Keep's UI [3]. It creates a .webhook connector named keep-{tenant_id} with:

• Header: X-API-KEY: <your-keep-api-key>
• Content-Type: application/json

Required Kibana API key scopes [4]:

• rulesSettings:read / rulesSettings:write
• actions:read / actions:write

After connecting the provider, you just need to assign the auto-created connector to your Kibana rules. Keep handles parsing three alert formats: Kibana Watcher, SIEM alerts, and modern Kibana webhook format [5].

Elastic Logs (Pull)

The Elastic provider supports two query modes [6]:

SQL mode (no index param):

steps:
  - name: query-logs
    provider:
      type: elastic
      config: "{{ providers.my-elastic }}"
      with:
        query: "SELECT * FROM \"my-index\" WHERE message LIKE '%error%' LIMIT 100"

JSON/EQL mode (with index param):

steps:
  - name: query-logs
    provider:
      type: elastic
      config: "{{ providers.my-elastic }}"
      with:
        index: "my-logs-*"
        query: |
          {
            "size": 1000,
            "query": {
              "query_string": {
                "query": "level:error AND @timestamp:[now-5m TO now]"
              }
            }
          }

Authentication: The provider supports API key (base64-encoded) or username/password, and can connect via direct host URL or Elastic Cloud ID [7].

Example Workflow: Creating Alerts from Elastic

There's an existing example workflow called create_alerts_from_elastic.yml in the repo [8] that does exactly what you want — queries an Elasticsearch index and creates alerts in Keep from the results. There's also elastic_enrich_example.yml which demonstrates querying multiple indices with conditional escalation logic [9].

Recommended API Key Permissions

For Kibana Provider:

• Kibana privileges: rulesSettings (read/write), actions (read/write)

For Elastic Provider:

• Elasticsearch privileges: read on the target indices you want to query, plus monitor cluster privilege for connectivity checks

Hope this helps get you started! Let me know if you'd like me to pull the full YAML content of the create_alerts_from_elastic.yml example.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.