How to pause workflows if I lost self-host

Hey fellas, I had this Hetzner subscription where I self-host my n8n but I’ve got some problems paying it. Unfortunately Hetzner canceled my subscription and I’ve lost all my n8n automations (are in my computer only). I want to know if I can pause or exclude this data because, of course, I want to return my automations with all my environment variables, APIs, and all my data that I already use, and I don’t want conflicts.

Describe the problem/error/question

I had this Hetzner subscription where I self-host my n8n but I’ve got some problems paying it. Unfortunately Hetzner canceled my subscription and I’ve lost all my n8n automations (are in my computer only). I want to know if I can pause or exclude this data because, of course, I want to return my automations with all my environment variables, APIs, and all my data that I already use, and I don’t want conflicts.

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Hey @jonkalyt, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Anshul_Namdev, @nabossha - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

@jonkalyt

To avoid conflicts when you restore your automations, first pull any remaining configuration from your local machine (e.g., the n8n/ directory, docker-compose.yml, and the .env file that holds API keys, base URLs, and other secrets). If you have a recent backup of the n8n database (SQLite, PostgreSQL, or MongoDB) or exported JSON workflows (/home/user/.n8n/workflows/), keep those files safe; they contain the exact node settings, triggers, and credentials you used. Then, on a new Hetzner (or any other) droplet, mount the same volume paths or reuse the same .env values, and import the workflow JSON via the n8n UI (Settings → Import) or the CLI (n8n import:workflows). This approach lets you “pause” the data loss by keeping a local copy, and it guarantees that the restored automations will use the same environment variables and API secrets without mismatches.

To prevent future cancellations from wiping out your work, perform regular backup. This will save you from a lot of grief

Nothing is running anymore. Since Hetzner canceled the server, your self-hosted n8n instance is gone and all workflows are already stopped. There is nothing left to pause on the old server.

Hi @jonkalyt Welcome!
Before starting a replacement, confirm with Hetzner whether the old server was deleted or only suspended. If it still exists, keep it powered off so both copies cannot run together later.

Workflow JSON files contain saved credential names and IDs, not the saved API keys or passwords. They don’t back up your environment variables either. Restoring encrypted credentials requires the database backup or a separate credentials export, plus the original encryption key. If you only have workflow JSON, you’ll need to recreate the credentials and environment settings.

When you say the automations are on your computer, do you mean downloaded workflow JSON files, or a backup of the server’s n8n data folder/database? That determines what you can recover.

Hey @jonkalyt, one thing worth hunting for before you rebuild anything. If you never set N8N_ENCRYPTION_KEY yourself, n8n generated one on first launch and saved it into the ~/.n8n folder. Without that file, encrypted credentials in a database backup can’t be decrypted at all, so it’s the first thing to look for in whatever you copied off that server.

Hi @jonkalyt,

Sorry to hear about the server trouble! The good news is that since your Hetzner server is cancelled and offline, your workflows are already effectively “paused” because the instance is no longer running to execute them.

When you are ready to spin up a new self-hosted environment, you shouldn’t run into conflicts if you handle the restore carefully:

1. If you are importing from local JSON files: When you import workflow files from your computer into a fresh n8n instance, they are imported as inactive (paused) by default. You can safely import all of them, take your time setting up your environment variables and reconnecting your API credentials, and then manually activate the workflows one by one when you are ready.

2. If you are restoring a full database backup: If you happen to have a database backup (like an SQLite dump) and your N8N_ENCRYPTION_KEY, the workflows will restore in whatever active/inactive state they were in when the server went down. To prevent them from firing triggers immediately upon boot, you can use the n8n CLI command right after starting your new instance to pause everything: n8n update:workflow --all --active=false

For now, just keep those local files safe. You will be able to migrate everything back smoothly when you set up your new host.

Best, Pawan

Thanks man! Much apprecieted, I’ll certainly do it

Great!! Thank you

only the JSON files…

Thank you man!! Yeah I’ll only import local JSON files, so eventually I’ll need a full database backup and an n8n_encryption_key for this new instance right? Good to know, I’m new on all this, but I’ll certainly take this care to my next work. Thank you!

Hey @jonkalyt umm not quite.

The encryption key only matters for credentials sitting in a database, and workflow JSON doesn’t carry any. Exported workflows include credential names and IDs, never the secrets themselves, so there’s nothing in those files waiting to be decrypted. Import them into the new instance, re-enter each credential once by hand, and pick it on the node.

Worth doing on the new box though: set N8N_ENCRYPTION_KEY yourself in your compose file instead of letting n8n generate one into \~/.n8n. Back that up alongside a database dump and next time a restore actually restores.