DEV Community: SolutionsCraft

Turn Instagram Comments Into DMs With n8n

SolutionsCraft — Fri, 02 Oct 2026 09:00:00 +0000

"Comment LINK and I'll send it to you!" works great for engagement, right up until you're the one copy-pasting the same DM forty times an hour, and inevitably missing a few in the scroll. Instagram comment-to-DM automation fixes exactly this: a keyword in a comment triggers a workflow that replies publicly and privately messages the commenter, in the seconds after they post, every time, with nobody at the keyboard.

This walkthrough builds the whole thing on n8n and Meta's own Graph API, no third-party automation SaaS in the middle. It's more setup than a no-code app promises, but it's also the same API those apps are calling behind the scenes, so you're not trading capability for control.

Before you start

You'll need an n8n instance (a free n8n Cloud trial works fine for this, and if this is your first time wiring up an n8n webhook from scratch, the folder-watcher walkthrough covers the editor basics this one builds on) and an Instagram Professional (Business or Creator) account. You'll also need a Meta Developer App with the Instagram product added, so create one at developers.facebook.com if you don't have one yet.

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.

One thing worth knowing before you sink an evening into this: sending the private DM needs the instagram_manage_messages permission, and Meta classes it as a sensitive scope. In development mode it works fine against your own account and any test users you've added, but taking it live for real commenters means submitting the app for App Review first, and reviews for messaging permissions routinely take longer than the more common scopes. Budget for that lag before you promise this to anyone.

Step 1: Wire up the comment-to-DM automation webhook

In your Meta app, open Webhooks, choose the Instagram product, and subscribe to the comments field. It'll ask for a callback URL and a verify token, both of which point at an n8n Webhook node you create for this, so turn on "Allow Multiple HTTP Methods" on that node so it accepts both the one-time verification GET and the real POST events afterward.

Meta's verification handshake is simple but exacting: it sends a GET with hub.mode, hub.verify_token, and hub.challenge query params, and expects the raw hub.challenge value echoed back as plain text if your token matches, not JSON, not wrapped in anything else. Branch on the HTTP method with an IF node, and on the GET branch use a Respond to Webhook node set to "Text" with the response body {{ $json.query["hub.challenge"] }}, guarded by a check that $json.query["hub.verify_token"] matches the token you set in the Meta dashboard.

I don't have a live Meta app to fire a real request at in this environment, so I tested that matching logic standalone against the exact shape Meta's docs describe, rather than n8n's actual node internals:

function handleVerification(query, expectedVerifyToken) {
  if (query["hub.mode"] === "subscribe" && query["hub.verify_token"] === expectedVerifyToken) {
    return { status: 200, body: String(query["hub.challenge"]) };
  }
  return { status: 403, body: "Verification failed" };
}

// handleVerification({ "hub.mode": "subscribe", "hub.verify_token": "my-secret", "hub.challenge": "12345" }, "my-secret")
// -> { status: 200, body: "12345" }

Ran that in plain Node against a matching token and a deliberately wrong one, and it echoes the challenge only when the token lines up, 403s otherwise, which is exactly the contract Meta's docs describe.

Step 2: Filter for your trigger keyword

Every comment on every post you own fires this webhook, so the next node's job is to throw out everything that isn't the keyword you care about, and to ignore the echo of your own reply so the workflow doesn't loop on itself. Add a Code node on the POST branch:

const entry = $input.first().json.body.entry?.[0];
const change = entry?.changes?.[0];
if (!change || change.field !== "comments") return [];

const value = change.value;
const OWN_IG_USER_ID = "<your IG user id>";
if (value.from?.id === OWN_IG_USER_ID) return [];

const KEYWORDS = ["link", "guide"];
const text = (value.text || "").toLowerCase();
const matched = KEYWORDS.some((k) => text.includes(k));
if (!matched) return [];

return [{
  json: {
    commentId: value.id,
    commenterId: value.from?.id,
    commenterUsername: value.from?.username,
    text: value.text,
  },
}];

