Move n8n off Zeabur before the December 31, 2026 shutdown

Short answer

Zeabur is winding down. Its October 17, 2026 announcement says some services begin shutting down on December 1, 2026, and all dedicated servers and shared clusters will be shut down by December 31, 2026. December 31, 2026 is the final shutdown date. It does not mean that every service will keep running until that day. Some services begin shutting down on December 1, 2026. Dedicated servers shut down on their own expiration dates between December 1 and December 31, and shared-cluster services are paused on December 1 and can be restarted manually to back up. A dedicated server, in that announcement, is a server with its own expiration date. A shared cluster is the environment whose running services are paused. The move is an export of workflows and credentials with the Server CLI, n8n's command line on the same machine as n8n, then an import on the new host. Make the encryption-key decision before you export. The encryption key is the value in the config file, or N8N_ENCRYPTION_KEY, that n8n uses to decrypt credentials. If your n8n ran on Zeabur's shared cluster, Zeabur's October 19, 2026 incident report says to replace the n8n encryption key and recreate all third-party credentials in n8n, so give the new instance a new key and new credential secrets instead of carrying the old ones over. Dates and the deadline caveat are from Zeabur's shutdown post (Yuanlin Lin, October 17, 2026), checked Oct 18, 2026. The export commands and the encryption-key choice are from n8n's command line and backup and restore docs, checked the same day. The advice to replace the key on the shared cluster is from Zeabur's incident report (October 19, 2026), checked Oct 19, 2026.

The shutdown timeline — your real deadline

Zeabur is shutting down — when does n8n actually stop? It stops on the row that matches the service you use, not on a single shared last day. The post says all dates below are in 2026. If migrating inside this timeline is not possible, the post says to contact Zeabur Support as early as possible so they can discuss individual options. The post also names the October 14, 2026 security incident, a second incident after late August, and limits from growth and architecture, as the context for winding down. This page does not add to that account.

Before you export — secrets warning

Zeabur's status incident Unauthorized Access to Zeabur Infrastructure and User Data (created October 15, 2026, 4:08pm UTC; the rotation instruction is the update at 8:48pm UTC; last update October 15, 2026, 11:33pm UTC) says the exposed data includes service environment variables, account information, API tokens, and zSend API keys. The status home status.zeabur.com still listed that incident on Oct 18, 2026. A migration that copies environment-variable secrets off Zeabur is the moment to do what that update says to do now:

• Rotate any secrets stored in environment variables.
• Regenerate Zeabur API tokens.
• If you use zSend, create new API keys. The update says existing keys are being revoked.
• If you use a Google Cloud dedicated server, change its root password and remove any SSH keys you do not recognize, especially any labeled zeabur-pentest.

Zeabur's October 2026 security incident report (preliminary report, October 19, 2026), checked Oct 19, 2026, adds this for shared-cluster users: "n8n: Replace the n8n encryption key and recreate all third-party credentials in n8n." It says that "Of the n8n instances using PostgreSQL, 602 (of the 607 we checked) had their encryption key set in an environment variable, so the third-party credentials in n8n were effectively leaked in plaintext." For all users, it says: "Replace all credentials in your environment variables. This includes API keys, cloud keys, database passwords, and signing and encryption keys. Revoke the old ones with the service provider first, then create new ones and redeploy." It says projects that moved their environment variables to their own Dedicated Server after August are outside the scope of the platform database read, but credentials on a compromised host still have to be replaced. For GCP Dedicated Server users it says: "Treat your server as compromised" and "Back up your data and rebuild the server." It also says: "Credentials you replaced after the August incident must be replaced again."

These lists are Zeabur's instructions, from the status page and the incident report. This page does not add security steps those pages do not state, and it does not say what the incident did to any one reader's instance beyond that wording.

Step 1 — Export workflows and credentials from the old instance

How do you move n8n workflows and credentials off Zeabur? Export them with the Server CLI on the old instance, then import them on the new one. The Server CLI runs on the same machine as n8n. On npm the n8n command is available directly. On Docker it runs inside the container. How to open a shell on the Zeabur service that runs n8n is — / not yet verified. Zeabur's migrate-project page, checked Oct 18, 2026 (page last updated June 22, 2026), describes copying a project to another Zeabur region or account. It is not a procedure for moving n8n off Zeabur, and this page does not reprint those dashboard steps. Shutdown migration guides are TBA, as the timeline says.

n8n's backup and restore page gives these as the backup commands. Use a different output directory for each. import:credentials --separate currently fails when the directory also contains workflow files. That is a known issue in the docs. --backup sets --all --pretty --separate. You can optionally set --output.

