L2 Assess · github trending · Jul 27, 2026

n8n-io/n8n

proceedmedium confidence

01 · Fit to Stack

strong fit

n8n already runs as a homelab service (CT 102) and is an active dependency inside bud's pipeline, so this is not a new-tool adoption question but an evaluation of new capability in software already deployed and trusted. The self-hosted, free-tier nature of the new AI nodes matches the operator's stated preferences directly.

02 · Fit to Vision

partial fit

bud's classification logic currently lives in a Python/FastAPI service the operator wrote and understands; moving it into n8n's node-based AI feature trades that for a visual-workflow abstraction, which cuts a component but reduces code-level control and testability. The operator's stated interest is learning modern web dev, not deepening n8n workflow design, so this is an operational win more than a learning one.

Implementation Options

01Time-boxed spike: parallel classification trial

bud3-5 hourslow risk

Add a branch to the existing n8n workflow that sends the same email content bud already routes through the FastAPI classifier to an n8n AI node backed by the existing Ollama instance. Log both outputs side by side for a week of real traffic without changing the production path or removing anything.

+Zero risk to bud's working, unattended classification path during the trial

+Produces real accuracy/latency evidence instead of deciding from a changelog alone

-Adds temporary duplicate processing overhead while the trial runs

-Does not resolve anything by itself -- still requires a follow-up decision afterward

02Full migration: retire the FastAPI classifier

bud6-10 hoursmedium risk

Rebuild bud's email classification directly inside n8n using its native AI node against the existing Ollama instance, remove the separate FastAPI classification service, and have the n8n workflow write straight to Supabase after in-workflow classification.

+Reduces bud from three components to two, meaning one less service to deploy and keep running

+Consolidates classification logic into a single visual workflow instead of splitting it across n8n and FastAPI

-Re-expresses tuned Python classification logic inside n8n's node UI, which is harder to version, unit test, and debug

-Carries real regression risk to a production pipeline that is meant to run unattended, with no trial period to catch quality drops

-Locks bud's core classification step to n8n's AI node feature set instead of portable Python code

01 · Value

bud currently splits email handling across n8n (routing to Supabase) and a separate FastAPI service (classification). If n8n's new AI nodes can classify in-workflow at acceptable quality, bud drops from three moving components to two -- one fewer service to deploy, monitor, and keep alive on the homelab.

02 · Why It Matters

This is a narrower and more concrete decision than most trending items: n8n is not a new tool being pitched, it is a dependency already running in production, and the question is only whether a capability it just gained should replace code the operator already wrote and understands.

03 · What Implementation Looks Like

A minimal v1 is the spike: a new branch in the existing n8n workflow (CT 102) that calls an AI node for classification, run in parallel with the current FastAPI call on the same emails, writing both results to a comparison log for about a week. No production component is removed until that comparison shows the AI node matches or beats the FastAPI service on accuracy and latency.