Blip: Somewhere a spec writer decided a webhook that fires on your own reply, right after you reply, was a feature and not a trap. Check the sender id, always.

I verified this filtering logic (case-insensitive keyword match, and skipping the account's own comments) as a standalone script against a sample payload shaped like Meta's documented comments webhook, and a match returns the parsed fields while a non-match and a self-authored comment both correctly return nothing. Wiring the exact same logic into an n8n Code node is a direct port, not a rewrite, but the live n8n execution itself isn't something I ran here.

Step 3: Reply publicly first

A public reply keeps the conversation visible under the post, a bit of social proof for the next person scrolling by, and it's the same endpoint whether or not you go on to DM anyone. Add an HTTP Request node:

POST https://graph.instagram.com/v21.0/{{ $json.commentId }}/replies
Authorization: Bearer <your Instagram access token>
Content-Type: application/json

{ "message": "Sent you a DM with the link! 📩" }

Step 4: Send the private DM

This is the actual comment-to-DM automation piece, turning that public comment into a private message without the commenter ever having messaged you first. Instagram's Messaging API supports exactly one flow for this: a private reply, sent from your own IG account's /messages endpoint but addressed by comment ID rather than by the commenter's user ID, in another HTTP Request node:

POST https://graph.instagram.com/v21.0/{{ $json.myIgUserId }}/messages
Authorization: Bearer <your Instagram access token>
Content-Type: application/json

{
  "recipient": { "comment_id": "{{ $json.commentId }}" },
  "message": { "text": "Here's the link: https://solutionscraft.com/newsletter" }
}

{{ $json.myIgUserId }} here is your own Instagram business account's user ID (the same value you'd hardcode as OWN_IG_USER_ID in Step 2), not the commenter's, since the endpoint is scoped to your account and the recipient is identified through the comment_id in the body instead.

Two hard limits worth planning around, straight from Meta's docs: you can only private-reply to a comment within 7 days of it being posted, and you only get one private reply per comment, ever. Send it once and that comment's window is closed for good, so this isn't a node you want firing twice on a retry.

Step 5: Land the DM link on a page, not an API call

It's tempting to have the DM link straight into your own signup API to skip a step, but don't point it at an endpoint sitting behind bot protection. Ours, like most newsletter signup forms, is gated by Cloudflare Turnstile, which needs an actual browser solving a challenge, something no link click can do on its own. Send the DM to your normal newsletter signup page instead, and let the page's existing form (Turnstile check, Resend contact creation, automatic welcome email) do the rest exactly the way a human visitor triggers it. The automation's job ends at getting a warm click into that page, not at replacing the page.

What this doesn't solve

This catches new comments going forward, not a backlog of ones posted before the webhook was live, and it won't touch anything if you edit an existing comment. Instagram also caps API calls at 200 per user per hour (down from the 5,000 you'll see quoted in older tutorials), so a viral post with the keyword in a huge share of the comments can outrun this well before it outruns your patience. And the 7-day/one-reply limits from Step 4 mean this is a first-touch tool, so anything past the initial DM needs a real conversation, not another automated message.

Where to start

Wire up Steps 1 and 2 first and just watch the executions log for a day against your own comments, confirming the keyword filter catches the right ones and ignores your own replies before you let Step 4 actually message a stranger. Once that's solid, turn on the public reply and private DM, and treat App Review for instagram_manage_messages as the thing to submit in parallel, not after, since it's the step most likely to make you wait. If you'd rather point n8n itself at an AI assistant once this is running, connecting n8n's instance-level MCP to Claude Desktop covers asking it to inspect or adjust a workflow like this one in plain English.

n8n Instance MCP Now Lets Claude Drive

SolutionsCraft — Fri, 02 Oct 2026 09:00:00 +0000

Two earlier posts on this site covered MCP one workflow at a time. The MCP Server Trigger exposes a single workflow as a tool, and the MCP Client Tool lets an n8n Agent call an external server. Both work fine, but they share the same limit: every new workflow you want an AI assistant to reach means wiring up another trigger, another credential, and another URL to hand out. n8n's instance-level MCP skips all of that. Connect once, with OAuth, and Claude gets a single door into your whole n8n instance instead of a separate one per workflow.