n8n export:workflow --backup --output=backups/workflows/
n8n export:credentials --backup --output=backups/credentials/

Docker form, from the command line page:

docker exec -u node -it <n8n-container-name> <n8n-cli-command>

If n8n runs in Docker, a backups/ directory inside the container is not persisted. Only the .n8n folder is in a volume. Bind-mount a host directory for the exports, or copy them out before recreating the container.

Single-file and decrypted alternatives

The same command-line page also documents single-file exports. --decrypted is credentials only. It writes them in plain text so you can import onto an instance with a different encryption key. All sensitive information is visible in the files. The backup page says to store that file with the same care as the credentials, and to delete it once the restore is complete.

n8n export:workflow --all
n8n export:workflow --id=<ID> --output=file.json
n8n export:workflow --all --output=backups/latest/file.json
n8n export:credentials --all
n8n export:credentials --id=<ID> --output=file.json
n8n export:credentials --all --output=backups/latest/file.json
n8n export:credentials --all --decrypted --output=backups/decrypted.json

Export flags on that page: --all, --backup, --id, --output / -o, --pretty, --separate (one file per workflow, and the output must be a directory), --decrypted (credentials only), --version (workflows only; cannot be used with --all or --published), and --published (workflows only; with --all, unpublished workflows are skipped; cannot be used with --version). Use the same encryption key on the new instance, or use --decrypted. Without the key from config, or the same N8N_ENCRYPTION_KEY, an encrypted credential export cannot be decrypted. If your n8n ran on Zeabur's shared cluster, Zeabur's October 19 report says to replace the encryption key and recreate all third-party credentials, so carrying the old key over does not make those credentials safe.

If you are replacing the encryption key

This is the order the official pages support for a reader on Zeabur's shared cluster, or anyone whose encryption key was in an environment variable Zeabur says was read. It uses only Zeabur's incident report and n8n's command line and set a custom encryption key pages, checked Oct 19, 2026.

1. On the old instance, export the workflows with the backup command above.
2. For credentials, pick one route. Either recreate them by hand on the new instance, or export them with n8n export:credentials --all --decrypted --output=backups/decrypted.json. The command-line page says a decrypted export is for migrating "from one installation to another that has a different secret key", and that all sensitive information is visible in the file.
3. Give the new instance a new key. n8n's encryption-key page says n8n creates a random key on first launch and saves it in the ~/.n8n folder. If the key is not yet in the settings file, you can set N8N_ENCRYPTION_KEY so n8n uses your key instead. In queue mode, set it on all workers. Do not reuse the old Zeabur value.
4. Import the workflows, and the decrypted credentials if you took that route, with the Step 2 commands. n8n re-encrypts imported credentials with the new instance's key.
5. Replace every third-party secret. A decrypted export carries the same secret values Zeabur's report treats as leaked, so re-encrypting them under a new key does not make them safe. Zeabur's order is to revoke the old ones with the service provider first, then create new ones, then put the new values into the n8n credentials.
6. Delete the decrypted file once the restore is complete, as the backup page says.

What the export does not move

What won't move when you export n8n workflows with the CLI? The backup and restore page says a --backup export contains workflows and credentials only. It does not include:

• Users and their roles. After importing into a fresh instance, n8n shows the owner setup screen again, and the first person to complete it becomes the owner.
• Execution history and logs.
• Variables.
• Instance settings, including the encryption key.

Binary data is not in that CLI export either. The backup page defines the export as workflows and credentials only. It places binary data and execution data, when filesystem storage is used, inside the .n8n folder, and in external storage (S3, Azure Blob Storage, or a custom filesystem path) when that is what you configured. Those locations have to be backed up separately for a full-instance restore. This page does not claim a CLI flag moves binary data. n8n backups: a snapshot is not a backup is the longer page on what a complete backup has to contain.

A separate entities export

The command line page also documents export:entities and import:entities. export:entities exports database entities from one database type to another. The page names SQLite and Postgres as the supported types. Execution history data tables are excluded by default, and --includeExecutionHistoryDataTables includes them. import:entities expects an empty database, which --truncateTables can force. That command is not the --backup export. The backup page still says a --backup export is workflows and credentials only. This page does not describe export:entities as moving the encryption key, users, variables, binary files, or instance settings. The command-line page does not list those items as included.

n8n export:entities --outputDir=./outputs --includeExecutionHistoryDataTables=true
n8n import:entities --inputDir ./outputs --truncateTables true

If you need a full-instance restore instead of a move

