nudgebee/nudgebee

Nudgebee – an open‑source SRE copilot

What it does

• Monitors Kubernetes clusters and the three major clouds (AWS, Azure, GCP).
• Turns raw events, metrics, traces and cloud‑provider scans into a ranked list of findings.
• Shows cost‑optimization signals (idle workloads, oversized pods, stale snapshots, dangling volumes) and suggests right‑sizing actions.
• Uses LLMs to automatically triage incidents: reproduce the problem, propose a root cause and generate a remediation plan.
• Exposes a ChatOps interface (Slack / Teams) so operators can query state, run runbooks, acknowledge alerts and drive investigations from the same channel they are on‑call.
• Provides a runbook engine that codifies recurring fixes and can trigger them from chat, alerts or a schedule.
• Syncs with ticketing systems (Jira, ServiceNow, PagerDuty, Zenduty) and delivers notifications via Slack, Teams or email.

How it is built

• Backend – a set of Go services (Gin HTTP framework) handling tenants, integrations, recommendation logic and the RPC gateway.
• LLM layer – Go‑based llm-server plus a RAG server and a code‑analysis worker that keep session state, retrieve relevant vectors from Qdrant and run on‑demand code analysis.
• Runbooks – orchestrated with Temporal workflows; a dedicated runbook-server talks to Temporal, stores state in Postgres and communicates via RabbitMQ.
• Data stores – Postgres (core state), Redis (caching), RabbitMQ (event bus), Qdrant (vector store for RAG), Temporal (workflow engine).
• Collectors – agents that run inside a Kubernetes cluster and cloud‑collector jobs that scan AWS/Azure/GCP APIs. They push metrics, events and cost data into the central bus.
• Frontend – a Next.js (TypeScript) dashboard (app/) that talks to the backend via GraphQL/RPC, handles authentication with NextAuth, and hosts the chat‑assistant UI.
• Deployment – provided as a Helm chart (OCI‑hosted) that bundles all required infra as sub‑charts, plus a Docker‑Compose setup for local development.

Getting started (local dev)

1. Install Docker (or Podman) with compose, Go 1.26+, Node 25+.
2. docker compose up -d brings up Postgres, Redis, RabbitMQ, Qdrant, Temporal and a migration container.
3. Copy the example .env files for the backend (api-server/services/.env) and the frontend (app/.env), generate a 32‑byte encryption key with openssl rand -hex 32 and place the same key in both files.
4. Run the Go backend (make run or go run ./cmd) – it listens on http://localhost:8000.
5. Install the frontend dependencies (npm install --legacy-peer-deps) and start the dev server (npm run dev). The UI is reachable at http://localhost:3000.
6. Sign in with any email and the dummy password Test!24#5 (provided by the dev auth provider).

Production deployment

• Install the Helm chart from oci://ghcr.io/nudgebee/charts/nudgebee.
• Supply a permanent NUDGEBEE_ENCRYPTION_KEY (generated once with OpenSSL) via the chart’s nudgebee_secret values.
• The chart provisions the same infra components as the compose stack and runs a post‑install hook that applies database migrations.
• After the pods are ready, port‑forward the app service and log in with the generated admin password from the secret.

Typical workflow

1. Connect a cluster or cloud account → the collector populates a knowledge graph of resources, metrics and spend.
2. Review the dashboard – findings are ranked; cost‑optimization recommendations appear.
3. Ask the AI assistant (bottom‑right chat) a question like “Why is pod frontend‑abc using 2 CPU?” – the LLM uses the retrieved context to explain and may suggest a right‑size.
4. Run a runbook – either manually from the Runbooks → Library page or automatically via a ChatOps command. The runbook executes as a Temporal workflow, interacting with the cluster through the relay‑server.
5. Close the loop – notifications are sent to Slack/Teams, tickets are created/updated in Jira or ServiceNow, and the incident is marked resolved.

Who might use it

• Site‑Reliability Engineers who need a single pane of glass for observability, cost‑control and incident response.
• Cloud‑native teams that manage multi‑cloud workloads and want AI‑assisted triage.
• Organizations looking for a self‑hosted alternative to commercial SRE “copilot” platforms.

Where to get help / contribute

• Discord: https://discord.gg/C5d27ceTEv
• Issues: use the provided bug‑report and feature‑request templates.
• Good‑first‑issue label for newcomers.
• See CONTRIBUTING.md for CLA, branch model and PR guidelines.

---

All details above are taken directly from the repository’s README; no additional features have been inferred.