Self-host n8n on a VPS: a safe setup plan

Self-host n8n on a VPS when you can own patching, backups, TLS, monitoring, and recovery—not just the first container launch. Use Docker with persistent storage, place n8n behind a reverse proxy, set the public webhook URL, protect credentials, test a real workflow, and document updates before production.

Decide whether you should self-host at all

n8n recommends Docker for most self-hosting needs, but its documentation also draws a firm boundary: operating the service requires server, container, security, scaling, and n8n knowledge. Configuration mistakes can cause data loss, security problems, or downtime.

The login screen is not the finish line. A working editor proves that one process started. It does not prove that incoming webhooks use the right public address, credentials can survive a rebuild, storage will persist, or anyone can restore the service after an update.

Self-hosting makes sense when control over data location, network access, integrations, or operating policy justifies the maintenance. It is a poor bargain when upgrades, alerts, backups, and incidents belong to whoever notices first.

Choose managed n8n when the team wants workflow automation without taking on the server. Choose a VPS when the operating responsibilities are understood, assigned, and tested.

Draw the service boundary before installing

A small deployment still has several parts. Naming them prevents the common mistake of treating a container as the whole system.

Keep the public edge narrow. The reverse proxy should be the internet-facing service. n8n should listen behind it, while administrative access to the VPS remains restricted to the people and systems that need it.

Choose a VPS by measurement, not folklore

There is no honest universal VPS size for n8n. A scheduled workflow that moves small records is not comparable to frequent webhooks, large binary files, browser automation, code-heavy nodes, or many simultaneous executions.

Start with the workflows you actually intend to run. Record how often they trigger, how long they wait, whether they process files, which steps call external APIs, and what happens when several executions overlap.

Measure these signals during a representative test:

• memory use during the heaviest normal execution;
• CPU pressure when workflows overlap;
• database and file growth over a realistic retention window;
• network transfer created by inputs, outputs, and binary data;
• recovery time after a container or VPS restart.

Leave room for failure handling. A workflow that fits only when everything is calm may stall when retries, logs, updates, and overlapping executions arrive together. Rent boring infrastructure, then scale from observed pressure rather than a generic plan label.

When comparing VPS options such as DigitalOcean and Hetzner, check storage persistence, backup controls, network policy, console recovery, monitoring, and support. The provider page is the right place to compare current offers; this deployment plan does not invent a minimum machine.

Build a replaceable Docker deployment

Use the official n8n image and an explicit Docker Compose configuration stored outside the container. Keep environment values separate from the Compose file when they contain secrets or deployment-specific details.

Persist the n8n directory. The official Docker setup mounts a volume at /home/node/.n8n. That directory remains important even with an external database because it contains the encryption key and other instance data needed across container replacements.

Docker describes volumes as its preferred persistent store for container data. A volume is not automatically a backup, however. It lives with the Docker host unless you copy and protect it elsewhere.

Set a restart policy so the service can return after a normal container exit or Docker restart. Then test the policy. A container that restarts forever is not highly available. It is merely very committed to failing.

Keep the deployment definition, non-secret configuration, update procedure, and recovery notes together. Another operator should be able to identify what the container needs without reconstructing the server from command history.

Pick a database without pretending it is sizing

Self-hosted n8n uses SQLite by default and also supports PostgreSQL. SQLite keeps the initial architecture compact. PostgreSQL separates the database service and introduces its own credentials, storage, maintenance, and recovery work.

Database choice is an operating choice. Do not switch because a guide labels one option more professional. Decide from concurrency, recovery, administration, scaling plans, and the team’s ability to run the database safely.

With SQLite, the database file is part of the persistent n8n directory. With PostgreSQL, back up the database and continue preserving the n8n directory because the encryption key and other important instance assets still live there.

Test a restore using the database mode you chose. A copied file or database dump is only an input to recovery, not proof that credentials and workflows can run again.

Put TLS and webhook URLs at the public edge

n8n recommends a reverse proxy or load balancer for TLS. That layer can expose the public hostname, renew certificates, and forward requests to the private n8n service.