A complete backup, from the same backup page, is the .n8n folder (~/.n8n by default; it holds config with the credential encryption key, the SQLite database if you use SQLite, and filesystem binary and execution data if you use that storage) plus the external PostgreSQL database if you use one, backed up with that database's own tooling. Also include external binary or execution storage, custom filesystem paths, and N8N_CUSTOM_EXTENSIONS directories. With SQLite, stop n8n before copying .n8n. A live copy can be inconsistent. On Docker, .n8n lives in the n8n_data volume, mounted at /home/node/.n8n.

The backup page's full-instance restore order is:

1. Stop n8n.
2. Restore the .n8n folder to its original location, plus any custom-node directories set with N8N_CUSTOM_EXTENSIONS.
3. Restore the PostgreSQL database from its backup, if you use one.
4. Restore the deployment configuration: the environment variables for the database connection, a custom N8N_ENCRYPTION_KEY if you use one, and any external storage settings. Without them, a restored instance cannot reach its database or decrypt its data.
5. Start n8n.

Environment variables and instance config do not travel in a CLI workflow-and-credential export. They have to be restored or set again, which is step 4 above. This page does not add an environment-variable list the backup page does not name.

Step 2 — Set up the new instance and import

On a fresh instance, complete owner setup first. The import commands need an existing user, and imported credentials need an owner. If the instance has multiple users or projects, use --userId or --projectId. Those two flags cannot be combined. n8n setup problems is the page for a fresh instance that will not come up cleanly. It does not replace the import commands below.

Import from the separate backup directories:

n8n import:workflow --separate --input=backups/workflows/
n8n import:credentials --separate --input=backups/credentials/

Single-file and directory forms from the command-line page:

n8n import:workflow --input=file.json
n8n import:workflow --separate --input=backups/latest/
n8n import:credentials --input=file.json
n8n import:credentials --separate --input=backups/latest/

IDs are exported too. If the target already has workflows or credentials with the same IDs, they are overwritten. Delete or change the IDs before importing to avoid that. Imported workflows are deactivated by default. Activate them in the UI after import, or pass --activeState=fromJson, which uses each JSON file's active field and works only in queue or multi-main mode.

n8n import:workflow --separate --input=backups/latest/ --activeState=fromJson

Known issue, from the command-line page: importing a previously active workflow does not behave the same in every mode. On multi-main and queue-mode instances, that workflow's cron triggers are deactivated on import. On non-multi-main instances, those cron triggers keep running until you restart n8n. The same page documents publish:workflow and unpublish:workflow for n8n 2.0, and says update:workflow is deprecated. The import section of that page still states the UI and --activeState behaviour above. This page does not add a step that maps a deactivated import onto publish:workflow.

