nudgebee

开源

采用 AI-SRE、AI-FinOps、AI-K8sOps 和 Agentic Automation Builder 的统一 CloudOps 平台,无需使用分散的工具、切换上下文或依赖模型。

382 stars0 点赞0 次浏览

工具介绍

采用 AI-SRE、AI-FinOps、AI-K8sOps 和 Agentic Automation Builder 的统一 CloudOps 平台,无需使用分散的工具、切换上下文或依赖模型。

Nudgebee

Open-source SRE copilot — observability, FinOps, runbook automation, and incident response across Kubernetes and AWS / Azure / GCP.

What is Nudgebee?

Nudgebee is an open-source SRE copilot that watches your Kubernetes clusters and AWS / Azure / GCP accounts, turns raw signals into ranked findings, and walks operators through investigation and remediation. It bundles:

Observability ingestion — Kubernetes events, metrics, traces, plus cloud-provider scans across AWS, Azure, and GCP.
FinOps & cost optimization — surfaces unused / underutilized resources (idle workloads, oversized pods, stale snapshots, dangling volumes) and right-sizing recommendations across cloud and Kubernetes.
LLM-powered triage — agentic planners that reproduce, root-cause, and propose fixes for incidents.
ChatOps — Slack / Teams chatbot for SRE workflows: query state, run runbooks, ack alerts, and drive investigations from the channel where on-call already lives.
Runbook automation — codifies recurring fixes as reusable runbooks and triggers them from chat, alert, or schedule.
Ticketing + notifications — bidirectional sync with Jira, ServiceNow, PagerDuty, Zenduty; alert delivery to Slack, Teams, email.

Dashboard screenshot — to be added. Track discussion thread or contribute via a PR.

Quick Start (Local Development)

This is the fastest way to run Nudgebee from source. Infra in containers, backend and frontend from source on the host. This is the path contributors should use.

Prerequisites

Docker (with docker compose) or Podman Desktop (with podman-compose)
Go 1.26+
Node 25+ and npm

1. Clone

bash

git clone https://github.com/nudgebee/nudgebee.git
cd nudgebee

2. Bring up infra + apply migrations

bash

docker compose up -d

The default compose profile starts Postgres, Redis, RabbitMQ, Qdrant, Temporal, and a one-shot migrations container that applies the Postgres + RabbitMQ schema and then exits. Re-runs are safe — golang-migrate is idempotent against an up-to-date tracker. To also run the backend and frontend in containers (instead of from source), use docker compose --profile full up -d. The full profile mounts the host Docker socket into llm-server so it can launch an isolated code-analysis workspace container per account; access to that socket is equivalent to host-level Docker control. Workspace containers join the internal nudgebee-workspace network and do not publish host ports.

To connect a Kubernetes agent to the Compose relay and K8s collector, use the local agent configuration.

See api-server/migrations/README.md for how migration tracking works and how to add a new migration.

3. Configure backend env

bash

# macOS / Linux / WSL
cp api-server/services/.env.example api-server/services/.env

# Windows PowerShell
Copy-Item api-server\services\.env.example api-server\services\.env

Then generate the encryption key and replace the __REPLACE__ placeholder for NUDGEBEE_ENCRYPTION_KEY in the new .env:

bash

openssl rand -hex 32

Keep this value — you'll paste the same key into app/.env in step 5, and into every other service's .env if you later run more from source (see Local Stack Bootstrap below). Rotating it after data is written makes previously-encrypted DB rows unreadable, so treat it like a database master password.

Other defaults work as-is against the compose stack from step 2. Read the inline comments before any non-local deploy — a few other values (private keys) also need rotation.

4. Run the backend

bash

# macOS / Linux / WSL (requires make)
cd api-server/services
make run

# Windows (no make required — runs the same command directly)
cd api-server\services
go run ./cmd

Listens on . Leave it running.

5. Configure frontend env

In a new terminal:

bash

# macOS / Linux / WSL
cp app/.env.example app/.env

# Windows PowerShell
Copy-Item app\.env.example app\.env

Replace __REPLACE__ for NUDGEBEE_ENCRYPTION_KEY with the same value you generated in step 3. The app can't decrypt what services-server writes unless these match.

The NEXTAUTH_SECRET in the example is a dev-only sample; rotate it for any non-local deploy.

6. Run the frontend

bash

cd app
npm install --legacy-peer-deps
npm run dev

Open .

7. Sign in

On the sign-in page, click Admin Login. Then:

Email: any address (e.g. [email protected]) — a tenant and an admin user are created automatically on first sign-in.
Password: literally Test!24#5 — the value of NEXTAUTH_DUMMY_CREDS_PASSWORD shipped in app/.env.example. Type it exactly; this is the dummy-credentials provider, not your own password.

Secrets & required env vars

The sample values in steps 3 and 5 above are fine for local dev. For any non-local deployment, generate fresh values and review the notes below.

