[🐛 Bug]: HTTP / bash / python / console providers hidden from Connect Provider UI catalog

[ckaiser-graniterock]

Summary

The http provider (and similarly bash, python, console) does not appear in the Connect Provider UI catalog, even though the provider code is present and functional on the backend. This makes it impossible to install these providers through the UI, blocking common use cases (workflow actions that call arbitrary HTTP endpoints, run scripts, etc.).

Environment

• Keep build: commit 339151c9 on main (released 2026-04-14 as part of post-v0.51.0 development)
• Deployment: self-hosted docker compose, images us-central1-docker.pkg.dev/keephq/keep/keep-api:latest and keep-ui:latest
• EE/ directory on the image only contains identitymanager — no EE provider gating

Reproduction

1. Open Keep UI → Providers → Connect Provider
2. Search http in the catalog → no results
3. Repeat with bash, python, console → no results
4. On the backend container:

   docker exec keep-keep-backend-1 ls /venv/lib/python3.13/site-packages/keep/providers/ | grep -E 'http|bash|python|console'

   → http_provider/, bash_provider/, python_provider/, console_provider/ are all present.

Root cause

Frontend filter in keep-ui/app/(keep)/providers/page.client.tsx requires:

Object.keys(provider.config || {}).length > 0 || (provider.tags && provider.tags.includes("alert"))

The http provider:

• has no auth config (it's stateless — URL/method/body/headers are per-call workflow args)
• has no PROVIDER_TAGS declaration in http_provider.py
• backend tag-derivation logic in providers_factory.py (lines ~385–400) gives it data + messaging tags based on _query / _notify methods, but not alert (which requires _get_alerts)

→ Filter evaluates false || false → hidden.

Same applies to bash, python, console which also have no auth config and no alert-source behavior.

Impact

Workflows that need to call REST APIs with dynamic URLs (e.g., auto-restart an infra resource based on alert labels) cannot install the provider via UI. Operators either abandon the workflow, use the wrong provider (webhook has a fixed URL), or discover the KEEP_PROVIDERS env var workaround by reading source code.

Even worse: the UI silently hides the provider with no indication that it exists. Search just returns empty results — no hint that you should use a different mechanism.

Workaround

Provision via KEEP_PROVIDERS env var on keep-backend:

# docker-compose.yml keep-backend service:
environment:
  - KEEP_PROVIDERS=${KEEP_PROVIDERS}

# .env:
KEEP_PROVIDERS={"http-default":{"type":"http","authentication":{}}}

Then docker compose up -d --force-recreate keep-backend. Provider appears under Installed Providers.

Suggested fix

Pick one:

A. Add minimal PROVIDER_TAGS to the affected providers — e.g., PROVIDER_TAGS = ["action"] (new tag) or PROVIDER_TAGS = ["alert"] (reuse existing) on http_provider, bash_provider, python_provider, console_provider. Minimal code change, doesn't touch the filter.

B. Update the UI filter to include action-capable providers — Object.keys(config).length > 0 || tags.includes("alert") || (can_notify && can_query). Broader fix, catches any similar provider in the future.

C. Add a "Utility" or "Action" tab to the Connect Provider UI that exposes these stateless power-user providers explicitly, separate from the alert-source tabs.

Happy to open a PR for any of these if there's a preferred direction.

Related

Another Keep asymmetry discovered same day: the snowflake provider is installed by default (Database category, _query for enrichment) but has no _format_alert, so POST /alerts/event/snowflake explodes with NotImplementedError while POST /alerts/event/<unknown-name> falls back gracefully to the keep provider. Users hit this landmine when routing Snowflake-originated alerts through Keep. Distinct issue but same root cause family: asymmetric provider gating.