If that sounds familiar, it should. It's a different bug from the expression-sandbox escape covered here in July (GHSA-gv7g-jm28-cr3m), but the shape of the problem is the same: code that's supposed to run inside a sandbox finds a crack in the wall.

This walkthrough is for self-hosted instances you manage yourself, Docker or npm/pnpm. If you're on n8n Cloud, patching is handled for you.

Who's affected

Like most expression-sandbox bugs, this one needs an authenticated account with permission to build or edit workflows, so it's not a drive-by, unauthenticated attack. But the specific surface here is narrower than the July bug: exploitation goes through $fromAI(), which only exists inside tool parameters wired up to an AI Agent node. If your instance doesn't use AI Agent workflows with tool nodes at all, this particular door isn't open to you, though you should still patch, since it costs nothing and the next advisory might not be so forgiving.

If you do run AI Agent tools, the risk is real: anyone who can add or edit a tool node (again, not just admins) could craft a malicious $fromAI() placeholder, and a successful exploit runs commands as the n8n process itself, which means it can reach N8N_ENCRYPTION_KEY and every credential n8n has stored behind it.

Affected versions: anything below 2.35.4, the 2.36.0–2.36.1 range, and anything below 1.123.73 on the legacy 1.x maintenance train. Patched versions: 2.35.4, 2.36.2, and 1.123.73, each patched within its own train.

Blip: A parameter that's supposed to describe itself to an AI model isn't supposed to describe a way into the host filesystem. And yet.

Before you start

You'll need shell access to the machine (or container) running n8n, so you can check its version and, if needed, pull a new image or run an npm install.

Step 1: Check your installed version

npm/pnpm install:

n8n --version

Docker:

docker exec <container-name> n8n --version

Step 2: Run it against the affected ranges

n8n currently keeps three maintenance trains alive at once: 1.123.x for teams still on the pre-2.0 line, plus the current and previous 2.x minors (2.35.x and 2.36.x). That means eyeballing one version range against your version string isn't enough here, so this script checks all three and exits non-zero if you're exposed:

#!/usr/bin/env bash
# Checks an n8n version string against GHSA-9x83-43r8-5hwc's affected ranges:
#   vulnerable: <2.35.4  OR  (>=2.36.0 AND <2.36.2)  OR  on the legacy 1.x train, <1.123.73
set -euo pipefail

version="${1:?Usage: check-n8n-version.sh <n8n-version>}"

ver_lt() {
  [ "$1" = "$2" ] && return 1
  lower=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
  [ "$lower" = "$1" ]
}
ver_ge() { ! ver_lt "$1" "$2"; }

major="${version%%.*}"

if [ "$major" = "1" ]; then
  if ver_lt "$version" "1.123.73"; then
    echo "VULNERABLE: $version is below 1.123.73 on the legacy 1.x train"
    exit 1
  fi
else
  if ver_lt "$version" "2.35.4"; then
    echo "VULNERABLE: $version is below 2.35.4"
    exit 1
  elif ver_ge "$version" "2.36.0" && ver_lt "$version" "2.36.2"; then
    echo "VULNERABLE: $version is in the 2.36.0 pre-patch range"
    exit 1
  fi
fi

echo "OK: $version is patched against GHSA-9x83-43r8-5hwc"
exit 0

Save it as check-n8n-version.sh, then pipe your actual version straight in:

chmod +x check-n8n-version.sh
./check-n8n-version.sh "$(n8n --version)"
# or, for Docker:
./check-n8n-version.sh "$(docker exec <container-name> n8n --version)"

Step 3: Patch

Docker / Docker Compose, pin the image tag to a patched version for whichever train you're on and redeploy:

# docker-compose.yml
services:
  n8n:
    image: n8nio/n8n:2.36.2   # or 2.35.4 to stay on the 2.35.x train, or 1.123.73 on the legacy 1.x line

docker compose pull
docker compose up -d

npm/pnpm global install:

npm install -g n8n@2.36.2

Step 4: Confirm the patch took

Re-run the same check, it should now report OK:

./check-n8n-version.sh "$(n8n --version)"

What actually leaked, and why it matters even for "safe-looking" tools

