Install n8n on a VPS with Docker

How do you install n8n on a VPS with Docker?

To install n8n on a VPS with Docker, point a domain to the server, run a pinned n8n version with Docker Compose, and put it behind an HTTPS reverse proxy. Secure access and test backups before using real business data. For an existing instance, complete the upgrade checklist below before changing its image version.

Self-hosting lets you choose the server and configuration, while making your team responsible for maintenance and recovery. Connected AI and SaaS services can still receive workflow data. This guide assumes Ubuntu 22.04/24.04 and your own domain (for example n8n.yourdomain.com). The minimal example covers n8n and Caddy; it does not configure n8n Assistant's sandbox or a separate production task runner.

What do you need before you start?

Before typing any commands, make sure these four things are in place:

• A VPS running Ubuntu (22.04 or newer) with root/sudo SSH access.
• A domain or subdomain whose DNS you can manage (for HTTPS and a clean URL).
• The right specs for your workload (see the table below).
• Server administration skills, including container logs, access control and backup restoration.

These are starting estimates, not capacity guarantees. Measure memory, execution duration and concurrency with representative workflows:

Workload	vCPU	RAM	Storage	Notes
Testing / personal	1-2	2 GB	20 GB SSD	Start small; measure actual memory use
Small business	2	2-4 GB	40 GB SSD	Load-test the actual integrations
Production / AI agent	4	4-8 GB	60-100 GB SSD	Size the database and runners separately

Compare Jakarta and Singapore regions using actual latency and data-handling requirements. Budget for backups, storage, monitoring, operations and API usage as well as the VPS. The official Docker Compose guide requires at least 4 GB RAM and 2 vCPUs for its larger Assistant sandbox stack; that is a different configuration from the minimal example here.

What are the steps to install n8n with Docker Compose?

Use these steps for a fresh instance. Replace n8n.yourdomain.com with your domain. An existing instance needs the backup and staging steps below first.

1. Log into the VPS via SSH and update the system.

   ssh root@YOUR_VPS_IP
   apt update && apt upgrade -y
   

2. Install Docker and the Docker Compose plugin. Follow the official Docker Engine instructions for Ubuntu, including its apt repository and Compose plugin. Verify with docker --version and docker compose version.

3. Point your domain to the server. In your domain's DNS panel, create an A record for n8n.yourdomain.com pointing to your VPS public IP. Wait for DNS propagation (usually a few minutes to an hour).

4. Create a project folder and config file.

   mkdir ~/n8n && cd ~/n8n
   nano docker-compose.yml
   

