# Nudgebee: a fourteen-service SRE copilot you run from source

> Observability, FinOps, triage, ChatOps and runbook automation across Kubernetes and three clouds, delivered as a monorepo whose local run is gated by one encryption key and one Docker socket.

**nudgebee/nudgebee** — Unified CloudOps platform with AI-SRE, AI-FinOps, AI-K8sOps, and the Agentic Automation Builder without fragmented tools, context switching, or model lock-in.

- Repository: https://github.com/nudgebee/nudgebee
- Website: https://nudgebee.com/
- Stars: 398 · Forks: 263
- Language: Go
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/nudgebee-nudgebee

## One root Makefile fans out to thirteen service Makefiles

Nudgebee is a monorepo before it is a product. The root Makefile names seven Go services: api-server/services, ticket-server, runbook-server, collector-server/cloud-collector, collector-server/k8s-collector/relay-server, llm/code-analysis, and llm/llm-server. Five Python services sit alongside them: ml-k8s-server, llm/rag-server, collector-server/k8s-collector/app, notifications-server, and llm/benchmark. app is the only TypeScript target, and app-e2e-tests is a separate tier beside it.

Each service keeps its own Makefile and the root file only dispatches, using `$(MAKE) -C <dir> <target>`. Targets are named per service (fmt-app, lint-app, test-app) so GNU Make can run them in parallel, for instance `make -j test`. Only services whose Makefile defines a target join a fan-out, and CI calls each service's commands directly, so changing the root file alters no existing build behavior. `make help` lists what is available.

The release cadence is busy. v1.9.0-rc.2 shipped on 2026-09-24, rc.3 on 2026-09-30, and rc.4 on 2026-10-01, three release candidates in nine days, with the last push on 2026-10-01. The repository carries 397 stars, 264 forks, and 70 open issues. Licensing lives in files rather than one identifier: LICENSE, LICENSING.md, NOTICE, TRADEMARKS.md, and a licenses/ directory all sit at the root.

## The default compose profile runs migrations once and exits

The default profile is infrastructure only. Cloning and starting it takes two commands:

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

```bash
docker compose up -d
```

That brings up Postgres, Redis, RabbitMQ, Qdrant, and Temporal, plus a one-shot container named `migrations` that applies the Postgres and RabbitMQ schema and then exits. Re-runs are safe, because golang-migrate is idempotent against an up-to-date tracker, so the container is not a piece of state you have to remember to remove before restarting.

The services address each other by compose name rather than by localhost. Defaults point RABBIT_MQ_HOST at rabbitmq on port 5672 with guest credentials, and set CACHE_PROVIDER to redis with REDIS_SERVER_HOST at redis on 6379, no auth, which works because clients are lazy and do not dial until first use. APP_DATABASE_URL is where the split shows: the compose default uses localhost from the host and the postgres hostname from inside the compose network. Prerequisites are Docker with docker compose, or Podman Desktop with podman-compose, plus Go 1.26+ and Node 25 with npm.

## The full profile hands llm-server the host Docker socket

`docker compose --profile full up -d` also runs the backend and frontend in containers rather than from source, and it changes the trust boundary. The full profile mounts the host Docker socket into llm-server so that service can launch an isolated code-analysis workspace container per account. Access to that socket is equivalent to host-level Docker control, and the project says so in plain terms.

Workspace containers join the internal `nudgebee-workspace` network and do not publish host ports, which narrows what someone can reach from outside the host. It does not narrow what a workspace can do through the socket it was handed. Two further shared secrets travel with this profile. RELAY_WORKSPACE_JWT_SECRET on relay-server and LLM_SERVER_JWT_SECRET on llm-server sign and verify the same workspace JWTs, so the compose file feeds one variable into both and you set it in one place. ACTION_API_SERVER_TOKEN is optional, and when it is empty on both sides the internal app-to-services-server action check is simply disabled, which the project calls fine for local work.

## One encryption key has to match in two services, with no way back

Nudgebee encrypts integration credentials and other sensitive columns with NUDGEBEE_ENCRYPTION_KEY, and the key must be identical between services-server and app. Start from the example files:

```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
```

Generate the value with:

```bash
openssl rand -hex 32
```

Paste the same 64 hex characters into the `__REPLACE__` placeholder for NUDGEBEE_ENCRYPTION_KEY in `api-server/services/.env`, then into `app/.env`, and into any other service `.env` if you run more of them from source. The app cannot decrypt what services-server writes unless the two match.

The consequence is worth reading twice. Rotating the key after data has been written makes previously-encrypted database rows unreadable, there is no automatic re-encryption migration, and the value is meant to be treated like a database master password. Treat the shipped default, 64 hex characters of `0123456789abcdef` repeated, as a development value. NEXTAUTH_SECRET in the app example is a dev-only sample too, and the project flags a few other private keys that need rotation before any non-local deploy.

## Admin Login takes any email and one fixed password

Run the backend with `make run` from `api-server/services`, which listens on http://localhost:8000 and stays running. Then the frontend:

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

That serves http://localhost:3000. The sign-in page has an Admin Login button, and the credentials under it are not a real account. The email can be any address, for example `dev@example.com`, and a tenant plus an admin user are created automatically on first sign-in. The password is literally `Test!24#5`, the value of NEXTAUTH_DUMMY_CREDS_PASSWORD shipped in `app/.env.example`, typed exactly. This is a dummy-credentials provider, which is convenient locally and means the sign-in path has nothing to do with production identity.

The `--legacy-peer-deps` flag on the npm install is there for a reason the docs do not spell out, so expect peer dependency conflicts if you drop it. Two ports are fixed by the local setup, 8000 for the API and 3000 for the app.

## Raw signals arrive, ranked findings leave