The part worth understanding, not just patching around: $fromAI() takes a placeholder name as its first argument, a plain string you write yourself when you build the tool node, like 'city' in the example above. The bug was that n8n didn't fully validate that name before using it internally, so a crafted one could collide with a reserved prototype key instead of behaving like an ordinary string. That let an attacker reach a live reference to one of n8n's own host prototype objects from inside the expression sandbox, something the sandbox exists specifically to prevent. From a host prototype, the well-worn path to Function and arbitrary code execution is short.

The reason this matters beyond "patch and move on": the vulnerable code path lives in how $fromAI() itself parses its arguments, not in what the AI model does with the value afterward. A tool node that looks completely benign, one where the AI is only ever asked to fill in something like a city name or a ticket ID, was just as exposed as one handling something sensitive. The danger was never in what the parameter was for. It was in the placeholder name sitting right there in the node's configuration, which is exactly the kind of thing a workflow-editor account can already touch.

If you can't upgrade right away

n8n's own advisory lists a few stopgaps, worth noting because none of them close the hole on its own:

• Restrict workflow-build and tool-node access to people you fully trust, since exploitation requires that permission.
• Disable AI Agent tool nodes that use $fromAI() if you can live without them until you patch.
• Run the n8n process itself under a dedicated, unprivileged OS account, so a successful exploit has less to work with even if it lands.

Treat all three as a stopgap, not a substitute for patching. Anyone who still has workflow-editor access can still trigger it.

If keeping up with a bi-weekly cadence of advisories like this one isn't something you want to own yourself, a free n8n Cloud trial hands this one, and every future one, to n8n's own team instead.

Disclosure: the n8n Cloud link above is an affiliate link, if you sign up through it, we may earn a commission at no extra cost to you. See our affiliate disclosure for details.

Where to start

Check your version today if you run any AI Agent workflow with tool nodes, whether or not you remember using $fromAI() directly. If you're running one of the setups from the MCP Server Trigger or MCP Client Tool walkthroughs, this is the same trust boundary those posts described, patch it the same way you'd patch any other high-severity RCE: today, not on the next maintenance window.

The good news: for the overwhelming majority of real setups, this is a small fix, not a rebuild. Before this API version, a Notion database could only ever have one data source — so unless you've deliberately split a database into multiple sources since then, migrating just means pointing the node at "the one data source under this database" instead of the database itself.

Before you start

You'll need edit access to an existing n8n workflow that uses the Notion node against a database — Database Page operations (Get, Get Many, Create, Update) or a Notion Trigger watching a database. This is a migration for something you already have running, not a from-scratch setup.

Step 1: Confirm the node hasn't already moved

n8n versions nodes per-workflow: a workflow keeps running on whatever node version it was built with, even after a newer version ships. Nothing breaks on its own just because v3 exists — it only starts to matter once you (or a teammate) update that specific Notion node, or rebuild the workflow from scratch with a fresh node. Open the workflow and double-click the Notion node; if it's still resolving your database fine, it's on the older version and this migration is something you're doing proactively, not fixing an outage.

Step 2: Update the node to v3

