Importing and exporting n8n workflows: JSON, CLI, API and templates without surprises

Everything you build in n8n is a JSON document: nodes, connections, parameters, canvas positions. That transparency is one of the tool's great strengths — it makes workflows portable: shareable with a colleague, versionable in Git, movable from dev to prod, publishable as a template. You just need to know the four import/export mechanisms and their traps (credentials, IDs, node versions). Treating automation as code isn't mere elegance: the study by Hilton et al. presented at the ASE conference in 2016 ("Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects", see on Google Scholar) showed, across thousands of projects, that teams who tool their integration-delivery cycle release more often with fewer defects — exactly what an n8n team gains by exporting, versioning and redeploying workflows instead of hand-editing them in production.

Method 1: the UI, for everyday use

In the editor, the workflow menu offers Download (get the JSON) and Import from File / Import from URL. That's the natural path for sharing a complete workflow or picking up a colleague's. Two subtleties:

• Importing into an open workflow replaces its content; to keep the existing one, create a blank workflow first.
• The JSON carries credential references (name + ID), never the secrets: on the target instance, each node flagged in error waits for a local credential to be reassigned. Good news for security — consistent with the principles in our guide to securing credentials.

Absolutely worth knowing: node copy-paste. Select nodes in the canvas, copy, paste into any other instance: the clipboard carries the JSON, connections included. Ideal for reusing a proven block — a standard error-handling stage, a complete AI section.

Method 2: the CLI, for backups and migrations

On a self-hosted instance, the command line exports and imports in bulk:

# Export all workflows, one file per workflow
n8n export:workflow --all --separate --output=./backup/workflows/

# Re-import a whole folder
n8n import:workflow --separate --input=./backup/workflows/

Key difference from the UI: the CLI preserves IDs — re-importing an export updates existing workflows instead of creating copies. That's the behavior you want for restoration and cross-environment sync. The CLI can also export credentials (encrypted by default); handle the decryption option with the caution it deserves and keep those exports out of any Git repository. For a complete backup strategy — database included — see our guide to backing up and restoring a self-hosted instance.

Method 3: the REST API, for automation

n8n's public API exposes workflows for reading and writing: a GET /workflows retrieves the definitions, a POST creates them. It's the building block of advanced scenarios: automated promotion from dev to prod, continuous backup to Git (an n8n workflow exporting the n8n workflows — and yes, that works very well), and an inventory of active workflows for instance monitoring.

Method 4: templates, so you don't start from scratch

The n8n.io/workflows gallery holds thousands of templates importable in one click or by URL. Three checks before activating an imported template:

1. Credentials: everything must be recreated locally — normal and healthy.
2. Community nodes: some templates assume community nodes installed first; the editor flags unknown nodes.
3. Full review: hardcoded URLs, webhooks to regenerate, and — for any template touching your data — an understanding of every node before activation. A template is code you didn't write: treat it as such.

Our free workflows and the FlowKit packs follow exactly this standard JSON format: two-click import, credentials to wire, per-node documentation included.

The three traps that keep coming back

The version trap. A workflow exported from a recent n8n can use node versions unknown to an older instance. Align versions before migrating — our guide to updating n8n on Docker without breaking anything details the careful path.

The crossed-IDs trap. Two people trading exports on a shared instance end up overwriting each other. Agree on a single direction: Git as the source of truth, the instance as the deployment target — the full discipline is described in our dev/prod environments guide.

The "it worked in dev" trap. A successful import isn't a successful deployment: missing environment variables, unregistered webhooks, prod credentials with different permissions. After every import, one test execution per workflow, systematically — the reflex championed in our guide to workflow evaluations and testing.

Import/export is the gateway to n8n maturity: the day your workflows live in Git, deploy through the API and restore with one command, your automation stops being a collection of hacks and becomes a system.