How I built my self-hosted stack with Hetzner, Coolify and n8n

What each component does

The responsibilities are straightforward:

Hetzner Cloud
└── Linux server
    └── Coolify
        ├── Reverse proxy and TLS certificates
        ├── Web applications
        ├── n8n and its database
        └── Monitoring service

• Hetzner Cloud provides the machine, network, snapshots and cloud firewall.
• Coolify deploys and supervises containers and manages domains and the proxy.
• n8n executes workflows and stores credentials, definitions and execution history.
• Monitoring checks that services respond and important workflows complete.

A server outage affects every component when they share one machine. This design therefore accepts a single point of failure. It fits a constrained budget and recoverable processes, not a high-availability requirement.

Choose the server from current specifications

The current CX23 no longer matches the specifications quoted in the old guide. Hetzner lists:

• 2 shared vCPUs;
• 4 GB RAM;
• 40 GB storage;
• 20 TB included traffic in European locations.

Coolify requires at least 2 cores, 2 GB RAM and 30 GB of free storage. A CX23 meets the technical threshold but leaves little headroom if the same server builds a Next.js application, runs n8n and stores data. Watch RAM, disk and load during builds. For several services or heavy workflows, choose a larger server or a separate build server.

Following the June 15, 2026 price adjustment, Hetzner lists a new CX23 in Germany or Finland at EUR 5.49 per month excluding VAT and IPv4. A complete installation may also need an IPv4 address, backups, a domain and external storage. Check the current Hetzner price table before ordering.

For production I start with a clean Ubuntu LTS image in a European region appropriate for the data. Coolify's automatic installer officially supports Ubuntu LTS 20.04, 22.04 and 24.04.

Prepare SSH and the firewall

Add your SSH key before disabling password authentication. Coolify uses SSH even to manage the server on which it runs. Its documentation recommends PermitRootLogin prohibit-password when the installation uses root.

The Hetzner Cloud Firewall is preferable to an isolated UFW rule set. Docker adds network rules that can bypass UFW. For a self-hosted installation, Coolify documents these ports:

After routing the dashboard through a custom domain and Coolify's integrated proxy, the Coolify firewall guide says that ports 8000, 6001 and 6002 can be closed. Do not expose the internal ports of n8n, PostgreSQL or other services directly.

Install Coolify with the current command

Connect to a fresh compatible server through SSH and run the recommended command:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

If the session already runs as root, sudo is unnecessary. The script installs required tools, Docker Engine, directories under /data/coolify and Coolify itself. Docker installed through Snap is not supported.

At the end, the installer prints an address similar to:

http://203.0.113.1:8000

Open it immediately and create the first administrator account. Until that account exists, another person reaching the registration page could take control of the instance. The correct port is 8000, not 3000.

The Coolify installation documentation remains the source of truth if the command or prerequisites change.

Connect a repository and deploy an application

In Coolify:

1. add the GitHub source with the minimum necessary permissions;
2. select the repository and production branch;
3. choose the build method for the project, such as a Dockerfile committed with the code;
4. declare environment variables in Coolify instead of committing them;
5. add the domain and verify its certificate;
6. configure a health check against a real application endpoint;
7. enable failed-deployment notifications.

A push can trigger deployment through the GitHub integration, but build time varies with the project and available resources. A recovery procedure should not depend on a promised two-minute deployment.

Deploy n8n without legacy configuration

Coolify provides n8n as a service. Use the platform-maintained template instead of copying a compose file from an old tutorial. The template should keep data in persistent storage or in its associated data services.

Exact settings vary, but check these values at minimum:

N8N_HOST=automation.example.com
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://automation.example.com
WEBHOOK_URL=https://automation.example.com/
GENERIC_TIMEZONE=Europe/Paris
TZ=Europe/Paris
N8N_ENCRYPTION_KEY=<long-stable-secret>

Do not restore the old N8N_BASIC_AUTH_ACTIVE, N8N_BASIC_AUTH_USER and N8N_BASIC_AUTH_PASSWORD variables from this guide. Use n8n's built-in user management, protect the owner account with a unique password and enable two-factor authentication where available.

Store N8N_ENCRYPTION_KEY in a vault separate from the server. Without it, a database restoration can leave encrypted credentials unusable.

Do not publish port 5678 directly to the Internet. Coolify should route n8n through its HTTPS proxy. For business data, prefer PostgreSQL to an isolated local database and back up both the database and persistent files.

Back up what a recovery needs

A Hetzner snapshot should not be the only backup. It remains with the same provider and does not prove that recovery works.

Keep the following outside the server:

• an n8n database backup;
• the n8n encryption key;
• required variables and secrets in a vault;
• persistent data for the other services;
• DNS configuration and the recovery procedure;
• when useful, versioned workflow exports without credentials.

Test recovery on a separate instance. Confirm that n8n starts, decrypts credentials, receives a webhook and runs a control workflow.

Monitor services and workflows

An HTTP check on the login page only confirms that the proxy and application respond. Add at least:

• an external HTTPS check for Kirako and n8n;
• alerts on disk space and memory;
• notifications for failed n8n executions;
• a scheduled sentinel workflow;
• an alert when that workflow stops sending its signal;
• backup age and completion monitoring.

n8n also provides a security audit command that reports unused credentials, unprotected webhooks, risky nodes and an outdated instance.

Update without breaking production

Do not use the latest tag blindly for a critical service. Read release notes, back up the instance, update in a planned window and test important workflows. For n8n, pay particular attention to major-version changes, community nodes and execution settings.

The same principle applies to Coolify and the operating system. A self-hosted stack gives the team control over when and how to update. It also makes the team responsible for keeping components current.

The VPS bill is not the full cost

The base machine can remain inexpensive. A fair comparison also includes:

Self-hosting can reduce subscription costs and provide more control. It is not automatically cheaper when nobody owns operations. Start with the cost of an outage and the acceptable recovery time when comparing it with a managed service.

Official sources

• Coolify: self-hosted installation
• Coolify: ports and firewall
• Coolify: OpenSSH configuration
• Hetzner: cost-optimised instance specifications
• Hetzner: June 15, 2026 price adjustment
• n8n: security audit for self-hosted instances

Going further

This stack becomes useful when it supports a specific process, such as automating Pennylane invoicing with n8n. For a company, I would start with a non-critical workflow and verify backups and alerts before moving a process that can block invoicing or customer service.

If you want to keep n8n self-hosted without carrying every architecture and operations decision alone, the n8n consultant for companies page explains Kirako's support.