That's a bigger grant than a single-workflow tool, so this post covers both how to turn it on and how to keep it scoped to what you actually want an assistant touching.

Before you start

You'll need an n8n instance on a version that supports instance-level MCP. It's been available since 2.18.4 on self-hosted Community Edition (and on Cloud and Enterprise from around the same time), with OAuth added as the recommended connection method in 2.31.0. If you're on an older self-hosted version, update first. If you don't have an instance at all yet, a free n8n Cloud trial gets you one on a current release, instance-level MCP included. You'll also need instance owner or admin permissions (a regular member can't enable this) and Claude Desktop installed on your machine.

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: Turn on instance-level MCP

Go to Settings > Instance-level MCP and select Enable MCP access. On a self-hosted instance you can do the same thing at deploy time instead, by setting the environment variable N8N_MCP_ACCESS_ENABLED=true (available from 2.20.0). That's the better option if you provision instances by config rather than clicking through the UI after every deploy.

Nothing is exposed yet at this point. Enabling the feature just makes the MCP server exist, it doesn't hand any workflow to it.

Step 2: Decide which workflows Claude can see

Open any workflow, click its main ... menu in the top-right corner, choose Settings, and flip on Available in MCP. That single workflow now shows up as something an MCP client can find and act on. You can do the same from the workflows list: open a workflow card's menu and pick Enable MCP access, or select several workflows at once and use the Enable workflows button in the table header to expose a whole project or folder at once.

Blip: There's also an "Auto-expose new workflows" toggle back in Settings, which quietly hands Claude every workflow you build from now on. Convenient. Also exactly the kind of setting worth remembering you turned on.

If you'd rather opt in per workflow than trust your future self to remember an auto-expose toggle, leave that setting off and come back to Step 2 each time you build something you want the assistant to reach.

Step 3: Generate the connection details

Back in Settings > Instance-level MCP, open Connection details and select Connect. This opens the Connect a client dialog. Confirm you're on the OAuth (recommended) tab. The alternative Access Token tab issues one long-lived bearer token instead, which works but can't be revoked per client the way an OAuth connection can, so a leaked token means rotating access for everyone who uses it, not just the one client that leaked it.

In the Your client dropdown, choose Claude Desktop. n8n shows you a Server URL value tailored to that client. This is the address Claude Desktop authenticates against, not something you construct by hand.

Step 4: Add n8n as a custom connector in Claude Desktop

In Claude Desktop, open Settings > Connectors and select Add custom connector. Give it a name ("n8n MCP" is fine) and paste the Server URL from Step 3 in as the Remote MCP Server URL. Save it, and Claude Desktop prompts you to authorize access to your n8n instance. Approve it, and the OAuth handshake completes without you ever touching a token or a config file by hand.

This is where instance-level MCP earns its keep over the single-workflow trigger from the earlier post. There, you were editing claude_desktop_config.json directly and copying a bearer token into an environment variable. Here, the whole connection is a name, a URL, and one authorization click.

Tip: if Claude Desktop connects but can't see any workflows, the fix is almost always Step 2, not the connection itself. Instance-level MCP access and per-workflow "Available in MCP" are two separate switches, and it's easy to flip the first without the second.

Step 5: Try it from a plain-English prompt

Open a new chat in Claude Desktop and ask for something that maps to a workflow you exposed in Step 2. "What workflows do I have that touch Stripe" is a reasonable first test, since it only needs read access. If the connection is set up right, Claude lists and inspects your workflows without you naming a specific tool.

From n8n 2.13.0 onward, MCP clients can also build and edit workflows, not just run existing ones, so a prompt like "create a workflow that watches a folder and archives new files" can result in Claude actually assembling nodes in your instance. Check what it produces before you activate it, the same way you'd review a pull request from a new teammate rather than merging it on trust.

Step 6: Review and scope what you granted

