The Problem: Renovate Bot is Prolific

If you run a Kubernetes homelab with Renovate Bot, you know the drill. Every morning you wake up to a flood of open pull requests — patch updates, minor bumps, the occasional major version change. Each one needs a decision: safe to merge, needs a closer look, or definitely hands-off.

Doing this manually gets old fast. But blindly auto-merging everything is a bad idea too — you really don’t want Renovate silently bumping your CloudNativePG major version at 2am.

So I built a middle ground: an n8n workflow powered by Claude that reads each PR, reasons about the risk, and either merges it automatically, flags it for review, or rejects it from auto-merge — all while leaving a comment on the PR explaining the decision.

The Workflow at a Glance

Every 23h → Get Open PRs → Filter Renovate PRs → Loop Over Items
  → Store PR Data → Get PR Comments → Check If Processed → Only New PRs
  → AI PR Analyzer (Claude) → Add PR Comment → Decision Router
      ├── APPROVED  → Merge PR → Notify Slack
      ├── NEEDS_REVIEW → Notify Slack
      └── REJECTED  → Notify Slack

Each stage has a clear responsibility, and the whole thing runs on a 23-hour schedule so it doesn’t hammer the GitHub API.

Step-by-Step Breakdown

1. Schedule Trigger

The workflow kicks off every 23 hours via n8n’s scheduleTrigger. I chose 23h instead of 24h to avoid drifting into the same time slot every day — a small but useful trick.

2. Fetch Open PRs from GitHub

A plain HTTP request hits the GitHub API:

GET https://api.github.com/repos/affragak/pi5cluster/pulls?state=open&per_page=50

Bearer token auth keeps it simple. Returns all open PRs in the repo.

3. Filter for Renovate PRs

A Filter node checks if the PR’s source branch contains "renovate". This ensures we only process what Renovate created — no accidental interference with your own branches.

4. Loop Over Items

Rather than processing all PRs in one shot, a splitInBatches node with batchSize: 1 processes each PR individually. This matters for correctness when referencing upstream node data later in the flow.

5. Store PR Data

A Code node extracts and normalises the fields we care about:

return {
  pr_number: pr.number,
  pr_title: pr.title,
  pr_url: pr.html_url,
  pr_body: pr.body || '',
  pr_author: pr.user.login,
  target_branch: pr.base.ref,
  comments_url: `https://api.github.com/repos/affragak/pi5cluster/issues/${pr.number}/comments`
};

6. Idempotency Check

Before sending anything to Claude, the workflow fetches existing PR comments and looks for a hidden marker:

const alreadyProcessed = comments.some(
  comment => comment.body && comment.body.includes('<!-- n8n-ai-assessment -->')
);

If the marker is found, the PR is dropped. This means the same PR is never analyzed twice — even if it stays open across multiple workflow runs.

7. AI PR Analyzer — The Heart of the Workflow

This is where Claude comes in. The n8n LangChain Agent node sends each PR’s title, description, and metadata to Claude Sonnet with a carefully crafted prompt.

Claude is instructed to:

• Confirm the PR is from Renovate Bot
• Identify the component and version change (PATCH / MINOR / MAJOR)
• Evaluate risk level (LOW / MEDIUM / HIGH) using explicit homelab-specific rules
• Return a structured JSON decision

The rules baked into the prompt are opinionated for this infrastructure:

• Database updates (PostgreSQL, CloudNativePG) → always HIGH risk
• Core infrastructure (Cilium, Flux CD, cert-manager, external-secrets) → HIGH risk
• Simple app updates with no breaking changes → LOW risk
• Helm chart minor updates → MEDIUM risk

Claude returns something like:

{
  "decision": "APPROVED",
  "risk_level": "LOW",
  "update_type": "PATCH",
  "component": "linkding",
  "from_version": "1.4.1",
  "to_version": "1.4.2",
  "breaking_changes": false,
  "breaking_changes_details": "",
  "reasoning": "Simple patch update with bug fixes only.",
  "recommendation": "Safe to merge automatically."
}

A JSON Output Parser node enforces the schema so downstream nodes can reference fields without any string parsing.

8. Add PR Comment

Regardless of the decision, the workflow always posts an assessment comment to the PR. This creates a human-readable audit trail for every automated choice:

<!-- n8n-ai-assessment -->
## AI Assessment

| Field | Value |
|-------|-------|
| **Decision** | APPROVED |
| **Risk Level** | LOW |
| **Update Type** | PATCH |
| **Component** | linkding |
| **Version** | 1.4.1 -> 1.4.2 |
| **Breaking Changes** | false |

### Analysis
Simple patch update with bug fixes only.

### Recommendation
Safe to merge automatically.

---
*Analyzed by n8n AI Agent using Claude*

The hidden HTML comment at the top is what the idempotency check looks for on subsequent runs.

9. Decision Router

A Switch node routes on Claude’s decision field:

• APPROVED → Merge PR via GitHub API (squash) → Slack notification
• NEEDS_REVIEW → Slack notification only
• REJECTED → Slack notification only

Squash merging keeps the commit history clean — one commit per dependency bump.

10. Slack Notifications

Each outcome sends a message to #k3s-pi5cluster. Approved PRs get a confirmation with the version bump. Rejected or needs-review PRs include Claude’s reasoning and a direct link.

Why This Works Well

Conservative by design. The system prompt explicitly instructs Claude to be cautious: “when in doubt, recommend manual review — never auto-approve database migrations or breaking changes.” The AI is calibrated to be conservative, not to blindly approve things.

Idempotent by architecture. The hidden HTML marker ensures the same PR is never touched twice across workflow runs.

Full audit trail. Every PR gets a comment, approved or not. You can always look at a merged PR and see exactly what reasoning led to the decision.

Domain-aware rules. By encoding homelab-specific knowledge directly into the prompt, you get decisions appropriate for your actual infrastructure rather than generic risk advice.

What I’d Improve Next

Include the actual diff. Claude currently only sees the PR description, not the file changes. Fetching GET /pulls/{pr_number}/files and including the diff in the prompt would let Claude verify the description matches reality.

Check mergeable state. The workflow doesn’t verify that CI checks have passed before merging. Adding a check against the PR’s mergeable_state field would prevent merging a PR that’s failing tests.

Version history awareness. Knowing that the last three patch updates for a given component merged cleanly could factor into the risk assessment. Something to explore with persistent storage in n8n.

Wrapping Up

This workflow has taken nearly all the manual toil out of dependency management in my homelab. Patch updates merge themselves. Major version bumps and database changes land in Slack for intentional review. Every decision has a paper trail on the PR itself.

If you’re running Renovate on a homelab cluster and spending more than 10 minutes a week clicking through dependency PRs, this is well worth an afternoon to set up.