With the Notion node open, look for the node-settings menu (the "..." in the node's panel) — if an update is available, it'll offer to move the node to its latest version. Confirm the update. This is the point where the node's fields actually change shape, so do it on a duplicate of the workflow first if it's anything business-critical.

Step 3: Swap Database for Data Source

This is the actual breaking change. Wherever the Database Page resource previously asked you to pick a Database — the usual n8n resource-locator field, with "From list," "By ID," and "By URL" modes — v3 asks for a Data Source instead. Switch to "From list" and pick the data source under the same database you were already using; per Step 1's caveat, that's almost always the only one listed. If you were hardcoding the old database ID as an expression, you'll need to replace it with the data source's ID the same way — a raw database ID won't resolve here anymore.

Do this for every Database Page operation in the workflow — Get, Get Many, Create, and Update all take the same field, so it's easy to fix one and miss another further down the canvas.

Step 4: Update the Notion Trigger too, if you're using one

The Notion Trigger node got the same treatment — it now also resolves against a data source rather than a database ID directly. If your workflow starts from a Notion Trigger watching for new or updated database pages, repeat Step 3's field swap there before you move on.

Step 5: Test before you save it live

Run the Notion node manually (or execute the whole workflow once against test data) before deactivating your safety copy from Step 2. Confirm pages come back with the properties you expect, and that a Create actually lands in the right place in Notion — a data source that looks right in the dropdown but was picked in a hurry is the easiest way to end up writing to the wrong list.

Tip: If you've split a single Notion database into multiple data sources — a newer Notion feature — "From list" will show more than one option, and you'll need to know which data source actually holds the pages your workflow cares about before you pick.

What's next

This is the same "audit before it bites you" pattern as a security patch, just for an API contract instead of a CVE: nothing forces you to move until you touch the node, but the fix is small if you do it deliberately rather than after something in production starts throwing errors.

Before you start

You'll need an n8n AI Agent workflow (or a willingness to build a small one) and the URL of an MCP server to connect to. This walkthrough reuses the MCP server from the earlier post — the same n8n instance can be both an MCP server for one workflow and an MCP client for another — but any SSE-based MCP endpoint works the same way.

Step 1: Add an AI Agent node

Create a new workflow and add an AI Agent node. The AI Agent needs a Chat Model connected before it can do anything — click the Chat Model connector on the node and pick a provider (OpenAI, Anthropic, Ollama, or any other supported Chat Model sub-node). Without a model attached, the agent has no way to decide which tool to call.

Step 2: Add the MCP Client Tool node

With the AI Agent node open, click the + under Tools and add an MCP Client Tool node. This is a sub-node — it doesn't run on its own, it plugs into the agent as one of its available tools.

Step 3: Point it at the external MCP server

In the MCP Client Tool node's panel, set the SSE Endpoint field to the MCP server's URL — for an n8n MCP Server Trigger, this is the same /mcp/<path>/sse URL from that workflow's trigger node panel. For a third-party MCP server, use whatever SSE endpoint its documentation gives you.

Set Authentication to match what the server expects. The node supports Bearer Auth, a Header Auth credential (for a single custom header), Multiple Headers Auth (for servers that need more than one, like an API key plus a username), OAuth2, or None if the server doesn't require authentication. If you're connecting to the MCP Server Trigger from the earlier post, choose Bearer Auth and use the same token you generated there.

Step 4: Choose which tools to expose

The Tools to Include field controls how much of the external server's tool catalog the agent sees:

• All — every tool the server exposes is available to the agent.
• Selected — pick specific tools by name, and only those are exposed.
• All Except — expose everything except the tools you list in Tools to Exclude.

Start with Selected and pick one tool while you're testing. An agent handed a large, unfiltered tool list is more likely to call the wrong one — narrowing the set is often the fastest fix if the agent seems to guess instead of reasoning about which tool applies.

Step 5: Test it from the agent's chat

Save and activate the workflow, then open the AI Agent node's chat panel and ask for something that maps to one of the exposed tools, in plain English. If the connection and auth are correct, the agent lists the MCP server's tool(s) internally, calls the right one, and returns the result in its reply.

Tip: If the agent can't see any tools, double check the SSE endpoint first — a URL pointing at the base MCP path instead of the /sse suffix is the most common cause, and it fails silently rather than throwing a clear connection error.

What's next

A single AI Agent can hold multiple MCP Client Tool nodes side by side, each pointed at a different external server — combining your own n8n-hosted tools with a partner's or vendor's MCP server in one conversation. Between this node and the MCP Server Trigger from the earlier post, the same n8n instance can sit on both ends of an MCP connection: serving tools to one agent while consuming another's.

This walkthrough is for self-hosted instances you manage yourself — Docker or npm/pnpm installs. If you're on n8n Cloud, patching is handled for you.

Who's affected

Exploiting this requires an authenticated account with permission to create or modify workflows — it's not an unauthenticated, drive-by attack. But in many self-hosted setups that's a wide net: any teammate with workflow-editor access (not just admins) could trigger it, and a successful exploit runs commands as the n8n process itself, which can expose N8N_ENCRYPTION_KEY and, through it, every credential n8n has stored.

Affected versions: anything below 2.31.5, plus the 2.32.0 release specifically. Patched versions: 2.31.5 and 2.32.1 onward.

Notice the gap: 2.32.0 shipped after 2.31.5 but was itself vulnerable — patch level alone doesn't tell you the answer, you need the actual version string.

Step 1: Check your installed version

npm/pnpm install:

n8n --version

Docker:

docker exec <container-name> n8n --version

Step 2: Run it against the affected ranges

Rather than eyeball the version number against two separate ranges, this script does the comparison for you and exits non-zero if you're exposed:

#!/usr/bin/env bash
# Checks an n8n version string against GHSA-gv7g-jm28-cr3m's affected ranges:
#   vulnerable: <2.31.5  OR  >=2.32.0,<2.32.1
set -euo pipefail

version="${1:?Usage: check-n8n-version.sh <n8n-version>}"

ver_lt() {
  [ "$1" = "$2" ] && return 1
  lower=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
  [ "$lower" = "$1" ]
}

ver_ge() { ! ver_lt "$1" "$2"; }

if ver_lt "$version" "2.31.5"; then
  echo "VULNERABLE: $version is below 2.31.5"
  exit 1
elif ver_ge "$version" "2.32.0" && ver_lt "$version" "2.32.1"; then
  echo "VULNERABLE: $version is in the 2.32.0 pre-patch range"
  exit 1
else
  echo "OK: $version is patched against GHSA-gv7g-jm28-cr3m"
  exit 0
fi

Save it as check-n8n-version.sh, then pipe your actual version straight in:

chmod +x check-n8n-version.sh
./check-n8n-version.sh "$(n8n --version)"
# or, for Docker:
./check-n8n-version.sh "$(docker exec <container-name> n8n --version)"

Step 3: Patch

Docker / Docker Compose — pin the image tag to a patched version and redeploy:

# docker-compose.yml
services:
  n8n:
    image: n8nio/n8n:2.32.1   # or 2.31.5 if you need to stay on the 2.31.x train

docker compose pull
docker compose up -d

npm/pnpm global install:

npm install -g n8n@2.32.1

Step 4: Confirm the patch took

Re-run the same check — it should now report OK:

./check-n8n-version.sh "$(n8n --version)"

If you can't upgrade right away

The advisory's own workaround, worth noting because it's only partial: restrict workflow creation and editing to accounts you fully trust, since exploitation requires that permission. It doesn't close the hole — anyone who still has editor access can still trigger it — so treat it as a stopgap until you patch, not a substitute for patching.

If keeping up with patches like this one indefinitely isn't something you want to own yourself, n8n Cloud handles this one — and every future one — for you automatically.

Disclosure: the n8n Cloud link above is an affiliate link — if you sign up through it, we may earn a commission at no extra cost to you. See our affiliate disclosure for details.

What's next

If you're running n8n behind the MCP Server Trigger setup, the same principle applies doubly: an MCP client that can create or edit workflows through that surface has the same permissions this vulnerability requires, so keep both patched and access-scoped together.

Before you start

You'll need a running n8n instance (Cloud, self-hosted Community Edition, or Enterprise all support the MCP Server Trigger node — a free n8n Cloud trial is the fastest way to get one if you don't have an instance yet) and an MCP client to test with — this walkthrough uses Claude Desktop. No community nodes or extra installs are required on the n8n side; the node ships in n8n's built-in LangChain node package.

