DevOps & Infrastructure

Nudgebee: I installed it, here’s my verdict

21 June 2026 Mehdi 21:41

Nudgebee is an open source CloudOps platform that wants to bring SRE, FinOps, Kubernetes Ops, runbooks and an AI assistant together in a single cockpit. My short verdict: the idea is solid and some blocks genuinely work, but the project is still heavy to install and not yet smooth enough for a team that just wants to plug in a tool and ship results within an hour.

What is Nudgebee?

Nudgebee presents itself as an open source SRE copilot. The repository targets a fairly ambitious use case: monitoring Kubernetes clusters, scanning cloud accounts, ranking recommendations, triggering runbooks, talking to ticketing services and exposing a Next.js interface to manage all of it.

On paper, the product wants to replace the classic thousand-piece stack: one tool for costs, another for incidents, another for runbooks, another for AI. Here, everything is designed as a centralized platform.

The repository structure confirms that ambition. You’ll find a web app, a Go API server, a runbook server, cloud and Kubernetes collectors, an LLM server, a RAG server, ticketing, notifications and even an ML service for Kubernetes right-sizing.

Tested element Observed result
Repository Monorepo Go, TypeScript, Python
Stated prerequisites Docker, Go 1.26, Node 25, npm 11
Frontend Installation succeeded with Node 25, Next.js launch OK
Runbook engine Dry-run tests executed, real workflow output
Full stack Blocked here because Docker was not available
Perceived quality Ambitious, but still rough

Installing Nudgebee

I cloned the GitHub repository into a temporary folder, then read through the README and dependency files. First important point: Nudgebee is not a small binary you just run. It’s a real distributed platform.

The official path requires Docker Compose for PostgreSQL, Redis, RabbitMQ, Qdrant and Temporal, then Go 1.26 for the backends and Node 25 for the web app.

The documented base commands look like this:

git clone https://github.com/nudgebee/nudgebee.git
cd nudgebee
docker compose up -d
cp api-server/services/.env.example api-server/services/.env
cp app/.env.example app/.env
cd app
npm install --legacy-peer-deps
npm run dev

In my test environment, Docker was not installed. So I couldn’t launch the full platform with Postgres, RabbitMQ, Qdrant and Temporal. I did, however, install the missing source-side runtimes: Go 1.26.1 and Node 25.9.0 with npm 11.12.1.

The Next.js app installation succeeded with Node 25: 1522 packages installed, 51 npm vulnerabilities reported, including one high severity. That’s not unusual for a large frontend app, but it’s the kind of debt I look at closely before putting an operations tool into production.

Using Nudgebee

I wanted to avoid the fake test where you just say: the server starts. So I tested two concrete paths.

The first path: launching the web app. After configuring the local environment, the Next.js server started on port 3000. The HTTP page responded correctly, the styles and interface shell were served. Since the full backend wasn’t available, I couldn’t validate an end-to-end flow with a real cloud integration or Kubernetes cluster.

The second path: running the Go-side runbook engine, which is one of the most interesting pieces of the product. I ran targeted tests on runbook-server/internal/workflow, specifically the dry-run executor. There, Nudgebee produces something concrete: it starts a test workflow, injects dry-run mode, executes a core.print task, marks the task as complete and returns an output.

The command used:

export OPENAI_BASE_URL=http://172.17.0.1:8790/v1
export OPENAI_API_KEY=sk-proxy
export OPENAI_API_BASE=http://172.17.0.1:8790/v1
export OPENROUTER_BASE_URL=http://172.17.0.1:8790/v1
export OPENROUTER_API_KEY=sk-proxy

go test ./internal/workflow -run 'TestExecutorDryRunTestSuite' -v

Significant output observed:

Starting workflow workflowId test-dryrun-wf tenantID test-tenant accountID test-account
DryRun: Executing task with dry-run flag taskID task1 taskType core.print
Task completed taskID task1 result executed
Workflow completed successfully
Workflow execution completed workflowId test-dryrun-wf result map[task1:executed]

Nudgebee interface showing the dry-run of a runbook in the logs

I also ran a series of parsing, DAG validation, templating and switch routing tests. Many pass, which shows that the runbook core is not just a facade. But I also saw clear failures: a realpath template filter announced by the test is not registered, and a webhook secret logic fails while trying to reach mock-integration-service via DNS.

Nudgebee interface showing the frontend installation with npm

What I like about Nudgebee

What I like most is the product framing. Nudgebee doesn’t just say AI to sell a dashboard. The repository contains classic operational building blocks: workflows, tenants, accounts, integrations, audit, tickets, notifications, scan orchestrator, collectors and Temporal.

I also like the idea of versioned YAML runbooks. For a DevOps team, that’s more useful than a simple chatbot. A runbook needs to be re-runnable, auditable, validated and tied to triggers. Nudgebee is heading in that direction.

Another positive point: the README is fairly honest about complexity. It explains the minimum required services, per-component dependencies and the limits of dry-run mode. That’s valuable, because a dry-run that still calls external systems can catch you off guard in production.

Nudgebee’s limitations

The first limitation is installation. Docker, Go 1.26, Node 25, npm 11, Temporal, RabbitMQ, Redis, Qdrant, Postgres: that’s a serious stack. For a large platform team, it’s defensible. For a freelancer or a small business, it’s a lot.

The second limitation is perceived maturity. Not all the tests I ran are green. A missing templating filter and a test that tries to resolve a mock service via external DNS are not dramatic for a project in motion, but they signal that some areas are not yet polished.

The third limitation is that real value requires integrations. Without a Kubernetes cluster, without a cloud account, without Slack or Teams, without a full backend, the interface stays fairly empty. Nudgebee is not a tool you judge solely by its home screen.

Does Nudgebee actually work?

Yes, partially, within what I was able to run. The Next.js frontend installs and launches. The runbook engine executes a real dry-run and produces workflow output. The parsing, DAG and templating validators cover concrete cases.

No, I can’t say the full platform is validated end-to-end in this test. The absence of Docker blocked the official launch with databases, message queues and complete services. I’d rather say that clearly than sell a validation I didn’t actually do.

For a reader who wants to test Nudgebee, I’d recommend doing it on a machine with a working Docker Compose setup and enough RAM. Then, the real test to run is straightforward: connect a lab Kubernetes cluster, import a few intentionally imperfect resources, and see whether the recommendations and runbooks actually help you take action.

Should you adopt Nudgebee?

My verdict: worth trying if you have a platform team, a SRE culture and the desire to experiment with an ambitious open source tool. Adopt it in production only after a real pilot, with a security review, an npm dependency review, properly configured secrets and tests against your own integrations.

For a DevOps freelancer, I see it more as a source of inspiration and a lab environment. The runbook engine is interesting. The full platform is still too heavy to quickly replace a simpler chain based on Prometheus, Grafana, GitOps scripts and a few targeted automations.

For an infra startup or a team suffering from too many fragmented tools, Nudgebee deserves a spot on the short-list. Not because everything is magic, but because the project is tackling a real problem.

FAQ

Is Nudgebee free?

The GitHub repository is open source under the Apache 2.0 license. You still need to account for the cost of running the stack: databases, queue, Temporal, storage, compute and integration time.

Does Nudgebee replace Grafana or Prometheus?

Not directly. Nudgebee sits more above the signals, to correlate, recommend and automate. In a real stack, it could complement existing observability rather than replace it.

Is Nudgebee production-ready?

I’d be cautious. The building blocks are promising, but my test revealed rough edges and I didn’t validate the full stack. I’d classify it as a tool to pilot seriously before adoption.

Leave a comment

Your email address will not be published. Required fields are marked *