Nudgebee: an SRE copilot that keeps its runbooks in the repo

The fragmentation problem Nudgebee is aimed at

On-call work in a multi-cloud shop usually spans four tools that do not talk to each other. Metrics live in one place, cloud cost data in another, the runbook for a known failure in a wiki page nobody has updated, and the alert routing in a chat tool. Nudgebee's pitch is that these are one product. The README lists observability ingestion (Kubernetes events, metrics, traces plus AWS, Azure and GCP scans), FinOps findings such as idle workloads, oversized pods, stale snapshots and dangling volumes, LLM-powered triage, ChatOps over Slack and Teams, runbook automation, and bidirectional ticketing sync with Jira, ServiceNow, PagerDuty and Zenduty. The intended user is an SRE or platform team that owns clusters and cloud accounts and wants the investigation surface, the cost surface and the remediation surface in one place. It is not aimed at a single-cluster hobby setup, and the prerequisites make that clear.

What the compose profile tells you about the architecture

The default docker compose profile starts Postgres, Redis, RabbitMQ, Qdrant, Temporal and a one-shot migrations container that applies the Postgres and RabbitMQ schema then exits. That set of dependencies is the architecture in miniature. Postgres holds relational state including encrypted integration credentials. Redis is a cache or queue. RabbitMQ carries events between services. Qdrant is a vector store, which is where the LLM triage retrieves context from. Temporal is a workflow engine, which is what makes runbooks durable rather than a shell script that dies halfway. The backend is a Go service in api-server/services listening on port 8000, and the front end is a Next.js app in app/ on port 3000. The full profile adds one more thing worth reading carefully: it mounts the host Docker socket into llm-server so that service can launch an isolated code-analysis workspace container per account. The README states plainly that access to that socket is equivalent to host-level Docker control, and that workspace containers join an internal nudgebee-workspace network without publishing host ports. That is an honest disclosure of a real privilege boundary, and it is the single most important operational fact on the page.

Getting a local stack running

The documented path is infra in containers, backend and frontend from source. Prerequisites are Docker with docker compose (or Podman Desktop with podman-compose), Go 1.26 or newer, and Node 25 or newer with npm. Clone the repository, then run docker compose up -d to start the infra and apply migrations. The README notes re-runs are safe because golang-migrate is idempotent against an up-to-date tracker, and points to api-server/migrations/README.md for how tracking works and how to add a migration. Copy api-server/services/.env.example to api-server/services/.env, generate a key with openssl rand -hex 32, and paste it where NUDGEBEE_ENCRYPTION_KEY has a __REPLACE__ placeholder. Start the backend with make run from api-server/services, or go run ./cmd on Windows. Copy app/.env.example to app/.env and paste the same encryption key, because the app cannot decrypt what services-server writes unless the two match. Install with npm install --legacy-peer-deps, run npm run dev, open port 3000, and sign in through Admin Login with any email address and the literal password Test!24#5. That password is the NEXTAUTH_DUMMY_CREDS_PASSWORD sample value, not a real credential. The README also warns that rotating NUDGEBEE_ENCRYPTION_KEY after data is written makes previously encrypted database rows unreadable, so it should be treated like a database master password.

The licence is the first thing to check, not the last

The repository metadata reports NOASSERTION for the licence, while the README badge says BSL 1.1 and links to ./LICENSE. Those two signals do not agree, and the gap matters more here than in most projects. BSL 1.1 is a source-available licence with a change date: it typically converts to an open source licence after a set period, and it typically restricts production or commercial use that competes with the vendor. The specific terms, the change date and the definition of permitted use live in the LICENSE file, which is not included in the material available here. Anyone evaluating Nudgebee for a commercial product, a managed service, or a fork should read that file directly rather than trusting the badge, and should get their own legal review rather than relying on a summary. The other licence-adjacent cost is operational: the default profile requires five stateful or semi-stateful services before you can look at a single finding, and the full profile widens the container's privilege over the host.

Where the documentation is thin

The README is strong on bootstrap and quiet on behaviour. There is no dashboard screenshot; the page carries a placeholder noting one is to be added and pointing at a discussion thread. There is no example of what a ranked finding looks like, no sample runbook definition, no schema for the Ticketing sync, and no description of how the agentic planners are prompted or which models they call. The description mentions model lock-in avoidance, but nothing in the supplied material shows the abstraction that would deliver it, so treat that claim as unverified. The Kubernetes agent is referenced only through a link to docs/QUICKSTART.md for connecting an agent to the Compose relay and K8s collector; the agent's own installation, permissions and update path are not described here. For a platform that will hold cloud credentials and encrypted integration secrets, the absence of a published threat model beyond the Docker socket warning is a gap an adopter should close by reading the source.

Release cadence and what it implies for upgrades

The three most recent releases are v1.8.0-rc.1, v1.8.0-rc.2 and v1.8.0-rc.3, dated 2026-09-08 and 2026-09-09, with the last repository push on 2026-09-10. That is a tight release-candidate loop, which reads as active development but also as a version line that has not yet settled. Anyone pinning Nudgebee in production is choosing between a release candidate and an older stable tag that is not listed in the supplied material. Migration cost is the concrete upgrade concern: the compose stack includes a migrations container, the README says golang-migrate is idempotent, and the encryption key warning means key rotation and schema migration are separate operations with different failure modes. A migration that changes an encrypted column is the scenario to plan for, because the README states that rotating the key after data is written makes previously encrypted rows unreadable. There is no documented rollback procedure in the material provided.

How it differs from wiring up Prometheus, Kubecost and a chatbot yourself

The obvious alternative is assembling the same capabilities from single-purpose tools: Prometheus and Grafana for Kubernetes metrics and alerting, a cloud cost tool for right-sizing, and a chat bot glued to an automation runner. That stack is permissively licensed, widely understood, and each piece can be replaced independently. The difference in approach is where the reasoning lives. In the assembled stack, the correlation between a cost anomaly, a Kubernetes event and a past incident is a human activity performed across three browser tabs, and any automation is a script that runs to completion or dies. Nudgebee puts a vector store and a workflow engine behind that correlation, so triage retrieves prior context and remediation runs as a durable Temporal workflow with state. The trade is that you now operate Qdrant and Temporal, and the reasoning pipeline is inside a BSL-licensed product rather than in scripts you own. If your team already has mature Grafana dashboards and a small set of well-understood failure modes, the assembled stack is the cheaper answer. Nudgebee earns its place when the number of clusters, clouds and distinct failure modes has outgrown what a wiki page and a runbook script can cover.

Editorial conclusion

Adopt Nudgebee if you run Kubernetes plus at least one public cloud, you already have Temporal and Postgres capacity, and you want triage and remediation logic to live in your own infrastructure rather than in a vendor tenant. Do not adopt it if you need a permissively licensed component you can fork into a commercial product, or if you have no appetite for operating Postgres, Redis, RabbitMQ, Qdrant, Temporal and a Docker socket-exposing analysis service. Before committing, verify three things: the exact terms in the LICENSE file behind the NOASSERTION label, that the v1.8.0 release candidates have been replaced by a stable tag, and that the Kubernetes agent configuration in docs/QUICKSTART.md matches your cluster's network policy.

Official sources

1. Issues
2. nudgebee/nudgebee on GitHub
3. Project website
4. README
5. Releases