What Nudgebee claims to do is watch Kubernetes clusters and AWS, Azure, and GCP accounts, turn raw signals into ranked findings, and walk operators through investigation and remediation. Ingestion covers Kubernetes events, metrics, and traces, plus cloud-provider scans across the three clouds. Cost work is part of the same pipeline rather than a separate tool: it surfaces unused and underutilized resources, naming idle workloads, oversized pods, stale snapshots, and dangling volumes, then produces right-sizing recommendations for cloud and Kubernetes.

Triage sits on top of that data. The LLM-powered tier uses agentic planners to reproduce an incident, root-cause it, and propose a fix, which is a different shape of claim from surfacing a metric: the system is expected to recreate the failure before it proposes anything. What the visible documentation does not tell you is how long reproduction takes, what the tool budget is, or how the ranking orders findings when several are plausible, so those are the questions to put to the project rather than assume.

The description frames the pitch as avoiding fragmented tools, context switching, and model lock-in. One of those three is checkable from the repository itself, since you bring your own provider credentials rather than a bundled model.

## Runbooks fire from chat, an alert, or a schedule

ChatOps is where the workflow claims to meet the on-call rotation. A Slack or Teams chatbot handles the SRE loop from the channel where people already are: query state, run runbooks, acknowledge alerts, and drive investigations. Runbook automation codifies recurring fixes as reusable runbooks, and those runbooks can be triggered from chat, from an alert, or from a schedule, so a fix that has been written down once does not need a human to paste it in again.

Ticketing runs both ways. Nudgebee syncs bidirectionally with Jira, ServiceNow, PagerDuty, and Zenduty, and delivers alerts to Slack, Teams, and email. The repository reflects that spread as separate services: ticket-server and notifications-server are their own Go and Python targets, and runbook-server is a third. That is a real cost to weigh, since each integration is a credential set you have to store, and the credentials live in the database under the encryption key from earlier.

For cluster agents, the project points at docs/QUICKSTART.md for connecting a Kubernetes agent to the Compose relay and the K8s collector, and at api-server/migrations/README.md for how migration tracking works and how to add a migration.

## Host port 8003, because AirPlay already owns 5000

The k8s-collector listens on container port 5000 and publishes to host port 8003 by default. The reason is in the environment example: host port 5000 collides with the macOS AirPlay Receiver, and 8003 keeps the service inside the 800x range the rest of the app uses. If 8003 is taken on your host, change K8S_COLLECTOR_HOST_PORT.

The same example file sets out the other shared secrets, all with insecure development defaults that compose falls back to when a variable is unset. RELAY_SERVER_SECRET_KEY, RELAY_WORKSPACE_JWT_SECRET, and ACTION_API_SERVER_TOKEN each ship with a change-me value, and the file states plainly that these defaults are not safe for real use. Copy .env.example to .env, which docker compose auto-loads, and edit before running the stack anywhere that is not your laptop.

There is also agent-facing guidance checked into the tree: AGENTS.md, CLAUDE.md, and GEMINI.md at the root, alongside .claude/, .gemini/, and .jules/ directories, plus .gitleaks.toml and .golangci.yml. For a project that asks you to mount a Docker socket, a committed secret scanner configuration is not a surprise, but it is worth noticing that the workflow files are part of the repository rather than something you add yourself.

## Conclusion

Nudgebee fits teams that already run Kubernetes and more than one cloud and want findings, cost rightsizing, runbooks and ticket sync in one place. It does not fit a single-cluster shop or anyone unwilling to hold a Docker socket on a shared host. Before you deploy past your laptop, read the secrets table end to end and replace NUDGEBEE_ENCRYPTION_KEY, because the project states plainly that rotating it later leaves stored credentials undecryptable with no migration to recover them.

## FAQ

### What do I need installed to run Nudgebee from source?

Docker with docker compose, or Podman Desktop with podman-compose, plus Go 1.26+ and Node 25 with npm. Infrastructure runs in containers while the backend and frontend run from source on the host.

### How do I sign in to a local Nudgebee stack?

Click Admin Login on the sign-in page, enter any email address, and type the password `Test!24#5` exactly. That value is NEXTAUTH_DUMMY_CREDS_PASSWORD from app/.env.example, and a tenant plus admin user are created automatically on first sign-in.

### Why must services-server and app share one NUDGEBEE_ENCRYPTION_KEY?

The key encrypts integration credentials and other sensitive columns, and the app cannot decrypt what services-server writes unless both use the same value. Rotating it later leaves previously-encrypted rows unreadable, and there is no automatic re-encryption migration.

### What does the docker compose full profile add over the default one?

It runs the backend and frontend in containers instead of from source, and mounts the host Docker socket into llm-server so it can launch an isolated code-analysis workspace container per account. The project notes that socket access equals host-level Docker control.

### Does the Nudgebee make test target run the end-to-end suites?

No. The test and validate targets are unit tests only. The app-e2e-tests suites are deliberately excluded because they need a configured live environment with a target cluster, tenant, and credentials, so they run explicitly with make e2e.

### Which ticketing and chat systems does Nudgebee connect to?

Bidirectional sync covers Jira, ServiceNow, PagerDuty, and Zenduty. Alerts are delivered to Slack, Teams, and email, and a Slack or Teams chatbot can query state, run runbooks, and acknowledge alerts.

## Sources

- [Issues](https://github.com/nudgebee/nudgebee/issues)
- [nudgebee/nudgebee on GitHub](https://github.com/nudgebee/nudgebee)
- [Project website](https://nudgebee.com/)
- [README](https://github.com/nudgebee/nudgebee/blob/main/README.md)
- [Releases](https://github.com/nudgebee/nudgebee/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nudgebee-nudgebee