5. Fill in docker-compose.yml with an n8n + Caddy setup (Caddy handles HTTPS automatically via Let's Encrypt): This example pins n8n 2.43.5, checked on 15 October 2026, and retains Caddy 2.11.7, previously checked on 10 October. Review newer releases before adopting them. N8N_WEBHOOK_URL and one trusted proxy hop follow n8n reverse-proxy guidance; adjust the hop count if your proxy chain differs.

   services:
     n8n:
       image: n8nio/n8n:2.43.5
       restart: always
       environment:
         - N8N_HOST=n8n.yourdomain.com
         - N8N_PROTOCOL=https
         - N8N_WEBHOOK_URL=https://n8n.yourdomain.com/
         - N8N_PROXY_HOPS=1
         - GENERIC_TIMEZONE=Asia/Jakarta
         - TZ=Asia/Jakarta
       volumes:
         - n8n_data:/home/node/.n8n
     caddy:
       image: caddy:2.11.7
       restart: always
       ports:
         - "80:80"
         - "443:443"
       volumes:
         - ./Caddyfile:/etc/caddy/Caddyfile
         - caddy_data:/data
   volumes:
     n8n_data:
     caddy_data:
   

6. Create a Caddyfile in the same folder for the reverse proxy + automatic HTTPS:

   n8n.yourdomain.com {
       reverse_proxy n8n:5678
   }
   

7. Restrict onboarding access, then start n8n. Before startup, allow access to HTTPS only from your administrative IP in the VPS provider firewall, or use an equivalent restricted access path. Keep the initial owner-setup page private until your account exists. Ensure the chosen restriction still permits Caddy's certificate validation.

   docker compose up -d
   

   Caddy will fetch the SSL certificate automatically. Open https://n8n.yourdomain.com in your browser and create your first owner account.

8. Configure host and provider firewalls. The UFW example below covers host rules. Docker-published ports can bypass UFW; use provider-firewall or Docker-aware rules for container access, as explained in Docker's firewall limitations. Preserve SSH access before enabling UFW:

   ufw allow OpenSSH
   ufw allow 80
   ufw allow 443
   ufw enable
   

Verify HTTPS, owner login and a harmless test webhook. Keep onboarding access restricted until the owner account is created, and check the VPS provider firewall too. A working editor alone does not establish production readiness.

How do you secure a self-hosted n8n instance?

• Restrict access. Use HTTPS, an owner account and the minimum necessary network access. Keep n8n's port 5678 off the public host interface, as in this example. Review any extra proxy authentication against your webhook routes.
• Plan updates. Read release notes, pin a version and test it in a separate staging instance before production, following n8n's update guidance.
• Keep recoverable backups. With default SQLite, stop n8n before copying n8n_data, or use a consistent snapshot. With PostgreSQL, include a database backup; the volume alone is insufficient. Include configured external storage and custom-node files. See n8n backup and restore.
• Protect the matching encryption key. Preserve the key from .n8n/config or your custom N8N_ENCRYPTION_KEY with access-controlled backups; encrypted credentials need it to be restored. See the encryption-key documentation. Never put keys or credential exports in Git.

Keep deployment configuration and the previous image version, then rehearse restoration in isolation. Workflow JSON exports alone are not a complete instance backup. For sustained production use, review the official PostgreSQL and runner guidance rather than assuming this minimal SQLite example covers every workload.

Which n8n version should you use after the 14 October security disclosures?

Checked 15 October 2026: this guide now pins n8n 2.43.5, released on 14 October, the current stable release. The previously shown 2.42.6 is no longer this guide's upgrade target. n8n 2.44.1 is a patched prerelease, not the stable production recommendation.

For an existing 1.x deployment, 1.123.85 is a listed branch fix for the webhook, file-node, credential-error and Quick Base advisories below. That does not establish coverage of every advisory or ongoing support for all 1.x deployments. Plan a move to 2.x separately with the full 2.0 migration guide, including runner, file-access, database/storage and workflow publication changes. Do not disable security defaults just to make an old workflow pass.

Which workflows and permissions need a review?

These six advisories were published on 14 October 2026. Their prerequisites and fixes differ; a disclosure is not evidence that your instance was compromised. Use each linked advisory for its affected-version details.

• Webhook responses, High 8.4: a member who can create and activate workflows can serve HTML through response paths missing sandbox protection. Another user opening that webhook URL can expose their n8n session to the page. Review webhook response content and who can activate workflows. Listed fixes: 1.123.85, 2.43.5 and 2.44.1. Webhook sandbox advisory.
• Data Tables, High 7.2: a member able to create and run workflows can access Data Table rows across projects, including reading, changing or deleting them. Review project boundaries with authorized test accounts. Listed fixes: 2.43.5 and 2.44.1; the advisory lists no 1.x fix. Data Tables authorization advisory.
• Read/Write Files, High 7.1: a member able to create and run file-node workflows can trigger path processing that blocks the main event loop, affecting the editor, API and webhooks. Review who can use this node. Listed fixes: 1.123.85, 2.43.5 and 2.44.1. File-node denial-of-service advisory.
• Secrets in execution errors, Moderate 5.3: certain failed operations in Git, MongoDB Atlas Vector Store and Google Cloud Storage can leave credential secrets in execution-error data. A person with execution-read access may see them without credential-read permission. Listed fixes: 1.123.85, 2.43.5 and 2.44.1. Credential exposure advisory.
• Quick Base filters, Moderate 5.3: untrusted Where expressions can alter query/delete scope within the credential's permissions. Fixes: 1.123.85, 2.43.5 and 2.44.1. Upgrading alone leaves unsafe expressions vulnerable: move dynamic values to Where Parameters and test with disposable data. Quick Base filter advisory.
• Workflow-history compaction, High 7.1: a low-privileged user who can save workflows can cause later history processing to disrupt instance logins and writes. This was already fixed in 2.41.4 and 2.42.1, according to the advisory's patch notes; it was not first fixed in the 14 October release. Workflow-history advisory.

The severity labels above follow the canonical GitHub advisories. While preparing the patch, restrict access to trusted users, reduce unnecessary execution-read permissions and review exposed webhooks or unused affected nodes. The advisories describe these as incomplete temporary mitigations, not replacements for remediation.

As a prudent operational follow-up, review relevant historical errors with restricted access and rotate credentials if exposure is suspected, following the service's procedure. This is not a claim of a leak on your server. Do not assume the patch deletes historical error copies or rotates secrets for you.

What should you check before upgrading to n8n 2.43.5?

Back up and test the selected patch before production. If you are coming from an older release, retain the legacy-node checks below: n8n 2.42.6's 9 October release introduced enforcement that changes how old workflows can be saved, imported and invoked.

Which legacy workflows are affected?

The default block covers Function, Function Item and LangChain Code. Already-saved workflows containing these nodes directly can run unchanged. Updates can retain an unchanged node, move its canvas position, delete it or migrate it to a supported version; editing its parameters, name, credentials or disabled state is rejected. Workflow JSON imports, including CLI restores into a fresh instance, and source-control pulls can therefore fail. Full database/volume restoration is a separate operation. See the breaking-change rules in n8n PR #40707.

The same PR identifies execution-time checks for subworkflows supplied as inline JSON, URLs or local files, Assistant single-node runs, and deprecated chat tools. Existing chat tools of a deprecated type stop working with enforcement enabled. An unchanged re-import into the existing workflow is allowed; that does not establish that the same export will import into a fresh instance.

A practical upgrade checklist

1. Inventory before changing versions. Record the running version, database/storage, enabled nodes and collaborators' permissions. List workflow owners and search current workflows, template JSON, backup exports, subworkflows and chat tools for the three legacy node types. Include unpublished work and the source-control path if your plan supports it.
2. Back up and prepare isolated staging first. Take a complete pre-upgrade backup and rehearse restoration. Use a separate database, volume and hostname. Block production destinations or replace credentials with test accounts before enabling triggers. Apply the selected patched n8n version in staging; complete the migrations and tests below there before changing production.
3. Migrate and compare outputs. Use the supported Code node for Function/Function Item logic, choosing the correct all-items or per-item mode. Rebuild LangChain Code logic with supported nodes for its purpose; do not assume a drop-in replacement. Check item shapes, errors and downstream side effects. Keep enforcement enabled: the old Function nodes still use the insecure vm2 sandbox identified in the PR.
4. Review dynamic Quick Base filters. Complete the parameter migration and scope tests described above, if applicable.
5. Test the paths you actually use. Check login, expected project/role isolation, file access, scheduled/webhook triggers, manual runs, edits and saves, subworkflow sources, Assistant and chat tools where configured, template imports, fresh-instance restore and source-control pulls where available. Verify credential decryption and expected outputs, not just an HTTP health check. Record failures and owners.
6. Review, then update production. Proceed only after the team accepts the test results and recovery plan. In a maintenance window, set the reviewed n8n image tag in Compose, pull that service and recreate it. Verify the running version with docker compose exec n8n n8n --version, then recheck logs and representative workflows. Do not assume an older image can read an upgraded database; use the rehearsed restoration procedure if recovery is needed.

These are recommended checks for your own deployment, not a claim that a particular server or workflow has been tested. For an upgrade from 1.x or an older 2.x release, also review all intervening breaking changes. Keep unrelated service and PostgreSQL major-version upgrades out of this security patch: the Compose documentation requires a separate database-upgrade procedure for an existing PostgreSQL deployment, rather than just changing its image tag.

When should you self-host vs use n8n Cloud?

Not every business needs to self-host. Here is a quick comparison:

Aspect	Self-host (VPS + Docker)	n8n Cloud
Data handling	You choose hosting and integrations	Review managed-service terms and integrations
Cost	Infrastructure, operations and external services	Plan subscription plus external services
Maintenance	Your team operates the instance	Provider manages the platform; your team maintains workflows
Best for	Teams with operational skills and specific hosting needs	Teams that prefer managed infrastructure

Choose based on operating skills, workload, recovery needs and where each integration sends data. Self-hosting alone does not guarantee privacy, compliance or fixed costs. Community n8n is source-available and fair-code; review the Sustainable Use License and n8n's licensing explanation for permitted use and commercial limits.

Just getting started and want the fundamentals first? See the n8n Indonesia hub, the What Is n8n guide, and the n8n tutorial. Once your server is ready, you can move on to n8n workflow examples for companies, AI agents with n8n, or a WhatsApp chatbot.

Who can help you self-host n8n in Indonesia?

For setup and team learning, explore Fahmi Fahreza's n8n templates and n8n training Indonesia. Review each template's nodes and credentials, then import and test it in staging before connecting production services.

A useful training agenda is a workflow and permissions inventory, legacy-node and Quick Base filter migration exercises, a restore rehearsal and a documented upgrade checklist. For help planning that work, see Corporate AI Training for Indonesian Teams or contact Fahmi.