Run a Private n8n Server Your Team Can Actually Restore

n8n is not only a visual automation tool. It stores workflow definitions, credentials encrypted with its instance key, execution data, and configuration that tells it where callbacks should return. A screenshot of the canvas is not a backup. A successful recovery means a new server can start with the same encryption key, load a selected workflow, and run a harmless test without reconnecting every service.

This guide uses DigitalOcean’s n8n 1-Click App on one Droplet and a private Spaces bucket for encrypted backups. This setup has no failover. Do not put customer records, production API keys, or financial actions into a workflow until you have tested both its normal failure handling and this recovery path.

The Marketplace app deploys a Droplet with the current stable n8n release and asks you to point a DNS A record at that server before completing setup. Use SSH-key login for the administrative account. Do not enable password SSH just to make the first login feel easier.

Create a cloud firewall before you invite anyone else. Allow TCP 80 and 443 for the web service. Allow TCP 22 only from your VPN exit or fixed administrative IP. Enable monitoring and backups on the Droplet, but treat those as a separate recovery layer. The backup in this guide protects the n8n data and configuration in portable form.

Complete the initial setup at your HTTPS domain, not by keeping the server IP in bookmarks. In the deployment directory, inspect the generated compose files and environment file before editing them. Set the public host, protocol, and webhook URL to the final HTTPS address using the variable names documented by the installed n8n version. Restart the compose stack only after you have saved a protected copy of the current configuration.

For the standard Docker and Caddy layout, the n8n data volume holds the SQLite database and its encryption material. That volume archive is the credential-recovery record. If you set N8N_ENCRYPTION_KEY outside that volume, keep the protected configuration archive too. Rotating a key is a deliberate maintenance task, not a troubleshooting step. A backup without the matching key may show credentials it cannot use.

Create a private Spaces bucket such as n8n-recovery-your-team in a deliberate region. Do not enable public listing or a CDN. Enable versioning, then create a lifecycle policy that retains primary backup archives for a period your team has approved. Ninety days is a reasonable first policy when you have no stated recovery requirement. Then create a separate, bucket-limited Spaces key. DigitalOcean limited keys offer Read or Read/Write/Delete access. The upload job requires its own Read/Write/Delete key because there is no narrower write-only key. Store that key in a root-readable file on the Droplet with mode 600. Keep the age recipient public key there too. Keep the matching private identity key off the Droplet, such as in a team password manager with recovery access.

The backup remains unreadable in Spaces without the offline age identity. This protects the archive if a Spaces key leaks, but it also means you must test that the recovery owner can use the identity before treating the job as real.

The 1-Click App can change its compose layout over time. Do not copy a volume name from this article. Use docker volume ls and the compose configuration you recorded earlier to identify the volume that holds n8n data. This guide covers the Marketplace Docker and Caddy layout with persistent n8n volume data. If you deliberately replace it with PostgreSQL, use the database vendor’s documented dump and restore procedure and test that as a separate recovery plan.

The script below stops the compose stack briefly, archives the named n8n volume and the deployment configuration, encrypts both with your public age recipient, then uploads the encrypted files. Set VOLUME_NAME only after you have inspected your server. It intentionally refuses to guess. It builds a configuration manifest from files that actually exist, includes the Caddy configuration when it is present, and fails if it cannot find a Compose file. Run it by hand once before scheduling it.

A backup that fails quietly is worse than no backup because it encourages false confidence. Start with a daily schedule and a log, then connect failures to the alerting system your team already watches. Choose frequency from the amount of automation state you can afford to lose. For a workflow that creates customer records every few minutes, daily is probably not enough.

Every few weeks, list the bucket prefix and compare the newest pair of archives with the schedule. The volume and configuration archives should have the same timestamp. Investigate a missing pair before the next routine change to the server.

A restore test must not overwrite the production Droplet or contact production systems. Create a temporary Linux Droplet with a separate cloud firewall. Use a dedicated test subdomain, not the production hostname. During certificate issuance, allow TCP 80 and 443 plus the Caddy service’s required outbound traffic, but start only the reverse-proxy service. Then restrict HTTPS to the recovery administrator’s IP and deny outbound traffic before starting n8n. This prevents duplicate emails, payments, CRM writes, and webhook calls while the recovered instance starts.

Install awscli, age, Docker Engine, and the Docker Compose plugin on the test Droplet. Use a separate bucket-limited Read key there, not the production backup key. Install the same n8n image version, create an empty named data volume, then retrieve one matching volume and configuration archive. Use the private age identity from the recovery owner only on the test machine. Do not copy it to the production server. Extract the configuration archive into a fresh compose directory and restore the encrypted volume archive into the new empty volume. Check the restored image tag, public URL, and encryption-key handling before starting n8n. Sign in through the administrator-only firewall, deactivate all workflows, then run one manual Set-node test. Destroy the test Droplet or remove the recovered credentials from it when finished.

Move beyond one Droplet when you need a documented recovery-time objective, multiple operators changing workflows, high execution volume, or a workflow whose outage can create a material customer or financial problem. At that point, use a managed database where appropriate, test database backups separately, manage secrets outside the Droplet, and write down who can approve recovery.

Do not use an n8n workflow as the only way to back up n8n. The backup job should stay outside the application it protects. That simple separation is what lets you recover when the workflow service is the thing that broke.