n8n is one of the few tools you genuinely own. The workflows, the credentials, the execution history - it all lives in a database and a data folder that you can pick up and move somewhere else. That portability is the whole point of self-hosting.

But “move it somewhere else” hides one landmine. n8n encrypts your credentials with a key that does not live in the database, and almost everyone who migrates for the first time copies the database, skips the key, and watches every credential break on the new server.

This guide walks through migrating a running n8n instance to InstaPods - whether you’re leaving n8n Cloud, Railway, Render, Elestio, or a Docker box you set up yourself - without losing a single workflow or credential. It also tells you honestly where a clean migration isn’t possible (looking at you, n8n Cloud) and what to do instead.

Before you start: the one thing that breaks n8n migrations

n8n encrypts every credential - API keys, OAuth tokens, database passwords - before saving them to its database. The key it uses lives in a file at ~/.n8n/config, not in the database itself.

Copy your database to a new server without bringing that key, and the new instance generates a fresh key on first boot. Your workflows load fine. But every credential fails to decrypt, and every workflow that touches one errors the moment it runs. You won’t see it until something fires at 3am.

There are two correct ways to deal with this, and the rest of the guide uses them:

  1. Export credentials in decrypted form and import them on the new host, which re-encrypts them under the new key. Cleanest path, no key surgery. This is what we recommend below.
  2. Carry the old encryption key over (set N8N_ENCRYPTION_KEY on the new host to the old value) before importing. Needed if you’re copying a raw database and want executions and everything preserved exactly.

Keep this in the back of your head. Everything else is mechanical.

What you’re actually moving

An n8n instance is more than its workflows. Here’s the full state, and how each piece travels:

WhatWhere it livesTravels how
WorkflowsDatabaseExport as JSON, or copy the DB
CredentialsDatabase (encrypted)Export decrypted, or copy DB + encryption key
Encryption key~/.n8n/config fileNever in the DB - must be handled explicitly
Execution historyDatabaseOnly if you copy the raw DB (usually skippable)
Binary data~/.n8n/binaryData/ (n8n 2.x default)Comes along if you copy the data folder
Env config (WEBHOOK_URL etc.)Environment variablesRe-set on the new host

Self-hosted n8n uses SQLite by default (a single ~/.n8n/database.sqlite file), with PostgreSQL as the only other supported option. If you never configured an external database, you’re on SQLite, and the whole thing is one folder.

First, know which kind of host you’re leaving

Your migration path depends entirely on one question: do you have shell access to your current n8n, or only the web UI?

There’s no way around the second case - it’s a deliberate limitation of managed hosts, not a trick you’re missing. Knowing which bucket you’re in up front saves you an hour of frustration.

Step 1: Deploy n8n on InstaPods (your destination)

Set up the target first, so it’s ready to receive your data.

Go to the n8n app page and click Deploy n8n. Pick the Build plan ($7/mo) and name your pod. About 60 seconds later you have a fully configured n8n running on a real Linux server - HTTPS, a live URL, systemd keeping it alive, no Docker or nginx to touch.

The Build plan gives you 2 shared vCPUs, 2 GB RAM, and 25 GB storage - comfortable for a few dozen active workflows, webhook triggers, and AI agent nodes. Executions are unlimited (no per-run billing, ever). If you outgrow it, resizing to Grow ($15/mo, 4 GB RAM, 50 GB) is a one-click change.

Every pod comes with SSH access and a built-in web terminal, which is exactly what you need for the import in Step 3.

Leave this instance running but empty for now.

Step 2: Export from your current host

If you have shell/SSH access (Railway, Render, a VPS, Elestio, Docker)

n8n ships a CLI that exports everything. Open a shell on your current host. If it’s a Docker container, that’s:

docker exec -u node -it <container_name> /bin/sh

Then export your workflows and credentials:

# Workflows - one JSON file each, into a folder
n8n export:workflow --backup --output=./n8n-backup/workflows/

# Credentials - DECRYPTED, so they re-encrypt cleanly on the new host
n8n export:credentials --backup --decrypted --output=./n8n-backup/credentials/

--backup is shorthand for --all --pretty --separate (all items, readable formatting, one file each). --decrypted is the important flag on credentials: it writes the secrets in plain text so the destination can re-encrypt them under its own key. This is the officially supported way to move between two instances with different encryption keys.

Treat the decrypted export as a secret. It contains your API keys and passwords in clear text. Move it over a secure channel (scp/rsync over SSH) and delete it from both machines once the import succeeds.

Copy the n8n-backup folder to your local machine (or straight to the InstaPods pod):

# from your current host, or pull it down locally first
scp -r ./n8n-backup you@your-old-host:/tmp/  # example

Alternative - copy the whole data folder. If you’re moving SQLite-to-SQLite and want an exact clone (executions and all), you can instead copy the entire ~/.n8n folder - it contains database.sqlite and the config file with the encryption key, so credentials just work. This is the atomic, everything-included option when both ends give you filesystem access. If you go this route, you’ll set N8N_ENCRYPTION_KEY to match, rather than importing decrypted files.

If you only have the UI (n8n Cloud, PikaPods)

You can’t reach the CLI or the encryption key, so export what the editor gives you:

  1. n8n Cloud: Admin Panel -> Manage -> Export downloads all your workflows as JSON.
  2. Any n8n editor: open each workflow, use the three-dot menu -> Download to save its JSON.