Each client that connects only gets the permissions it asked for and you approved during that OAuth handshake. Reading workflows without being able to create or run them is a valid, narrower grant than full read, build, and execute access, and it's worth choosing deliberately rather than accepting whatever the default happens to be.

To see what's actually connected, go back to Settings > Instance-level MCP, open Connected clients, and select View all. You get a table of every OAuth client, its access level, and when it connected, plus a revoke action for anything that shouldn't have access anymore. Get in the habit of checking this table the way you'd check any other service with standing access to your systems, not just once at setup, the same instinct worth applying to auditing an instance for leaked API tokens: a one-time check is worth less than a habit.

If you're running self-hosted behind a dedicated hostname (say, n8n-mcp.example.com in front of the same instance, rather than your normal editor URL), set N8N_MCP_BASE_URL to that address (available from 2.31.0). n8n advertises that URL during OAuth instead of the instance's default base URL, so clients authenticate against the address you actually intend them to hit.

Before you hand over the keys

Instance-level MCP is the right tool when you want an assistant working across your automations generally: "find the workflow that does X" or "build me something new," rather than being scoped to one job. That's also exactly why it deserves more caution than the single-workflow MCP Server Trigger from the earlier post. A client with build and edit access here can, in principle, touch anything you exposed to it, not just answer questions about it, and a workflow it builds for you is one you're choosing to trust before you activate.

Start narrow. Expose the handful of workflows you actually want an assistant reasoning about, leave "Auto-expose new workflows" off until you trust the habit of reviewing what gets shared, and check the Connected clients table every so often. Once that scope feels right, instance-level MCP is the version of "ask n8n to do something in plain English" that scales past a single workflow, which is the whole point of connecting it this way in the first place.

n8n's Expression Engine Just Got Stricter

SolutionsCraft — Fri, 25 Sep 2026 09:00:00 +0000

You upgrade n8n, nothing in the changelog looks scary, and a week later a workflow that's run quietly for months starts throwing errors on an expression you haven't touched. Nobody edited it. The data feeding it didn't change shape. The only thing that moved is n8n itself, and buried in the 2.35.0 release notes is the line that explains it: n8n made its VM expression engine the default, replacing the older Tournament engine that had run every {{ }} expression since the beginning.

This one's worth taking seriously for a reason the Notion v3 migration wasn't: node versions are pinned per-workflow, so upgrading n8n doesn't silently change how an existing Notion node behaves. The expression engine isn't like that. It's set with an environment variable at the instance level, and it applies to every workflow's next execution the moment you're running 2.35.0 or later, whether or not you asked for it.

Before you start

You'll need shell or dashboard access to your n8n instance (to check its version and, if needed, set an environment variable) and edit access to the workflows you want to audit. This applies to self-hosted n8n; if you're on n8n Cloud, more on that at the end.

Step 1: Confirm you're actually on the new engine

Check your instance version first (Settings → About in the UI, or n8n --version from the CLI). Anything 2.35.0 or later is running the VM engine by default unless someone already set N8N_EXPRESSION_ENGINE=legacy. If you're below 2.35.0, this doesn't apply yet, but it will the moment you upgrade, so it's worth reading before you do rather than after something breaks.

Step 2: Understand what actually changed

Tournament and the new VM engine both run your expression as JavaScript, so the language itself hasn't changed. What changed is how errors during evaluation get handled. Tournament wraps every expression in a try/catch and, depending on the error type, would often swallow a failure quietly and resolve to undefined rather than stop the workflow. The VM engine runs expressions inside an actual isolated V8 context (via isolated-vm) with a hard memory limit (128MB by default) and execution timeout (5 seconds by default), and it's meaningfully stricter about which errors it lets pass silently versus which ones it re-throws.

Blip: A workflow that silently resolves to undefined and limps forward is a workflow with a bug you haven't found yet. I'd rather it just told me.

Blip's not wrong, but "stricter" still means workflows built around the old quiet-failure behavior are the ones at risk now. The pattern to look for is any expression that chains into a property that might not exist on every item, something that used to quietly become undefined and now has a real chance of throwing instead.

Step 3: Find the risky pattern in your workflows

The expressions most likely to behave differently are direct property chains with no guard, especially several levels deep or reaching into data that isn't guaranteed present on every item:

{{ $json.customer.address.city }}

If customer or address is ever missing on an item (a common shape for optional fields from an API, a webhook payload that varies by event type, or an upstream node that doesn't always return the same structure), this is exactly the kind of expression that could tolerate the gap quietly before and won't now. I confirmed the underlying JavaScript behavior directly, since both engines evaluate real JS under the hood:

const data = { customer: {} };
data.customer.address.city;
// Cannot read properties of undefined (reading 'city')

data.customer.address?.city;
// undefined, no throw

data.customer.address?.city ?? "Unknown";
// "Unknown"

Search your workflows for expressions with two or more chained . property accesses and no ?. anywhere in the chain. That's your audit list. Pay closest attention to workflows using an Error Trigger, or ones with sub-nodes that reference data from earlier in the flow across an AI Agent connection; paired-item resolution across those boundaries is one of the specific spots the n8n team had to patch for consistency between the two engines, which tells you it's a genuine edge case, not a hypothetical one.

Opening every workflow by hand to eyeball its expressions doesn't scale past a handful. If you're self-hosted and have CLI access, n8n's export:workflow command dumps every workflow to JSON in one shot, and from there it's a normal grep problem:

n8n export:workflow --all --output=./audit/
grep -roE '\{\{[^}]*\.[a-zA-Z_]+\.[a-zA-Z_]+[^}]*\}\}' ./audit/ | grep -v '?\.'

I tested this exact pattern against a sample workflow JSON with one guarded and one unguarded expression, and it correctly pulled only the unguarded one. It's a starting list, not a verdict (some flagged expressions will turn out fine once you check whether that particular field can actually be missing), but it turns "audit the instance" into "review a short list" instead of "click through every workflow."

Step 4: Fix what you find

For each risky expression, add optional chaining and a sensible fallback:

{{ $json.customer.address?.city ?? "Unknown" }}

This is a one-character-per-link change (?. instead of .) plus a ?? default at the end, and it makes the expression behave the same way under either engine: no silent undefined, no thrown error, just the fallback value you chose. If an expression is doing something more involved than a property chain (a multi-step transform, several fallbacks chained together), it's usually clearer, and easier to test, moved into a Code node instead, where you can wrap it in an actual try/catch and decide exactly what happens on failure.

Step 5: Use the rollback as a stopgap, not a fix

If you've just upgraded and don't have time to audit before your workflows run again, you can buy yourself room with an environment variable:

N8N_EXPRESSION_ENGINE=legacy

This restores Tournament's behavior instance-wide, immediately. Treat it as a pause button, not a destination. The VM engine is where n8n is investing going forward (it's also faster on repeated expressions thanks to code caching, and the isolation is a real security improvement), so the goal is auditing your way back to the default, not living on legacy indefinitely.

Tip: Set the variable, restart, confirm your previously-broken workflow runs clean again, then work through Step 3's audit list on your own schedule instead of your production traffic's.

Where to start

If you've already upgraded and something's actively failing, set N8N_EXPRESSION_ENGINE=legacy first to stop the bleeding, then work through Step 3's search for unguarded property chains before removing the rollback. If you haven't upgraded yet, do the audit now, while it's a code review instead of an incident. Either way, the fix is the same one-line change repeated as many times as your audit turns up. It's the same audit-before-it-bites-you shape as checking your instance for leaked n8n API tokens, just for an expression engine instead of a credential.

If you're on n8n Cloud, this engine switch already happened for you as part of a coordinated rollout n8n tested ahead of time. You don't control when it lands, but you also don't have to schedule the audit around your own upgrade timing. If owning that timing yourself isn't something you want to keep doing release after release, a free n8n Cloud trial is worth a look.

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.

Is Your n8n API Key Already Leaked?

SolutionsCraft — Fri, 18 Sep 2026 09:00:00 +0000

You copy an n8n API key into a .env file to test something quick, commit the whole folder because you're in a hurry, notice a minute later, and delete the file in the next commit. Problem solved, right? Except git doesn't forget. The key is still sitting in that first commit, reachable by anyone who can run git log -p against your history, whether or not it's still in the file today.

That's not a hypothetical. GitGuardian scanned public GitHub commits in early August 2026 and found 4,576 distinct n8n API tokens sitting out in the open, tied to 1,255 different hostnames. Of the 896 instances they could actually reach, 321 accepted at least one of the leaked tokens, no exploit required, no password guessing, just an unrotated token from an old commit. A valid token hands over workflows, execution history, stored data tables, and enough about your credentials to know exactly what to go after next.

This walkthrough covers two things: a script that actually finds n8n keys in your git history (not just anything that looks vaguely like a secret), and what to do once you find one.

Blip:"I deleted the file" and "I removed the secret" are not the same sentence. Git remembers the first draft even after you've moved on from it.

Before you start

You'll need shell access to a local clone of any repo you want to check, and access to your n8n instance's Settings > n8n API page for the rotation step later. No n8n instance changes happen until Step 3, so it's safe to run the scan against a repo without touching anything live yet.

Step 1: Know what you're looking for

n8n's public API keys are JWTs, they start with eyJ, the standard base64 prefix for JSON, followed by two more base64 segments separated by dots. That shape isn't unique to n8n, plenty of other services hand out JWTs too, so a naive "does this look like a token" grep gets noisy fast. What is specific to n8n is what's inside the payload: n8n signs its API keys with "iss": "n8n" and "aud": "public-api" claims. Decode the middle segment of any JWT and you can tell immediately whether it's one of these keys or something else entirely.

Step 2: Scan your git history

This is the part worth actually running, not just reading. It walks every commit (git log -p --all), pulls out anything shaped like a JWT, decodes each candidate's payload, and only flags the ones whose iss/aud claims match n8n's:

#!/usr/bin/env bash
# Scans the full git history (not just the working tree) of the current repo
# for n8n public API keys. n8n API keys are JWTs, so a plain "looks like a
# JWT" grep also catches unrelated tokens; this decodes each candidate's
# payload and only flags the ones whose issuer/audience claims match n8n's.
set -euo pipefail

candidates=$(git log -p --all -- . 2>/dev/null \
  | grep -oE 'eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+' \
  | sort -u || true)

if [-z "$candidates"]; then
  echo "No JWT-shaped strings found in git history."
  exit 0
fi

found=0
while IFS= read -r token; do
  payload_b64=$(echo "$token" | cut -d. -f2)
  padded=$(echo "$payload_b64" | tr '_-' '/+')
  case $(( ${#padded} % 4 )) in
    2) padded="${padded}==" ;;
    3) padded="${padded}=" ;;
  esac
  payload=$(echo "$padded" | base64 -d 2>/dev/null || true)

  if echo "$payload" | grep -q '"iss": *"n8n"' && echo "$payload" | grep -q '"aud": *"public-api"'; then
    found=$((found + 1))
    echo "FOUND n8n API key in git history: ${token:0:24}...${token: -8}"
    echo " payload: $payload"
  fi
done <<< "$candidates"

if ["$found" -eq 0]; then
  echo "No n8n API keys found (JWTs present but none matched n8n's issuer/audience claims)."
  exit 0
fi

echo ""
echo "$found n8n API key(s) found in git history. Deleting the file today does NOT remove"
echo "them, they're still reachable via 'git log -p' or any clone. Rotate every key found"
echo "here, then scrub history (git filter-repo / BFG) if this repo is or was ever public."
exit 1

Save it as scan-n8n-tokens.sh, chmod +x it, and run it from inside the repo you want to check:

./scan-n8n-tokens.sh

I tested this against two throwaway repos before writing it into this post. One had an n8n key committed and then "removed" in a later commit, exactly the scenario above, and the script caught it and printed the payload showing iss: n8n, aud: public-api. The other had a JWT-shaped decoy with a completely different issuer, and the script correctly ignored it, so you won't get paged for every unrelated token your history happens to contain. A clean repo with no JWTs at all reports that plainly and exits 0, so you can drop this into a pre-merge CI check without it crying wolf.

Run it against every repo that's ever touched an n8n key, including ones you've since made private. GitGuardian's numbers came from public GitHub commits specifically, but a repo you flipped to private after the fact doesn't retroactively un-leak anything that was already indexed or cloned while it was public.

Step 3: Rotate anything you find

If the scan turns up a hit, treat that key as burned, full stop, whether or not you can prove anyone actually used it. Rotation itself is a UI action in n8n, not something scriptable through the public API (you'd otherwise need a valid key just to revoke itself, which doesn't help you here):

Open Settings > n8n API on the affected instance.
Click Create an API key , give it a label you'll recognize later, and set an Expiration if your plan supports it, an expiring key limits exactly this kind of damage the next time a token slips into a commit.
Update every place that used the old key, your automation scripts, CI secrets, anywhere it was configured, to the new one.
Go back to Settings > n8n API , find the old key in the list, and select Delete next to it. It's revoked immediately.

Do this even if the leaked key is months old and "probably fine." GitGuardian's whole point was that these tokens don't expire on their own, an n8n API key created without an expiration date stays valid indefinitely until someone deletes it, so "probably fine" and "still fully valid" are the same thing from the token's perspective.

Step 4: Get it out of history too, if the repo was ever public

Rotating the key stops it from working, but the string itself is still sitting in your git history, which is untidy and, if this repo is open source or shared, worth cleaning up so the next contributor doesn't find it and wonder if it's still live. git filter-repo (or the older BFG Repo-Cleaner) can strip a specific string from every commit that ever contained it. This rewrites history, so it needs a force-push and coordination with anyone else who has the repo cloned, which is a bigger operation than this post covers, but it's the right follow-up once the immediate danger (a working, unrevoked key) is handled.

What this doesn't solve

Scanning your own repo's history only tells you what's true for that repo. It can't tell you whether someone already cloned it while the key was live, whether it's sitting in a CI log, a Slack message, or a support ticket screenshot, or whether it leaked through a channel that has nothing to do with git at all. Treat "I found it and rotated it" as closing the door you know about, not a guarantee nothing walked through it first.

It also won't catch a key that's still currently committed in your working tree, only what's reachable through history. Run a plain git grep for eyJ against your current checkout too, and consider adding GitHub's push protection (Settings > Code security > Push protection) on any repo that might touch one of these keys again, it blocks a commit containing a recognizable secret pattern before it ever reaches the remote, which is a much better place to stop this than a post-hoc scan.

Where to start

Run the scan today against every repo that has ever had an n8n key anywhere near it, not just the ones you remember. If it comes back clean, good, now you know, and it's a five-minute script you can rerun anytime you're not sure. If it finds something, rotate the key before you do anything else, the five minutes that takes is a lot cheaper than being one of the 321 instances that answered when GitGuardian knocked. It's one item on a short list of n8n instance-hardening checks worth running together, alongside the sandbox-escape vulnerability patch and the $fromAI prototype-leak escape hatch, both quiet-until-someone-finds-it bugs in the same vein as an unrotated key.

When n8n's $fromAI Becomes an Escape Hatch

SolutionsCraft — Fri, 11 Sep 2026 09:00:00 +0000

$fromAI() is the little function that makes n8n's AI Agent tools feel almost magic: instead of hardcoding a value in a tool's parameters, you write something like {{ $fromAI('city', 'the city the user asked about', 'string') }} and let the agent fill it in at call time based on what the user actually said. n8n's bi-weekly security update on 20 August 2026 disclosed that this exact helper had a hole in it. A crafted placeholder name could leak a live reference to one of n8n's own host prototypes, and from there, an attacker could walk the prototype chain up to the Function constructor and run arbitrary code as the n8n process. Rated High with a CVSS 4.0 score of 8.7, tracked as GHSA-9x83-43r8-5hwc.

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.

Migrate an n8n Notion Workflow to the v3 Node's Data Source Model

SolutionsCraft — Fri, 04 Sep 2026 09:00:00 +0000

Notion shipped a breaking change to its API: a database is no longer a single thing you query directly. It's now a container that holds one or more data sources , and the pages you actually want live under a data source, not the database itself. n8n's Notion node was overhauled to a new v3 to match — and the sharp edge is that database IDs are no longer accepted for database-page query or create operations. If a workflow you built a while back still points at a raw database ID once it's running on the new node version, those operations stop resolving.

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. The VM expression engine default change is the same shape from the other direction: a quiet default flip instead of a deprecated field, but the same discipline of auditing before you're forced to. For the security side of that same discipline, see auditing an n8n instance for leaked API tokens.

Connect an External MCP Server to an n8n AI Agent with the MCP Client Tool Node

SolutionsCraft — Fri, 28 Aug 2026 09:00:00 +0000

An earlier post covered the MCP Server Trigger node: turning an n8n workflow into a tool an external AI assistant can call. The MCP Client Tool node does the reverse — it lets an n8n AI Agent call tools hosted on someone else's MCP server, including a server you don't run in n8n at all. Point an agent at any MCP-compliant endpoint and its tools show up alongside your other n8n tool nodes, ready to be called mid-conversation.

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. If you'd rather expose your whole instance at once instead of wiring up tools workflow by workflow, n8n's instance-level MCP covers that broader connection.

Audit and Patch Your Self-Hosted n8n Instance Against the Sandbox-Escape Vulnerability

SolutionsCraft — Fri, 21 Aug 2026 09:00:00 +0000

n8n's Code node and expression editor run inside a sandbox specifically so that a workflow can't reach out and touch the host it's running on. In July 2026, n8n patched a high-severity bypass of that sandbox: crafted arrow-function expressions could escape it entirely and execute arbitrary operating-system commands with the privileges of the n8n process. Rated High with a CVSS 4.0 score of 8.7, no CVE number had been assigned as of the advisory's publication.

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.

Enable n8n's Built-In MCP Server and Build a Workflow From a Plain-English Prompt

SolutionsCraft — Fri, 14 Aug 2026 09:00:00 +0000

n8n ships a node that flips the usual direction of automation: instead of n8n calling out to an AI model, an AI assistant calls into n8n. The MCP Server Trigger node turns a workflow into a tool that any Model Context Protocol client — Claude Desktop, Claude Code, or anything else that speaks MCP — can discover and run. Ask the assistant in plain English, and it invokes your workflow directly.

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. For the reverse direction, an n8n AI Agent calling tools on someone else's server, see the MCP Client Tool walkthrough. And if wiring up one workflow at a time starts to feel limiting, n8n's instance-level MCP exposes the whole instance through a single OAuth connection instead.

Auto-Resize and Compress Images with a Python Watch-Folder Script

SolutionsCraft — Fri, 07 Aug 2026 12:00:00 +0000

Resizing images by hand before every upload gets old fast. This script watches a folder and does it the moment a file lands — drop a photo in, it comes out resized and compressed, ready to use.

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.

Sync New Stripe Customers to a Google Sheet with n8n

SolutionsCraft — Fri, 07 Aug 2026 11:00:00 +0000

If your "CRM" right now is remembering who paid you, this fixes that in about ten minutes with zero code. Every time someone becomes a Stripe customer, their details land in a Google Sheet automatically.

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. If this is your first time in the n8n editor, the folder-watcher walkthrough covers the basics this one assumes.

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. Worth pairing with a regular audit of your n8n instance for leaked API tokens too, since the Stripe key powering this trigger is exactly the kind of credential that matters if it ever ends up somewhere it shouldn't.

Automate Windows Server Health Checks with PowerShell and Email Alerts

SolutionsCraft — Fri, 07 Aug 2026 10:00:00 +0000

Checking server health by logging in and eyeballing Task Manager doesn't scale past one or two machines. This script checks disk space, memory, and a list of critical services, and only sends an email when something's actually wrong — not a daily "everything's fine" notification you'll learn to ignore within a week.

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

$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.