Disclosure: the n8n Cloud link above is an affiliate link — if you sign up through it, we may earn a commission at no extra cost to you. See our affiliate disclosure for details.

Step 1: Add the MCP Server Trigger node

Create a new workflow and add the MCP Server Trigger node as its starting point. Unlike a normal trigger, this node doesn't fire on a schedule or a webhook — it stays listening, and its only job is to expose whatever tool nodes you connect to it.

Open the node's panel and note the Path field: by default it's a randomly generated segment of the MCP URL, which is fine for a first test. You can set a fixed path later if you want a stable URL to hand out.

Step 2: Expose a workflow as a tool

The trigger does nothing on its own — it needs at least one tool node connected to it. Add a Custom n8n Workflow Tool node and point it at the workflow you want the assistant to run (this can be the same workflow, or a separate one you've already built, like the folder-watcher from an earlier post).

Give the tool a clear Name and Description. The description is what the AI actually reads to decide when to call it — write it the way you'd explain the tool to a new teammate: what it does, and when to use it. A vague description gets skipped or misused; a specific one ("Archives a file at the given path into the archive folder") gets called at the right moment.

Step 3: Secure it with Bearer auth

An MCP endpoint with no authentication is an open door into your automations — anyone with the URL can call your tools. In the MCP Server Trigger node, set Authentication to Bearer Auth, then create a new credential and generate a token. Keep the token in the credential, not pasted into the workflow body.

Save and activate the workflow. With the workflow active, reopen the trigger node panel — it now shows the live MCP URL and the Bearer Token you'll need for the next step.

Step 4: Connect an MCP client

Claude Desktop (like most current MCP clients) expects a local process it can talk to over stdio, not a raw HTTPS URL, so you bridge the two with mcp-remote, a small proxy built for exactly this. Add an entry to your claude_desktop_config.json:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://your-n8n-instance.example.com/mcp/<your-path>/sse",
        "--header",
        "Authorization: Bearer ${N8N_MCP_TOKEN}"
      ]
    }
  }
}