Here’s the honest part: workflow JSON does not contain credential secrets. It carries only the credential’s name and ID, not the encrypted value. n8n Cloud blocks credential export entirely “for security reasons.” So from a UI-only host you migrate the logic of every workflow, but you will recreate each credential by hand on the new instance (paste the API key, re-do the OAuth connection). Annoying, but a one-time job, and often a good moment to rotate keys anyway.

Step 3: Import into your InstaPods pod

SSH into your new pod (or use the web terminal in the dashboard). Upload your export folder to the pod, then import:

# Credentials first, then workflows
n8n import:credentials --separate --input=/tmp/n8n-backup/credentials/
n8n import:workflow --separate --input=/tmp/n8n-backup/workflows/

Because you exported credentials decrypted, n8n re-encrypts them here under this pod’s own key. No key surgery, no broken credentials. Then restart n8n so it picks everything up:

sudo systemctl restart n8n

Refresh your pod’s URL and your workflows are all there.

If you copied a raw database instead (the data-folder route from Step 2), you’ll want the credentials to decrypt without re-entry. Grab the encryptionKey value from your old ~/.n8n/config, set it on the pod as N8N_ENCRYPTION_KEY in the pod’s environment settings, drop your old database.sqlite into place, and restart. The pod now decrypts with the original key.

Coming from n8n Cloud (UI-only)? Use n8n’s own “Import from file” in the editor to load each workflow JSON, then open every node with a red credential warning and reconnect it. There’s no CLI step because there were no credential files to import.

Step 4: Reconnect the things that don’t move automatically

Two categories of thing are tied to your host, not your data, so they need attention after the move. Skip this and you’ll think the migration failed when it didn’t.

Webhook URLs changed. Your public webhook base is derived from the host, and the host just changed. In the pod’s environment settings, set WEBHOOK_URL to your pod’s public address (e.g. https://your-pod.instapods.app) and restart. The workflow paths (/webhook/...) are preserved, but the domain in front of them is new - so update the URL in every external system that calls your webhooks (Stripe, GitHub, Typeform, etc.) to point at the new host.

OAuth redirect URLs changed. Any credential that uses OAuth (Google, Slack, etc.) has a callback URL registered with the provider. Update those to the new host in each provider’s console, or the reconnect will fail.

Re-test your credentials. Open a few credentials and hit Retest / Reconnect. Green means the key came over intact. A credential that’s present but fails the test is your signal the encryption key wasn’t handled right - go back to Step 3.

Re-activate your workflows. Imported workflows commonly land inactive, and triggers/webhooks only register on activation. Toggle each one Active on the new pod to resume schedules and register webhooks.

Then, and only then, turn off the old instance. Deactivate the workflows on your old host before you rely on the new one - otherwise both instances fire the same schedules and webhooks in parallel (double emails, double API calls). Confirm a trigger fires on InstaPods, then decommission the old host.

Platform-by-platform cheat sheet

Leaving…AccessWhat migratesMethod
n8n CloudUI onlyWorkflows onlyUI export -> re-enter credentials by hand
RailwayFull shell/volumeEverythingCLI export --decrypted, or copy the .n8n volume
RenderFull shell/diskEverythingCLI export --decrypted, or copy the disk at /home/node/.n8n
Docker on a VPSFull rootEverythingCLI export, or copy ~/.n8n / the named volume
ElestioFull SSHEverythingSSH in, CLI export or copy ~/.n8n
PikaPodsManaged, no SSHWorkflows (credentials if their file/backup UI exposes the raw data folder)UI export; check their backup browser for database.sqlite + config

The rule of thumb: shell access means a complete migration; UI-only means workflows now, credentials by hand.

Why run n8n on InstaPods

If you’re migrating from n8n Cloud, the math is the main reason (the full cost breakdown has the per-execution numbers):

n8n Cloud Startern8n Cloud ProInstaPods (Build)
Price$24/mo$60/mo$7/mo
Executions2,500/mo10,000/moUnlimited
Active workflows550Unlimited
Server accessNoneNoneFull SSH + web terminal

A single workflow that runs every 5 minutes burns 8,640 executions a month - enough to blow past the Cloud Starter cap in nine days. Self-hosted n8n has no execution meter at all. Most teams moving off Cloud save $200-700/year.

And if you’re migrating from a raw VPS or a Docker box, the reason is the opposite of money - it’s the ops you stop doing:

Flat pricing, unlimited executions, and the exact same portability you just used to get here. Nothing locks you in - your data is a folder you can export again any time.

TL;DR

  1. Deploy n8n on InstaPods first (Build plan, $7/mo, ~60 seconds).
  2. Export from your old host. Shell access: n8n export:workflow --backup and n8n export:credentials --backup --decrypted. UI-only (Cloud): export workflows as JSON, credentials can’t come.
  3. Import into your pod over SSH: n8n import:credentials then n8n import:workflow, then sudo systemctl restart n8n. Decrypted export re-keys cleanly.
  4. Reconnect the host-tied things: set WEBHOOK_URL, update external webhook callers and OAuth redirect URLs, retest credentials, re-activate workflows.
  5. Deactivate the old instance last, after a trigger fires on the new one.

The only real gotcha is the encryption key - handle credentials with --decrypted (or carry N8N_ENCRYPTION_KEY) and the rest is copy-paste.

Deploy n8n on InstaPods - migrate your workflows to a $7/mo server with unlimited executions, automatic backups, and full SSH access. $10 credit when you add a card.

Related reading: