Best Practices for Self-Hosting n8n in 2026

Self-hosting n8n gives you control over your workflows, credentials, data, and update schedule. It also means you are responsible for the boring but important parts: security, backups, upgrades, and monitoring.

This checklist is the 2026 version of what I would look at before trusting a self-hosted n8n instance with real automations.

1. Use A Real Domain And HTTPS

n8n depends heavily on webhooks. Those webhooks are easier to manage when your instance has a stable domain and valid HTTPS.

Use a reverse proxy like Caddy, Traefik, or Nginx. Caddy is the simplest option for most small setups because it handles certificates automatically:

n8n.example.com {
    reverse_proxy localhost:5678
}

After updating the config, reload Caddy:

sudo systemctl reload caddy

Avoid exposing port 5678 directly to the internet if you can. Put n8n behind the reverse proxy and only expose ports 80 and 443.

2. Set The Important n8n Environment Variables

Do not run production n8n with a random, changing encryption key. Set a stable N8N_ENCRYPTION_KEY and store it somewhere safe. If you lose it, credentials encrypted by n8n can become unusable.

For a production-style setup, review these values:

N8N_ENCRYPTION_KEY=replace-with-a-long-random-secret
N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.example.com/
N8N_SECURE_COOKIE=true
GENERIC_TIMEZONE=Europe/Berlin

This keeps webhooks, cookies, and generated URLs aligned with your public domain.

3. Use Postgres For Serious Setups

SQLite is fine for testing and tiny personal automations. For anything important, use Postgres. It is more robust for concurrent workloads, easier to back up safely, and a better fit once workflows become business-critical.

If you stay on SQLite, be extra careful with file backups and stop n8n before taking a filesystem-level backup.

4. Back Up Both Data And Credentials

Your backup plan needs to cover the database, n8n files, and your encryption key. A database backup without the encryption key is not enough.

For a Docker volume backup, use a pinned image version:

mkdir -p backups

docker run --rm \
  -v n8n_data:/source:ro \
  -v "$(pwd)/backups:/backup" \
  ubuntu:24.04 \
  tar cvf /backup/n8n-data-$(date +"%Y-%m-%d").tar /source

Then copy the backup off the server:

rclone copy ./backups remote:my-backups/n8n/

Test restores regularly. A backup you never restore is just a hopeful file.

5. Keep The Server Small And Locked Down

For a basic Ubuntu server, allow only SSH, HTTP, and HTTPS:

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable

Also install automatic security updates:

sudo apt update
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

If you use Docker, remember that Docker can interact with firewall rules in surprising ways. Test from the outside and check which ports are actually reachable.

6. Watch Disk, Memory, And Failed Executions

n8n problems often show up as boring resource issues: disk fills up, memory gets tight, or execution logs grow faster than expected.

At minimum, monitor:

• CPU and RAM
• Disk usage
• Container restarts
• Failed workflow executions
• Backup success/failure
• TLS certificate renewal

For quick manual checks:

docker ps
docker logs --tail=100 n8n
df -h
free -m

7. Update Intentionally

Do not blindly auto-update production n8n if your workflows matter. New versions can change nodes, dependencies, or behavior.

A safer update flow:

docker compose pull
docker compose up -d
docker compose logs -f n8n

Before updating, take a backup. After updating, test your most important workflows and webhooks.

8. Scale Only When You Need It

Most self-hosted n8n instances do not need advanced scaling. Start with one instance and enough RAM. If workflows become heavy, scale vertically first.

When you truly need more throughput, look into queue mode, workers, external Postgres, Redis, and object storage. At that point, you should treat n8n like production infrastructure and document the setup.

9. Consider Managed Self-Hosting

If the checklist above sounds like the opposite of why you wanted n8n, use managed Docker hosting.

Sliplane can deploy n8n with HTTPS, persistent storage, logs, backups, and scaling from the dashboard. You still run your own n8n instance, but you do not have to maintain the server manually.