Import flags on that page: --help, --input, --projectId (cannot be combined with --userId), --separate, --userId (cannot be combined with --projectId), --skipMigrationChecks, and --activeState (false by default, which deactivates all imported workflows; fromJson uses each file's active field). The flag table says fromJson is multi-main mode only. The import example on the same page says it is supported in multi-main and queue mode.

Migrating to SQLite: n8n limits workflow and credential names to 128 characters, and SQLite does not enforce that limit. The import can then fail with an error such as data too long for column name. The command-line page says to edit the names in n8n and export again, or edit the JSON before importing.

Do you need the n8n encryption key to move credentials? Yes, unless the credentials were exported with --decrypted. On import, the target either uses the same key (restore config, or set the same N8N_ENCRYPTION_KEY) or it imports a decrypted file, and n8n re-encrypts on import. The plain-text warning above still applies to that file. If your n8n ran on Zeabur's shared cluster, use a new key and new secrets, as in If you are replacing the encryption key, not the same-key route. Deployment configuration still has to be set on the new instance. The backup page's restore step 4 names the database-connection variables, a custom N8N_ENCRYPTION_KEY if you use one, and external storage settings. Those values are not inside the CLI workflow-and-credential export.

Step 3 — Test before the old host stops

Test what the docs give you a way to check. No page read for this guide states how long the move takes, and this page does not add a duration.

1. Confirm the imported workflows are on the new instance.
2. Confirm a credential decrypts. That is the same-key or --decrypted rule from the backup page. A per-service reconnect checklist after import is — / not yet verified on the pages read for this guide.
3. Activate the workflows in the UI, or use --activeState=fromJson only where that flag is supported. They import deactivated.
4. If a workflow had cron triggers and was active before export, apply the known issue in Step 2: queue and multi-main deactivate those triggers on import; other instances keep them running until n8n restarts.

Webhook URLs, from n8n's configure webhook URLs with reverse proxy page, checked Oct 18, 2026: n8n builds the webhook URL from N8N_PROTOCOL, N8N_HOST, and N8N_PORT. Behind a reverse proxy that does not work, because n8n listens on port 5678 and the proxy exposes port 443. Set N8N_WEBHOOK_URL to the public base URL (it replaces WEBHOOK_URL, deprecated from n8n 2.35.0), set N8N_PROXY_HOPS=1, and on the last proxy set X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto. A DNS cutover procedure for the new host is — / not yet verified. It was not on the n8n pages read for this guide, and this page does not add one.

After the new instance is up, keep it updated. How to update n8n safely — and who patches it on your host is that page.

Where to land — verified hosts from our price table

What's the cheapest verified place to land n8n after Zeabur? Dated readings of the landing rows in /data/prices.json, dataset last checked Oct 19, 2026. Euro amounts are not converted into dollars, so they are not part of the US-dollar readings. The $0 rows with a checked date are Render Hobby: first term $0/mo (plus compute), renewal $0/mo, checked Oct 16, 2026; Oracle Cloud Always Free: first term $0/mo, renewal $0/mo, checked Oct 16, 2026. Free-tier limits and sleep behaviour are not verified in the dataset, so this page does not present these rows as a deadline-safe place to land. Excluding those $0 rows and usage-based rows, the lowest US-dollar first-term price with a checked date is DigitalOcean Basic Droplet 512 MiB at $4/mo, renewal $4/mo, checked Oct 19, 2026. The sizing guide starts light single-instance work near the 1 GB class, so check that guide before choosing a plan under 1 GB. Among US-dollar rows in this table with verified RAM of at least 1 GB and a verified renewal, the lowest first-term price is Vultr Cloud Compute 1 GB (Regular) and Linode (Akamai) Nanode 1GB at $5/mo, renewal $5/mo, checked Oct 19, 2026. The US-dollar first-term price below that 1 GB group, with renewal not verified, is OVHcloud VPS-1 (2027): first term $4.54/mo (12-month upfront) · $5.35/mo no commitment, renewal — / not yet verified, checked Oct 17, 2026. Railway Hobby: first term $5/mo (usage-based), renewal $5/mo, checked Oct 19, 2026. Dataset source text for Railway Hobby: Hobby $5 ... Includes $5 of monthly usage credits (usage beyond credits billed extra). It is not a $5 flat always-on cost. Euro rows, not converted: Sliplane Starter: first term €9/mo, renewal €9/mo, checked Oct 19, 2026; netcup VPS Lite 1 G12.5s: first term €5.86/mo, renewal — / not yet verified, checked Oct 19, 2026. The sizing sentence points at how much RAM and CPU n8n needs. What the new host costs at your execution volume is the cost-by-executions guide. All prices, dated: n8n hosting prices and n8n hosting prices — October 2026.

The table uses dataset type only. Order is dataset order. It is not a ranking, and affiliate status is not an input. one-click: Hostinger KVM 1, OVHcloud VPS-1 (2027). managed n8n: Hostinger Managed n8n, Elestio Managed n8n (from). PaaS: Render Hobby, Railway Hobby, Sliplane Starter. bare VPS: Contabo Cloud VPS 4, DigitalOcean Basic Droplet 512 MiB, Vultr Cloud Compute 1 GB (Regular), Linode (Akamai) Nanode 1GB, netcup VPS Lite 1 G12.5s. free tier: Oracle Cloud Always Free. Sliplane Starter is type PaaS. Its One-click n8n flag in the dataset is in the row, not a second type.

Disclosure: Some host links below are affiliate links. We may earn a commission if you sign up, at no extra cost to you. Prices and order are not affected.

Hetzner Cloud CPX02: first term €6.49/mo, renewal €6.49/mo, checked Oct 19, 2026.

Stay on n8n Cloud instead?

n8n Cloud is not a row in the landing table above. The checked dataset rows are n8n Cloud Starter (annual): first term $20/mo, renewal $20/mo, checked Oct 19, 2026; n8n Cloud Pro (annual): first term $50/mo, renewal $50/mo, checked Oct 19, 2026. Those are the official-cloud prices in the dataset, not a self-host landing price. n8n Cloud vs self-hosted compares the two ways of running it. The host page is n8n Cloud.

How checks work. Price history.

FAQ

When does Zeabur shut down?

Zeabur's October 17, 2026 announcement says some services begin shutting down on December 1, 2026, and all dedicated servers and shared clusters will be shut down by December 31, 2026. December 31, 2026 is the final shutdown date. It does not mean that every service will keep running until that day. Some services begin shutting down on December 1, 2026. Dedicated servers shut down on their own expiration dates between December 1 and December 31, and shared-cluster services are paused on December 1 and can be restarted manually to back up. Data deletion date, final data export deadline, and the Zeabur Support closing date are TBA. Checked Oct 18, 2026.

Can I wait until Dec 31 to move my n8n?

No. December 31, 2026 is the final shutdown date. It does not mean that every service will keep running until that day. Some services begin shutting down on December 1, 2026. Dedicated servers shut down on their own expiration dates between December 1 and December 31, and shared-cluster services are paused on December 1 and can be restarted manually to back up. Check the dedicated server's expiration date and finish the backup and migration before that date. Checked Oct 18, 2026.

How do I export my n8n workflows and credentials?

On the same machine as n8n, the Server CLI backup commands are n8n export:workflow --backup --output=backups/workflows/ and n8n export:credentials --backup --output=backups/credentials/. Use a different output directory for each. --backup sets --all --pretty --separate. On Docker, the form is docker exec -u node -it <n8n-container-name> <n8n-cli-command>. A backups/ directory inside the container is not persisted, so bind-mount a host directory or copy the files out. Checked Oct 18, 2026.

What won't the n8n CLI export move?

A CLI --backup export contains workflows and credentials only. It does not include users and their roles (a fresh instance shows owner setup again, and the first person to complete it becomes the owner), execution history and logs, variables, or instance settings, including the encryption key. Binary data is not in that export either. When binary or execution data uses filesystem storage, the backup docs place it in the .n8n folder. When it uses external storage such as S3 or Azure, or a custom filesystem path, that location has to be backed up separately for a full-instance restore.

Should I keep the same n8n encryption key when I move off Zeabur?

Not if your n8n ran on Zeabur's shared cluster. Zeabur's October 19, 2026 security incident report says: "n8n: Replace the n8n encryption key and recreate all third-party credentials in n8n." It also says that 602 of the 607 n8n instances it checked that use PostgreSQL had the encryption key in an environment variable, so the third-party credentials in n8n were effectively leaked in plaintext. For all users, the report says to replace credentials in environment variables, including signing and encryption keys, revoking the old ones with the service provider first. n8n generates a random key on first launch, or uses N8N_ENCRYPTION_KEY if it is set before the key is saved in the settings file. Checked Oct 19, 2026.

I don't have my encryption key — can I still move credentials?

Yes, if the new instance uses the same encryption key, or if you exported credentials with --decrypted. Without the key from the config file, or the same N8N_ENCRYPTION_KEY, an encrypted credential export cannot be decrypted. A --decrypted export contains all credential data in plain text. Store it with the same care as the credentials themselves, and delete it once the restore is complete. If your n8n ran on Zeabur's shared cluster, a --decrypted export still carries the secret values Zeabur's incident report treats as leaked, so each one has to be replaced with a newly issued secret.

Where is the cheapest verified place to move n8n?

Dated readings of the landing rows in /data/prices.json, dataset last checked Oct 19, 2026. Euro amounts are not converted into dollars, so they are not part of the US-dollar readings. The $0 rows with a checked date are Render Hobby: first term $0/mo (plus compute), renewal $0/mo, checked Oct 16, 2026; Oracle Cloud Always Free: first term $0/mo, renewal $0/mo, checked Oct 16, 2026. Free-tier limits and sleep behaviour are not verified in the dataset, so this page does not present these rows as a deadline-safe place to land. Excluding those $0 rows and usage-based rows, the lowest US-dollar first-term price with a checked date is DigitalOcean Basic Droplet 512 MiB at $4/mo, renewal $4/mo, checked Oct 19, 2026. The sizing guide starts light single-instance work near the 1 GB class, so check that guide before choosing a plan under 1 GB. Among US-dollar rows in this table with verified RAM of at least 1 GB and a verified renewal, the lowest first-term price is Vultr Cloud Compute 1 GB (Regular) and Linode (Akamai) Nanode 1GB at $5/mo, renewal $5/mo, checked Oct 19, 2026. The US-dollar first-term price below that 1 GB group, with renewal not verified, is OVHcloud VPS-1 (2027): first term $4.54/mo (12-month upfront) · $5.35/mo no commitment, renewal — / not yet verified, checked Oct 17, 2026. Railway Hobby: first term $5/mo (usage-based), renewal $5/mo, checked Oct 19, 2026. Dataset source text for Railway Hobby: Hobby $5 ... Includes $5 of monthly usage credits (usage beyond credits billed extra). It is not a $5 flat always-on cost. Euro rows, not converted: Sliplane Starter: first term €9/mo, renewal €9/mo, checked Oct 19, 2026; netcup VPS Lite 1 G12.5s: first term €5.86/mo, renewal — / not yet verified, checked Oct 19, 2026.