PlanningGhostVPS editorial

Planning an n8n VPS: resources, domain, HTTPS and backups

Plan n8n resources from workflow load, configure a stable HTTPS webhook address, protect the encryption key and test a restore.

An n8n image can shorten the first installation step, but it does not decide how much memory your workflows need, where webhooks should point, or how you will restore credentials after a failure. This planning guide covers those decisions before you put an automation on a VPS. For click-by-click installation, use the existing tutorials; this article focuses on operating a reliable instance.

1. Describe the workflows before choosing RAM

Count active workflows, trigger frequency, concurrent executions, and the largest file or API response you process. A simple scheduled text workflow and a webhook that handles large files are not comparable workloads. If you already run n8n, measure peak RAM and database growth during the busiest period. For a new instance, start with a modest but upgradeable VPS, run a representative workflow and revisit the plan based on observed memory rather than a universal “n8n minimum.”

The GhostVPS n8n application page lists plans publishing an n8n installation option. Verify the exact image, location and version in Console; a published image option is not a guarantee that the smallest plan will suit every workflow.

2. Give the instance a stable HTTPS address

Choose a subdomain such as automation.example.com and point its DNS at the server. Put n8n behind a reverse proxy with a valid TLS certificate rather than exposing an unprotected editor on the public internet. For inbound webhooks, the external URL generated by n8n must match the HTTPS address clients can reach. The official n8n webhook URL guidance explains the reverse-proxy variables to review. Test a webhook from outside your own network before relying on it.

Real GhostVPS n8n application page showing checks for availability, software, project setup and recovery
GhostVPS n8n setup checklist captured 31 October 2026. Confirm the image and plan in Console, then design the domain, HTTPS and recovery path.

3. Decide what needs to survive a rebuild

List the database, workflows, execution history, binary data, environment settings and encryption key. A database copy without the correct encryption key may leave stored credentials unusable. Protect the key separately from the server, restrict backup access and test a restore to an isolated instance. The n8n database documentation and encryption key guidance should be checked against your deployed version.

A Storage Box can be a destination for independent backups, but buying storage does not automatically create or verify backups. Decide how often a workflow change can be lost and how long you can tolerate a restore. Run a trial restore before the instance becomes critical.

4. Make an operations checklist

  • Record the n8n and database versions and an update window.
  • Limit editor access and use strong account security; give integrations only the credentials they require.
  • Monitor disk usage and failed executions, not only whether the login page loads.
  • Retain an off-server backup of data and configuration; confirm that webhooks work after restore.
  • Budget for storage growth and any paid options shown in Console.

When the plan is selected, follow its Configure in Console link from the n8n application page and confirm the price and application option there. If you need help translating a workflow schedule into a server shortlist, use the server finder and provide support with execution frequency, file sizes and concurrency rather than only saying “I need n8n.”

Back to journalExplore servers