Var	Used by	How to generate	Notes
`APP_DATABASE_URL`	services-server	—	Compose default: `postgres://postgres:postgrespassword@localhost:5432/nudgebee?sslmode=disable`. Use `localhost` from the host, `postgres` hostname from inside the compose network.
`NUDGEBEE_ENCRYPTION_KEY`	services-server and app	`openssl rand -hex 32`	Encrypts integration credentials and other sensitive columns. Must match between services-server and app. Rotating it makes previously-encrypted rows unreadable — there is no automatic re-encryption migration.
`ACTION_API_SERVER_TOKEN`	services-server and app	`openssl rand -hex 32`	Optional. Shared secret for internal app↔services-server action calls. Defaults to empty on both sides, which disables the check (fine for local dev). If you set it, the value must match in both files.
`NEXTAUTH_SECRET`	app	`openssl rand -base64 32`	Signs both NextAuth session cookies and the inner HS256 session JWT (used by nbctl / Bearer-flow callers). Rotating it logs everyone out and invalidates outstanding bearer tokens.
`NEXTAUTH_DUMMY_CREDS_ENABLED` / `_PASSWORD`	app	—	Enables the any-email/password provider. Use for local development only; turn it off in any deployment exposed beyond your laptop.
`RABBIT_MQ_USERNAME` / `_PASSWORD` / `_HOST` / `_PORT`	services-server	—	Compose defaults: `guest` / `guest` / `localhost` / `5672`.

Troubleshooting

error pinging postgres: lookup postgres: no such host from backend → APP_DATABASE_URL in api-server/services/.env still uses the container hostname. Replace @postgres:5432 with @localhost:5432.
migrate: error: pq: relation "..." already exists → the tracker schema drifted from actual tables. Inspect SELECT version, dirty FROM nudgebee.schema_migrations; and use migrate force to align. See api-server/migrations/README.md.
Action call from frontend returns 502 RPC gateway could not handle the operation → the requested action isn't registered in app/src/lib/actions.yaml, or it's a subscription / fragment / parse error. Check the frontend dev-server console for the unhandled reason.

Deploy to Kubernetes (Helm)

The umbrella chart is published as a public OCI artifact at oci://ghcr.io/nudgebee/charts/nudgebee and bundles Postgres, RabbitMQ, Redis, Qdrant, and Temporal as subcharts.

bash

# 1. Generate a permanent encryption key — store this securely.
#    Losing it makes previously-encrypted DB rows unreadable.
export NUDGEBEE_ENC_KEY=$(openssl rand -hex 32)
echo "Save this key: $NUDGEBEE_ENC_KEY"

# 2. Install
helm install nudgebee oci://ghcr.io/nudgebee/charts/nudgebee \
  --namespace nudgebee --create-namespace \
  --set nudgebee_secret.NUDGEBEE_ENCRYPTION_KEY="$NUDGEBEE_ENC_KEY" \
  --wait --timeout 20m

To pin a specific version, pass --version (latest is used by default). To install from source instead — useful when iterating on chart changes — clone the repo, run helm dep update deploy/kubernetes/nudgebee, and point helm install at the local path.

The post-install hook applies database migrations automatically. Once the pods are ready:

bash

kubectl -n nudgebee port-forward svc/app 3000:80

# Retrieve the bootstrap admin password
kubectl -n nudgebee get secret nudgebee \
  -o jsonpath='{.data.NEXTAUTH_DUMMY_CREDS_PASSWORD}' | base64 -d

Open and sign in with any email + that password. See deploy/kubernetes/README.md for production-grade configuration (ingress, TLS, external Postgres, ClickHouse, observability sidecars).

First Run — what to do after you sign in

The platform is live but empty. A quick tour that takes ~10 minutes:

Connect a cloud account or a Kubernetes cluster — Settings → Integrations. Onboarding a real cluster lets the K8s collector populate the knowledge graph; an AWS / GCP / Azure account lights up the spend + recommendations surfaces. Without at least one of these, most of the dashboard is intentionally empty.
Wire up a notification channel — Settings → Integrations → Slack / Teams / Email. Without one, you can still try the product, but notifications + ChatOps flows won't reach you.
Run a sample runbook — Runbooks → Library. The bundled library has runnable examples (health-check loops, K8s investigation, cost spotlights). Run one manually to see end-to-end orchestration.
Ask the AI assistant something — bottom-right corner of the dashboard. It can answer questions about your connected clusters, walk you through a recommendation, or kick off an investigation.

Stuck? Want to help?

Want to chat? Join us on Discord — async help, design discussions, contributor coordination.
Hit a bug? Open an issue using the bug template.
Idea for a feature? Use the feature template.
Want to contribute code? Read CONTRIBUTING.md — covers CLA, branch model, PR conventions, and local-dev debugging tips. Look for issues tagged good first issue.
Question that doesn't fit a template? Email [email protected] or use the contact links on the new-issue page.