Copied successfully!The link has been copied to clipboard
How to Migrate n8n from n8n Cloud to a Self-Hosted or Managed Server
Moving n8n from n8n Cloud to your own server is very doable. The workflows themselves are just JSON. What catches people out is everything around them: credentials, webhook URLs and OAuth redirects. This plan keeps the risky parts under control.
If you want us to do it for you, our managed n8n hosting includes a free migration.
Step 1: take an inventory
List every active workflow, its trigger type (schedule, webhook, app trigger) and how often it runs.
Note every credential and which service it connects to.
List every external system that calls an n8n webhook (forms, payment tools, other apps).
Note any community nodes, custom environment variables and sub-workflows.
Step 2: set up the new instance first
Build the destination before you touch anything on Cloud. Use a dedicated domain with HTTPS and set WEBHOOK_URL correctly, so production webhook URLs show your new address. If you are going the DIY route, follow our VPS setup guide.
Step 3: export your workflows
From the n8n editor you can download a workflow as a JSON file, or select several workflows and export them together. Import them into the new instance using Import from file in the workflow menu, or with the CLI:
Credentials on n8n Cloud are encrypted with a key you do not hold, so plan to re-create them on the new instance rather than carry them across. For each one, add it again and reconnect the workflows that use it. Keep the new N8N_ENCRYPTION_KEY safe from day one.
Step 5: fix webhook URLs and OAuth redirects
Webhook URLs change because the domain changes. Update every external service that calls an n8n webhook.
OAuth apps (Google, Microsoft, Slack and others) have a redirect URI. Add the new instance's redirect URL in each provider's console before reconnecting.
Timezone. Set GENERIC_TIMEZONE so scheduled workflows fire when you expect.
Step 6: test before you switch
Keep the new instance's workflows inactive while you test. Run each important workflow manually with test data, then compare results with the same workflow on Cloud. Only activate a workflow on the new server once its twin on Cloud is deactivated, otherwise both will fire and you will get duplicates.
Step 7: cut over in a low-traffic window
Deactivate the workflow on Cloud and activate it on the new instance, one workflow at a time, starting with the least critical.
Update the webhook URL in the calling service straight after.
Watch the first few executions in both places.
Keep Cloud available for a week or two as a rollback path before cancelling.
Common migration mistakes
Activating the same schedule trigger on both instances at once.
Forgetting an external service that still calls the old webhook URL.
Skipping the OAuth redirect URI change, so reconnecting fails.
Will my workflows break when I migrate? Rarely, if you handle credentials, webhook URLs and OAuth redirects. Test each workflow before you activate it.
Can I migrate without downtime? For most workflows, yes. Move them one at a time and keep Cloud active until the new instance is confirmed.
How long does a migration take? A handful of workflows can move in an afternoon. Large setups with many credentials and webhooks take longer, mostly because of testing.
