n8n Cloud to Self-Hosted: Credentials, Webhooks and Safe Cutover
Your n8n Cloud workflows imported into the new server with their credential names intact. Why do the connections still fail, and when do you move the webhooks over?

- You can move workflows from n8n Cloud to self-hosted n8n, but workflow exports do not move credential secrets. Recreate the connections before switching traffic.
- Cloud backup downloads contain workflows, not a complete instance. Some PostgreSQL-backed Cloud instances require support to export them.
- Keep the imported workflows inactive while testing. Move webhook senders and schedules deliberately so two installations do not process the same event.
The file transfer is the easy part. The real migration is making the same business event produce the intended result on a different installation: the right credential, the right callback URL, the right schedule and no duplicate downstream actions.
A Cloud-to-self-hosted question on Reddit received several variations of “export the JSON.” That moves the workflow definition. It does not make the new installation an authenticated replacement for the old one.
What moves with the workflow—and what needs rebuilding
Use this inventory before pricing a server. A green import confirmation is not the end of the job.
| Item | Workflow JSON alone | Destination work |
|---|---|---|
| Nodes and connections | Included in the definition | Check node availability and version compatibility |
| Credential references | Names and IDs can remain | Create credentials, authorize them and select the right connection in each node |
| Credential secrets | Not transferred by Cloud workflow export | Recover from the original provider or your approved secret store |
| External webhook senders | Not reconfigured by importing a file | Point each sender at the new production endpoint |
| Schedules and dependent workflows | Definitions need checking | Verify timezone, sub-workflow references and error workflows |
| Execution history, instance settings and other dependencies | Not a complete instance transfer | Retain required records and recreate environment-specific configuration |
These boundaries follow n8n's migration guidance. Do not use a self-hosted database restore recipe as a promise that Cloud lets you download its database and encryption key.
Export the current workflows, not just an old backup
For an individual workflow, use the workflow menu's Download option. At the destination, use Import from File. The export/import guide also describes copying nodes and importing from a URL.
For a bulk Cloud download, the instance owner opens the Cloud console, selects Export, chooses a backup and downloads its workflows. Check the backup timestamp against the last changes you made. A backup created before yesterday's fix will not contain that fix.
The current Cloud download documentation identifies a further restriction: workflow export is not yet available through that screen for instances n8n hosts on PostgreSQL. The screen directs those owners to support. Arrange that export before canceling or losing access.
Inspect the files before handing them to another person. A workflow can contain sensitive credential names or literal HTTP authorization headers even though the managed credential secrets are absent. Treat an export as business configuration, not a harmless diagram.
Reconnect credentials before publishing anything
Build a connection list with four columns: workflow, node, provider account and replacement credential. Group nodes using the same approved service account so you do not accidentally authorize each one with a different employee's personal account.
Recreate API-key and Basic Auth credentials through the destination's credential interface. For OAuth, complete the provider's authorization process and check its registered redirect URI. Copying an old credential ID into a JSON file does not authorize the new installation.
Test a read-only operation first where the integration allows it. For write operations, use a test record with a stable ID and verify the result in the destination application. A node that connected successfully but wrote to the wrong workspace has not passed.
Keep the distinctions visible in the migration sheet: missing secret, expired authorization, insufficient permissions and a node pointing at the wrong credential are different failures. Repeating the workflow import will not repair all four.
Keep webhook addresses and timezones explicit
Behind one reverse proxy, a configuration can look like this:
N8N_WEBHOOK_URL=https://automation.example.com/
N8N_PROXY_HOPS=1
GENERIC_TIMEZONE=America/New_York For current n8n versions, the documented setting is N8N_WEBHOOK_URL; it replaces the deprecated WEBHOOK_URL from version 2.35.0. The example assumes one proxy hop. Match the proxy configuration to your actual request path rather than copying the count into a different topology.
Update the services that send webhooks to Cloud. Keeping the path portion does not keep the Cloud hostname working on your server. Confirm that senders use the destination's production URL, not a temporary test URL.
Set the instance timezone, then inspect workflow-specific schedule settings. Record the next expected run in the operator's timezone. This catches a shifted daily report before the first morning it fails to arrive.
Switch one event source at a time
The safest cutover is a small, observable one. A useful sequence for a webhook-driven order workflow is:
- Import and reconnect the destination, leaving production processing disabled.
- Run a test order through the destination and verify its external record.
- Choose a cutover window and record the final event ID processed by Cloud.
- Pause or redirect the sender using its supported controls; stop the old workflow's production processing.
- Publish the destination workflow, update the sender and send one identifiable test event.
- Check the receiving record, pending events and the next scheduled execution.
Some senders retry events during a pause; others need a separate backfill. Establish which behavior your sender supports before the window. Deduplicate by the original order or event ID, not by the new n8n execution ID: the same business event can have several executions.
Keep a rollback note that specifies where the sender will point, which workflows must be stopped and which events need reconciliation. Returning traffic to Cloud without checking writes already completed on the new server can create the very duplicates the rollback was meant to prevent.
Compare the replacement service, not just its VM price
Self-hosting changes who maintains the database, certificates, backups, upgrades and failed jobs. Cloud pricing is an execution-based subscription; a VPS bill covers a machine. The two prices do not cover the same work.
A small-business discussion about collaboration and controls illustrates the other buying question: does the replacement edition provide the features the team actually needs? Check the current edition differences before treating all Cloud capabilities as free self-hosted features.
Move when you have a concrete reason for server control and someone responsible for recovery. If the migration only works while one person is manually repairing credentials and watching every execution, it has not yet replaced the managed service.