Replace the URL with the MCP URL from Step 3, and set N8N_MCP_TOKEN in your environment to the Bearer token. Save the file and restart Claude Desktop — it reads this config on launch.

Step 5: Trigger it with a plain-English prompt

Open a new chat in Claude Desktop and ask for the thing your tool does, in ordinary language — no slash commands, no JSON. If your tool description was specific, Claude recognizes it needs your n8n tool, calls it with the right input, and reports back what happened. Check the n8n execution log for the run to confirm it actually fired and see exactly what input the assistant sent.

Tip: If Claude doesn't call the tool when you expect it to, the description is almost always the fix — not the prompt. Make it more concrete about what the tool does and what kind of request it applies to.

What's next

One workflow behind one tool is the starting point. The same MCP Server Trigger accepts multiple Custom n8n Workflow Tool nodes, so a single MCP connection can expose your whole library of automations to an assistant at once — letting you describe a multi-step task in plain English and have it call several of your workflows in sequence.

Before you start

You'll need Python 3.9+ and two packages:

pip install pillow watchdog

Pillow handles the actual image processing; watchdog is what lets the script react to new files instead of polling the folder on a timer.

Step 1: Write the handler

# resize_watch.py
from PIL import Image
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler

MAX_WIDTH = 1600
QUALITY = 82

class ImageHandler(FileSystemEventHandler):
    def on_created(self, event):
        if not event.src_path.lower().endswith((".jpg", ".jpeg", ".png")):
            return
        img = Image.open(event.src_path)
        if img.width > MAX_WIDTH:
            ratio = MAX_WIDTH / img.width
            img = img.resize((MAX_WIDTH, int(img.height * ratio)))
        img.save(event.src_path, optimize=True, quality=QUALITY)

observer = Observer()
observer.schedule(ImageHandler(), path="./incoming", recursive=False)
observer.start()

Step 2: Run it

python resize_watch.py

Drop a large JPEG into ./incoming and watch it shrink in place within a second or two.

Tip: on_created fires as soon as the file starts being written, which can catch a still-copying file on a slow network drive. If you're watching a folder fed by uploads over a slow connection, add a short delay or check the file size is stable before processing.

What's next

For a one-off batch instead of a always-running watcher, drop the watchdog part entirely and just loop over os.listdir() — that version fits neatly into an n8n Execute Command node, so you can trigger it from the same kind of workflow covered in the Stripe-to-Sheets tutorial.

Before you start

You'll need an n8n instance (local or cloud — a free n8n Cloud trial is the fastest way to get one), a Stripe account, and a Google account with a Sheet ready to receive rows.

Disclosure: the n8n Cloud link above is an affiliate link — if you sign up through it, we may earn a commission at no extra cost to you. See our affiliate disclosure for details.

Step 1: Add the Stripe trigger

Create a new workflow and add a Stripe Trigger node. Connect your Stripe account (an API key from the Stripe dashboard), and set the event to customer.created. This fires the workflow the moment someone new signs up or makes a purchase.

Step 2: Map the fields you want

Add a Google Sheets node after the trigger, set the operation to Append Row, and point it at your sheet. Map the columns using the data Stripe already sent through:

Name:    {{$json["name"]}}
Email:   {{$json["email"]}}
Created: {{$json["created"]}}

n8n resolves these expressions against the trigger's output automatically — no transformation step needed for a simple case like this.

Step 3: Test it

Use Stripe's test mode to create a customer, then check the workflow's execution log in n8n. You'll see exactly what Stripe sent and what got written to the sheet — useful for catching a field name mismatch before it happens with a real customer.

Tip: Turn on the workflow's Active toggle before trusting it in production. A workflow that only runs when you manually execute it in the editor won't catch real Stripe events.

What's next

The same trigger works for a Slack notification — add a Slack node in parallel with the Google Sheets node and you'll get pinged the moment someone new signs up, no extra Stripe configuration required.

Before you start

You'll need PowerShell 5.1+ (built into Windows Server) and SMTP credentials for sending mail — an app password if you're using Microsoft 365 or Gmail, or your internal relay if you have one.

Step 1: Write the check

Each check appends to an $issues array only when something crosses a threshold. Nothing gets added when things are fine, which is what keeps the email quiet on a normal day.

# health-check.ps1
$diskThreshold = 15    # percent free
$memThreshold  = 10    # percent free
$services = @("W3SVC", "MSSQLSERVER", "Spooler")

$issues = @()

Get-PSDrive -PSProvider FileSystem | ForEach-Object {
    $freePct = ($_.Free / ($_.Free + $_.Used)) * 100
    if ($freePct -lt $diskThreshold) {
        $issues += "Drive $($_.Name): $([math]::Round($freePct,1))% free"
    }
}

$os = Get-CimInstance Win32_OperatingSystem
$memPct = ($os.FreePhysicalMemory / $os.TotalVisibleMemorySize) * 100
if ($memPct -lt $memThreshold) {
    $issues += "Memory: $([math]::Round($memPct,1))% free"
}

foreach ($svc in $services) {
    $status = Get-Service -Name $svc -ErrorAction SilentlyContinue
    if (-not $status -or $status.Status -ne "Running") {
        $issues += "Service $svc is not running"
    }
}

Step 2: Only email when there's something to say

if ($issues.Count -gt 0) {
    Send-MailMessage -To "you@solutionscraft.com" -From "server-alerts@yourdomain.com" `
        -Subject "Server health check: $($issues.Count) issue(s)" `
        -Body ($issues -join "`n") `
        -SmtpServer "smtp.yourprovider.com" -Port 587 -UseSsl `
        -Credential (Get-StoredCredential -Target "smtp-alerts")
}

Tip: Don't hardcode the SMTP password in the script. Get-StoredCredential (from the CredentialManager module) pulls it from Windows Credential Manager instead, so the script stays safe to commit or share.

Step 3: Run it on a schedule

Register it as a scheduled task so it runs without you:

$action = New-ScheduledTaskAction -Execute "powershell.exe" `
    -Argument "-File C:\Scripts\health-check.ps1"
$trigger = New-ScheduledTaskTrigger -Daily -At 8am
Register-ScheduledTask -TaskName "ServerHealthCheck" -Action $action -Trigger $trigger

What's next

If you're monitoring more than a couple of servers, this is also a good candidate for an n8n Execute Command node instead of Task Scheduler — you get a run history and retry logic for free, the same tradeoff covered in the n8n workflow tutorial.

Before you start

You'll need a running n8n instance (local, or self-hosted on a cheap VPS) and about fifteen minutes. This walkthrough uses the desktop app, but the steps are identical in n8n Cloud — the fastest way to get one running if you don't already have an instance is a free n8n Cloud trial.

Disclosure: the n8n Cloud link above is an affiliate link — if you sign up through it, we may earn a commission at no extra cost to you. See our affiliate disclosure for details.

Step 1: Add a folder trigger

Create a new workflow and add a Local File Trigger node. Point it at the folder you want to watch, and set the trigger event to "file added." This node polls the folder on an interval and fires the workflow whenever something new shows up.

Step 2: Move the file

Add a Move Binary Data node after the trigger, pointed at an archive/ subfolder. At this point you already have a working automation — no script required.

Step 3: Add the parts n8n can't do alone

Sometimes you need logic that's easier to write than to wire together visually — renaming files based on content, computing a checksum, whatever your case needs. Drop in an Execute Command node and call a small script:

# watch-folder.py
import shutil, pathlib

def archive(path: str) -> None:
    shutil.move(path, "./archive/")

Tip: Run this as a scheduled n8n workflow rather than a cron job — you get retry logic and a visual run history for free, and it's one less thing running outside of something you can see.

Step 4: Test it

Drop a file into the watched folder and confirm it lands in archive/ within a few seconds. Check the n8n execution log — every run is recorded, with the exact input and output of each node, which makes debugging a lot faster than a bare cron job with no output.

What's next

From here, the natural extensions are a Slack or email notification when a file lands in the archive, and swapping the local trigger for an S3 or Google Drive trigger if your files don't live on the same machine as n8n. Both are covered in upcoming posts.