Migrating n8n Cloud to Self-Hosted: Your Credentials Don't Come With You
Getting your workflows out of n8n Cloud takes four clicks. That part is genuinely easy, and it’s the part every guide covers.
The work is everywhere else: credentials don’t travel with the export, OAuth connections break in a way that looks like a workflow bug, and webhook URLs have to be changed in the sending service rather than in n8n. Plan for those and this is an afternoon. Discover them one at a time on a live system and it’s a bad week.
Why the credentials don’t come
Self-hosted n8n has a perfectly good credential export. From n8n’s CLI:
n8n export:credentials --all --decrypted --output=backups/decrypted.json
n8n documents that as the way to “migrate from one installation to another that has a different secret key,” with a blunt warning attached: “All sensitive information is visible in the files.”
You can’t run it on n8n Cloud. It’s a CLI command against the instance, and Cloud doesn’t give you a shell. What Cloud gives you is a workflow download from the admin dashboard:
- Log in and open the Admin Dashboard
- In Manage, select the Export tab
- Select Download Workflows
That’s workflows, from the most recent backup. Credential references travel inside the workflow JSON — the nodes still know they need “Gmail account” — but the secrets themselves do not. So budget for re-entering every credential by hand on the new instance.
One deadline worth knowing if you’re migrating off an expired trial: n8n gives you 90 days to download workflows after a trial ends, after which they’re permanently deleted.
The credential checklist, by type
Work through these before you activate anything, because each fails differently.
API keys and tokens. The easy case. Copy the key from wherever you originally got it, paste it into the new instance, done. If you don’t have the key stored anywhere outside n8n Cloud, you’ll need to regenerate it at the provider — and regenerating invalidates the old one, which will break the Cloud instance you’re still relying on. Do these after cutover, or generate a second key where the provider allows it.
Basic auth. Same as above, plus the reminder that you may not have written the password down anywhere else.
OAuth2 — the one that catches people. These cannot be copied at all, because the stored token is bound to a redirect URI pointing at your Cloud tenant. On the new instance the redirect URI is your own domain, so you must:
- Register the new redirect URI in the provider’s app settings (Google Cloud Console, the Slack app config, and so on)
- Re-run the “Connect” flow in n8n on the new instance
- Confirm the connection reports success rather than assuming
The failure mode is what makes this nasty: the workflow looks fine, the node is configured, and execution fails at runtime with an authorisation error that reads like a broken integration. If several workflows share one OAuth credential, they all break together and it looks like the migration corrupted something.
Count your OAuth credentials before you start. That number is your real migration estimate — everything else is faster than you expect.
Webhooks change in the other service
n8n’s webhook URL contains your instance’s host. Move instance, change URL — and the change has to be made wherever the webhook was registered, which is a third-party system you may not administer.
For each webhook-triggered workflow, list where the URL is configured: a Stripe dashboard, a GitHub repository setting, a form provider, a partner’s system. Then update each one after the new instance is reachable.
This is the step that fails silently. Nothing errors. The workflow simply never runs again, and you find out when someone asks why they stopped getting notifications.
The parallel run, and how it double-fires
Unlike a messaging agent — where channels permit only one consumer and both instances fight — n8n Cloud and a self-hosted instance can happily run at the same time. That’s an advantage, and it’s also the trap.
If the same workflow is active on both, it runs on both. A schedule trigger fires twice. Two instances poll the same mailbox and both process the message. Anything that writes to a database, sends an email or charges a card does it twice.
So the rule for the parallel window: import everything, activate nothing.
- Stand up the new instance and import the workflows
- Leave every workflow inactive
- Re-enter credentials and re-authorise OAuth while inactive
- Test individual workflows with manual executions, which don’t need the workflow active
- Only at cutover: deactivate on Cloud, then activate on self-hosted, then re-point webhooks
Manual execution during the validation phase is the key that makes this safe — you can prove a workflow works end to end without arming its trigger.
Keep the Cloud subscription for a billing cycle after cutover. It’s the cheapest rollback available, and OAuth re-authorisation is much easier to redo while the old instance still works.
Do the encryption key properly on the new instance
One thing to set before you import anything: n8n encrypts stored credentials with a key that lives in the .n8n directory, and you can set it explicitly with N8N_ENCRYPTION_KEY.
Set it deliberately and record it in your password manager. If you later move again, restore from backup, or rebuild the container without preserving that directory, credentials encrypted with a key you no longer have are unrecoverable — you’d be re-entering everything a second time.
n8n’s own guidance is to keep persisting the .n8n directory even when using PostgreSQL, precisely because it holds “encryption keys, instance logs, and source control feature assets.”
What you actually gain
The cost comparison usually gets made on subscription price, which drifts. The more durable comparison is the ceiling, and n8n publishes it — these are the memory limits per Cloud plan:
| Cloud plan | RAM | CPU |
|---|---|---|
| Trial / Starter | 320 MiB | 10 millicore burstable |
| Pro-1 (10k executions) | 640 MiB | 20 millicore |
| Pro-2 (50k executions) | 1280 MiB | 80 millicore |
| Enterprise | 4096 MiB | 80 millicore |
n8n Cloud’s Starter plan gives you 320 MiB of RAM. A commodity 4GB VPS matches the Enterprise ceiling, and an 8GB one doubles it — with executions bounded by your hardware rather than a plan limit.
That’s the real argument for self-hosting n8n, and it isn’t primarily about price. It’s that memory is what kills n8n workflows — large payloads, big loops, anything holding a dataset in memory — and on Cloud you cannot buy your way past the ceiling without changing plan tier. n8n’s own documentation has a whole section on reducing workflow memory consumption, which tells you how often that ceiling is the binding constraint.
The costs you take on are real: patching, backups, uptime and the encryption key being your problem now.
Where to put it
For n8n specifically, size on memory and give yourself headroom above the workload rather than matching it exactly — the failure mode is an OOM kill that leaves no error in the n8n log.
Hostinger has the gentlest path, with 8GB tiers priced near what Cloud charges for 320 MiB and a one-click n8n template if you’d rather not touch Docker. Hetzner is the cheapest per gigabyte when its CX tier is in stock — worth checking before you commit, because that tier was showing as unavailable when we last looked, and the CPX line you’d fall back to is several times dearer. In stock, it is the right answer if you’re comfortable administering the box.
If you’d rather not run a server at all, Railway will host n8n as a managed container — though as we found in Railway vs a VPS for n8n, n8n has to stay resident to catch webhooks, so its metered model works out dearer than a flat VPS surprisingly quickly.
Our best VPS for n8n guide covers sizing, queue mode and the execution-data pruning that stops a self-hosted instance filling its disk — worth reading before you pick a plan, because pruning is the setting new self-hosters most often miss.
How we checked this
The CLI commands, the --decrypted export and its warning, the Cloud workflow download path, the 90-day post-trial window, the .n8n directory and N8N_ENCRYPTION_KEY guidance, and the per-plan memory limits are all from n8n’s own documentation, read in August 2026.
On Cloud pricing: we haven’t put subscription prices in this article, and that’s deliberate. n8n’s own docs decline to publish them, noting that “exact features, usage limits, and prices for each plan can change” and pointing readers at the pricing page instead. Its pricing page renders client-side and we couldn’t extract figures reliably enough to stand behind, so we’ve compared the published ceilings — which are structural and don’t drift week to week — rather than invent a break-even table. Check the current price yourself and put it against the RAM column above.
What we did not do: we did not perform this migration. The sequence is assembled from documented behaviour and the ordinary mechanics of OAuth and webhooks rather than a timed run. The one step we’d insist on regardless is keeping the Cloud subscription alive for a cycle after cutover — OAuth re-authorisation is much less painful while the old instance still works.
The three hosting links above are affiliate links. Note that one of them argues against itself: Railway is a legitimate option and also the one our own arithmetic says to avoid for a resident workload like n8n.
FAQ
Can I export credentials from n8n Cloud?
No. Credential export is a CLI command (n8n export:credentials) run against the instance, and Cloud doesn’t provide shell access. The Cloud admin dashboard exports workflows; credential references travel inside them but the secrets don’t. Plan to re-enter every credential by hand.
How do I export my workflows from n8n Cloud?
Log in, open the Admin Dashboard, select the Export tab under Manage, and choose Download Workflows. If your trial has ended you have 90 days before the workflows are permanently deleted.
Why do my OAuth connections break after migrating?
Because the stored authorisation is tied to a redirect URI pointing at your old Cloud tenant. Register the new instance’s redirect URI in the provider’s app settings and re-run the connect flow. Until you do, workflows fail at runtime with authorisation errors that look like broken integrations.
Can I run n8n Cloud and self-hosted at the same time?
Yes, and you should during validation — but keep every workflow inactive on the new instance. If the same workflow is active on both, schedules and polling triggers fire twice and any side effect happens twice. Use manual executions to test while inactive.
What happens to my webhook URLs?
They change, because they contain your instance’s host — and you update them in the service that calls the webhook, not in n8n. Missing one fails silently: no error, the workflow just never runs again.
Is self-hosted n8n cheaper than Cloud?
Usually, but the sharper difference is the ceiling. n8n Cloud’s Starter plan provides 320 MiB of RAM and Enterprise 4096 MiB; a 4GB VPS matches the top tier and an 8GB one doubles it, with no execution cap. For memory-hungry workflows that’s the deciding factor rather than the monthly price.
What’s the one thing I should set up before importing?
N8N_ENCRYPTION_KEY, recorded somewhere safe, and a persisted .n8n directory. Credentials are encrypted with that key — lose it in a future rebuild and you re-enter everything again.
