Execute Workflow node in n8n: migrating off Local File and URL before removal

Since n8n 2.34, released on August 4, 2026, a deprecation banner shows up in the editor on any Execute Workflow node (also called Execute Sub-workflow) whose source is set to Local File or URL. The message suggests switching to the Database source — or, failing that, pasting the sub-workflow's JSON directly through the Parameter source. Nothing breaks today: it's a warning, not a removal. But two reasons make this migration more pressing than a mere interface tidy-up — one architectural, the other about security.

What's actually changing

The Execute Workflow node offers four ways to point to the sub-workflow it should run:

• Database — select an existing workflow in the instance, from a list or by ID.
• Local File — point to a JSON file's path on the n8n server's disk.
• URL — point to a JSON file reachable over HTTP.
• Parameter — paste the workflow's JSON directly into the node's field.

The two now-deprecated options, Local File and URL, date back to the node's earliest versions (1.1 and earlier) — a time when n8n didn't yet offer as mature a way of handling sub-workflows as first-class database entities. Since then, the Database source has become the natural path: the sub-workflow lives like any other n8n workflow, versioned, visible in the list, editable in its own editor — exactly the setup described in our guide to sub-workflows.

Why n8n deprecates gently instead of cutting things off outright

Choosing a warning that precedes actual removal by several versions is not a small detail. Robbes, Lungu and Röthlisberger, in a landmark study presented at ACM SIGSOFT FSE in 2012, How Do Developers React to API Deprecation? The Case of a Smalltalk Ecosystem, found that a significant share of developers ignore deprecation messages or only act on them very late, often once the actual removal has already broken their code in production. That is exactly what n8n 2.34's warning phase is meant to prevent: a visible signal, with no removal date fixed in advance, giving existing workflows time to migrate before some future major version actually drops these two sources.

In practice, as long as no major version announces the removal in its breaking changes (the same kind of announcement documented for the n8n 2.0 release), the Local File and URL sources keep working. But not migrating means postponing exactly the risk the study describes: discovering the breakage at update time, rather than handling it now, calmly.

The security angle the banner doesn't mention

The deprecation of Local File didn't come out of nowhere: it follows a security advisory, GHSA-2vx9-7wpg-88jq, fixed in n8n 2.19.3 and 2.20.0. The Execute Workflow node's Local File option read a workflow file from disk without applying the same checks as n8n's other file-reading nodes — in particular, it didn't respect the N8N_RESTRICT_FILE_ACCESS_TO restriction, documented in our environment variables guide and in our Read/Write Files from Disk node guide. A user authorized to create or edit workflows could supply an arbitrary path through the REST API — the UI had already hidden the option since version 1.2, but the API still accepted it — and thereby check for the existence of files on the host server, or even load and run a workflow JSON file found at that path.

This isn't an isolated case: a recent study by Akhoundali, Hamidi, Rietveld and Gadyatskaya, Eradicating the Unseen: Detecting, Exploiting, and Remediating a Path Traversal Vulnerability across GitHub (2025), identified more than 1,700 open-source Node.js projects affected by a comparable code pattern — a file path built from insufficiently validated input. Since n8n is itself a Node.js application, this advisory illustrates the same pattern playing out in one of its own core nodes rather than in a third-party project. The lesson goes beyond the Execute Workflow node alone: any field that accepts a path or a URL deserves an explicit review of what can actually feed it.

How to migrate

1. Find the affected nodes. There's no built-in search for "every Execute Workflow node on Local File source" in the editor: the most reliable way is to export your workflows through the REST API or in bulk (CLI or API, as described in our import/export guide), then grep the exported JSON for "source": "localFile" or "source": "url". On an instance with several dozen workflows, that's far faster than opening every canvas one by one.

2. Switch to Database. If the referenced JSON file corresponds to a workflow that already exists in the instance, open the node, change the Source field to Database, then select that workflow from the list (or paste its ID if you know it). If the file doesn't correspond to any workflow imported yet, import it first — via Import from File in the editor, exactly as described in our import/export guide — then reference the workflow it creates.

3. Reserve Parameter for genuinely dynamic cases. If the sub-workflow's JSON is generated on the fly by an external system and isn't meant to exist as a separate n8n workflow, the Parameter source remains legitimate: it depends on neither a disk path nor a URL, only on the content pasted into the node.

4. Verify behavior after switching. A sub-workflow called through the Database source responds exactly the same way as through Local File or URL once the switch is made — still, test the full run, especially if the called workflow relied on specific item identifiers or an execution mode (Run Once for All Items / for Each Item) sensitive to the input's structure.

5. Add this check to your update routine. Our n8n Docker update method already recommends reading the breaking changes before every major version upgrade — that's exactly the habit that will catch the eventual announcement of these two sources' actual removal before it surprises anyone.

Use cases with the FlowKit packs

The workflows shipped in our packs already split their pipelines into separate blocks following the sub-workflow principle — the RAG Assistant Pack (€119) separates document ingestion from the conversation chatbot, for instance. Those links are built on the Database source from the start, for the simple reason that it's the most stable way to reference a sub-workflow on an instance that keeps evolving. For a consultant or agency maintaining automations for several clients, the Compliance & Audit Pack (€149) applies the same traceability principle to the audit trail itself: every step timestamped in the database rather than scattered across loose files. Both packs, together with the Inbox AI Pack (€79), are bundled in the Complete FlowKit Bundle (€269 instead of €347 bought separately).

Wrapping up

The deprecation banner that appeared in n8n 2.34 on the Execute Workflow node's Local File and URL sources isn't a mere architectural preference: it follows a real security flaw, fixed several versions ago, and it announces a removal that, if other software ecosystems' experience is any guide, will mostly catch out those who ignored the warning until the major update that triggers it. Migrating to the Database source — or Parameter for genuinely dynamic cases — takes a few minutes per affected workflow, and removes a fragile dependency on a file path or URL that n8n wasn't validating as strictly as its other file-reading nodes.