Behind a proxy, n8n cannot infer every public detail from its internal listener. Configure WEBHOOK_URL with the external HTTPS address so the editor and connected services use the correct callback. Configure N8N_PROXY_HOPS to match the trusted proxy path and pass the documented forwarded request headers.

A webhook is an internet entry point. Expose only the routes the workflow needs, authenticate callers where the integration supports it, validate incoming data, and avoid placing secrets in URLs. Treat a webhook trigger as production input, not a convenient form submission.

Test from outside the VPS network. Confirm that the displayed production webhook uses the intended hostname and HTTPS, that the trigger receives a real request, and that a malformed or unauthenticated request fails in the expected way.

Protect credentials and powerful nodes

n8n encrypts stored credentials with an instance encryption key. It creates a key on first launch, and operators can provide a custom N8N_ENCRYPTION_KEY. Losing continuity of that key can leave restored database records unusable even when the data itself is present.

Back up the key with the deployment secrets. Do not place it in a public repository, a shared Compose file, workflow notes, or logs. Restrict who can retrieve it and write down how recovery receives the same key; memory is not a secret manager.

Give every external credential the smallest practical permissions. Use separate service identities where possible, rotate them when ownership changes, and remove credentials that no active workflow needs.

n8n’s security audit can report unused credentials, risky database expressions, file-system access, risky or community nodes, unprotected webhooks, missing security settings, and an outdated instance. Run it before production and after meaningful workflow or node changes.

Community and code-capable nodes expand what the instance can do. They also expand what a compromised workflow or careless editor can reach. Review node provenance and permissions before installation instead of treating the catalogue as a harmless extension list.

Test one workflow end to end

Choose a representative workflow rather than a toy that only changes text. It should exercise the real trigger, one external credential, expected transformations, the final action, and the failure path.

Verify the complete path:

• the trigger receives a production-style event through the public endpoint;
• invalid input stops without performing the final action;
• external API failure produces a visible, actionable execution error;
• a retry does not create an unsafe duplicate result;
• logs reveal enough context to investigate without exposing credentials.

Automation moves failure; it does not remove it. If a workflow creates invoices, messages, records, or access grants, define what may be retried and how an operator recognizes an action that already succeeded.

Watch execution duration, failures, queueing, database growth, and disk pressure during the test. These observations are more useful for VPS selection than a resource number copied from somebody else’s workload.

Back up what recovery actually needs

A useful backup covers the chosen database, the persistent n8n directory, the encryption key, deployment configuration, and any local files that workflows depend on. Protect backups separately from the VPS account so one account failure does not remove both service and recovery copy.

Test the restore. Build a clean recovery environment, restore the state, supply the same encryption key, open a workflow, confirm its credentials can be read, and execute a controlled test. That is the fire drill. Record the steps and the time required.

Do not assume a VPS snapshot is the entire recovery plan. A snapshot can help return a machine, but the operator still needs a known application state, current secrets, DNS control, and a way to validate workflows.

Set a retention policy for executions and binary data that matches troubleshooting and compliance needs. Monitor growth rather than waiting for a full filesystem to become the first alert.

Update with a rollback path

Use a production release channel and read the n8n release notes before changing the image. Back up current state, record the running version, and identify how to return to it if a workflow or credential integration breaks.

Pull and start the new image through the documented deployment process. Then check the editor, production webhook, representative workflow, failed-execution view, logs, and available disk space.

A container rollback may not reverse a data migration. Treat the database and persistent directory as part of the update boundary. If the release changes stored state, recovery may require restoring the matching backup rather than starting an older image against newer data.

Schedule updates while someone can observe the service and act. Automatic updates without a compatibility test turn maintenance into an unplanned experiment.

When a VPS is the wrong answer

Operate the workflow engine, not just the container

A VPS can be a sensible home for n8n when the team needs control and accepts the maintenance. The durable part is not the container. It is the operating system around it: ingress, persistent state, secrets, observation, updates, and recovery.

Start with a representative workflow, measure the real load, and keep the architecture small until evidence demands more. The safest setup is the one another operator can understand, rebuild, and restore without guessing.