A VPS can run n8n, but a working container is not proof that its workflows, files, certificates, or webhook addresses can survive a failure. This worksheet is for one n8n instance on Linux with Docker Compose, a domain that reaches the VPS, and an operator who can manage the server and containers. It does not replace the Docker Compose instructions or test your provider. Official documentation describes self-hosting as requiring server and container setup, resource and scaling management, application security, and n8n configuration; it recommends it for expert users and links less-experienced operators to n8n Cloud. Those are n8n’s recommendations, not additional VPS-provider requirements. Source 66, evidence 3
Readiness boundary
Before deciding, record the instance’s purpose, maximum acceptable outage, recovery point, backup destination, and named response path. The supplied documentation does not set backup frequency, retention, capacity, restore-time targets, or a minimum technical level. A restart does not prove that a disk failure or certificate failure is recoverable. Use the stable release for production; the documentation identifies beta as the most recent release and says it may be unstable. Source 66, evidence 6
Cost and responsibility worksheet
| Question | Decision to record | Evidence and boundary |
|---|---|---|
| Who operates it? | Name who handles the server, containers, configuration, updates, monitoring, and incidents. | Self-hosting involves server and container setup, resource and scaling management, application security, and n8n configuration. This guide does not define a provider contract. Source 66, evidence 3 |
| What must survive? | Keep n8n_data mounted at /home/node/.n8n if using the supplied Compose file. Include workflow-owned files stored in ../local-files, mounted at /files, when applicable. |
The supplied Compose file creates n8n_data, traefik_data, and the local-files mount. n8n_data holds the SQLite database and encryption key; /files is shared with the host. Source 66, evidence 19 |
| How will recovery data be protected? | Copy the database, matching encryption key, and relevant files to a separate location. Record frequency, retention, and restoration testing. | The documentation identifies these items but gives no backup schedule or retention rule. Source 66, evidence 19 |
| How will HTTPS survive? | Preserve traefik_data, which stores TLS/SSL certificate data, and test certificate recovery. |
The supplied Compose file uses Traefik for TLS certificates and routing, and n8n is reachable over HTTPS rather than plain HTTP. Source 66, evidence 24 |
| What will it cost? | Obtain current prices for the VPS, DNS, storage, backup destination, and other services. | The supplied documentation provides no VPS or backup prices. |
Persistence and HTTPS worksheet
- Name the recovery boundary. Record purpose, required data, maximum outage, recovery point, backup destination, and response path. Keep recovery data separate from the VPS volume.
- Confirm DNS and HTTPS. Create a dedicated subdomain and an A record pointing to the server, then confirm the subdomain resolves before testing n8n. The supplied Compose example reaches n8n through HTTPS, not plain HTTP. Source 66, evidence 14 Source 66, evidence 24
- Choose persistence. Use the supplied
n8n_datamount at/home/node/.n8nif it matches your deployment. Keeplocal-filesin scope when workflows use it, and verify the actual paths and ownership in your Compose file. - Back up the recovery set. Include the database, matching encryption key, and relevant files. Decide frequency, retention, and restoration testing; the supplied guide does not prescribe them. Source 66, evidence 19 Source 66, evidence 20
- Prepare HTTPS recovery. Keep
traefik_dataand plan access to it for certificate renewal and restoration. The supplied Compose file uses Traefik for TLS certificates and routing. Source 66, evidence 19 Source 66, evidence 24 - Configure reverse-proxy webhooks only when needed. Behind a reverse proxy, n8n runs internally on port 5678 while the proxy exposes it on port 443. Set
N8N_WEBHOOK_URL=https://n8n.example.com/andN8N_PROXY_HOPS=1, and forwardX-Forwarded-For,X-Forwarded-Host, andX-Forwarded-Protoon the last proxy.N8N_WEBHOOK_URLreplaces deprecatedWEBHOOK_URL. Source 67, evidence 4 Source 67, evidence 6 - Test recovery. On a suitable non-production copy, create a snapshot or backup of the persistent data, restore it into a fresh environment, and verify a workflow plus an external webhook. A successful restart alone does not prove recovery.
Worked hypothetical recovery
Scope: Maya operates one account with one n8n instance. This example uses one VPS, one Compose project, and one off-VPS backup; it does not combine multiple accounts or instances.
Choice: Maya keeps n8n_data for the database and encryption key, stores workflow files in local-files, and copies all three after each planned change. She adopts a one-day recovery point and a four-hour recovery target as planning assumptions, not n8n limits. She also uses the reverse-proxy settings above.
Failure: On Tuesday, the VPS volume becomes unreadable. The container starts again, but the database and encryption key are gone. Maya does not delete the off-VPS copy.
Recovery: She restores the Monday copy into a fresh environment, starts the same Compose project, confirms that the workflows load, and sends a test webhook to the public HTTPS address. The external service must receive the URL registered by n8n, not an internal 5678 address.
Decision: If workflows run and the webhook test succeeds, recovery is ready. If the database restores but encrypted workflows cannot be read, Maya has restored files but not a usable instance; she restores the matching encryption key or follows her documented recovery procedure. If workflows run but the webhook points to the wrong host or port, HTTPS configuration is incomplete. She records the failed check and repeats the restoration or proxy correction before declaring success.
Final go/no-go checklist
- The operator accepts responsibility for the server, containers, configuration, updates, monitoring, and incidents.
-
n8n_datais mounted at/home/node/.n8n, or an equivalent persistent design is documented. - The database, matching encryption key, and relevant workflow files are included in backup scope.
- The backup destination is separate, with frequency, retention, and restoration testing documented.
- DNS resolves to the VPS, certificate data is preserved, and HTTPS recovery has been tested.
- Reverse-proxy webhook settings are correct for the chosen proxy path, including the public webhook URL,
N8N_PROXY_HOPS=1, and required forwarded headers. - A restore test verified workflow loading and an external webhook after a realistic failure.
- A named response path covers server, security, and downtime incidents.
Go: proceed when every applicable item is documented and tested. No-go: fix missing persistence, backup, HTTPS, webhook, or operating responsibility before using the instance for real automations. These are readiness criteria for this worksheet, not additional n8n product requirements.
Closing note: This is a planning aid, not proof that a specific VPS or backup service meets your needs. Review current provider documentation and test the design on your system.
AI-assisted drafting was used to organize the supplied official documentation into a concise readiness worksheet.
Prepared with AI assistance, linked sources, automated checks and a separate model review; not hands-on testing or human expert verification. Report an error.