Self-Hosted n8n Setup: Install, Backup and Security Checklist

Self-Hosted n8n Setup: Install, Backup and Security Checklist

The most common way to self-host n8n is Docker Compose on a Linux machine, with PostgreSQL instead of the default database, a reverse proxy serving HTTPS in front, and the encryption key stored away from the server. The installation itself is quick. What separates a test from a reliable operation is a backup that actually restores, controlled access, and webhooks exposed with care.

Key takeaways

• Use PostgreSQL from day one in production, and pin the n8n image version instead of relying on the latest tag.
• The n8n encryption key protects your saved credentials. Without it, a database backup does not give your access back.
• A backup only counts after a restore test on a different machine, with the database, the key and the configuration.
• Update in a test environment with a copy of your workflows before touching production.
• Expose to the internet only what has to be exposed: keep the editor restricted, and give production webhooks authentication and validation.

What should you decide before installing n8n on your own server?

Before opening the terminal, answer four questions. They prevent rework later.

• Who owns the server? Someone has to handle system updates, disk space, certificates and backups. If nobody has that role, consider a managed service.
• What data passes through the workflows? If customer personal data is involved, Brazil's LGPD applies to the server, the logs and the backup copies. The national data protection authority (ANPD) is the official reference for ongoing guidance.
• Where does the server live? A server outside Brazil can count as an international data transfer. Read the article on international data transfer under LGPD when using AI providers first.
• Does the license fit your use? n8n uses its own license, with rules about commercial use. Read the terms in the official documentation and confirm your case fits, especially if you plan to offer n8n to third parties.

It also helps to separate what comes from official documentation from what comes from deployment experience. Variable names and configuration paths change between versions, so check everything against the official n8n hosting documentation before applying it.

How do you install n8n with Docker Compose and PostgreSQL?

The plan below describes the order of decisions, not a command to copy. The exact details of each file are in the official documentation.

• Prepare a Linux VM with a separate disk for data, an active firewall and SSH key access, with password login disabled.
• Install Docker and Docker Compose from the official repositories.
• Run two services: n8n and PostgreSQL, each with a persistent volume. Without a volume, the data disappears when the container is recreated.
• Configure n8n to use PostgreSQL (the database type variable points to postgresdb) with a dedicated user and a long password.
• Set the encryption key (N8N_ENCRYPTION_KEY) manually and keep a copy in a password vault. Do not let n8n generate it on its own and leave it only inside the volume.
• Set the public URL (WEBHOOK_URL) and the domain so the generated webhook addresses are correct.
• Put a reverse proxy with HTTPS in front (Nginx, Caddy or Traefik). n8n should not receive internet traffic directly without TLS.
• Pin the n8n image version and record which one is running.
• Create the instance owner account, turn on two-factor authentication when available, and disable sign-ups you do not need.

The lightweight default database is fine for experiments, but in production PostgreSQL makes backup, monitoring and growth easier. If execution volume grows, the documentation describes queue mode with workers and Redis. Do not start there without a reason: more components mean more things to maintain.

Finally, configure automatic pruning of execution history (the execution prune variables). Without it, the database keeps growing with customer data that passed through your workflows, which costs you both disk space and privacy.

Where are credentials stored, and why does the encryption key matter?

n8n stores the credentials you register (API tokens, passwords, OAuth access) in the database, encrypted with the instance's encryption key. That has two practical consequences.

First, if you lose the key, a database backup restores your workflows, but the credentials become unreadable and you will have to re-enter all of them. Second, anyone who holds both the database and the key has access to every connected system. That is why the key should be stored in a different place from the database backup.

Simple good practices for credentials:

• Use service accounts or tokens with minimum permissions, never an administrator's personal login.
• Prefer one access credential per system, so you can revoke one without taking down the others. The least privilege principle is described in the OWASP authorization cheat sheet.
• Keep a list of which credentials exist, who created them and which workflow uses each one.
• Rotate access when someone leaves the team.
• Do not put secrets inside code nodes or in plain text fields of your workflows.

If your workflows include an AI agent with access to tools, limit what it can do and how many steps it can take. The article on step limits for AI agents shows how to prevent runaway executions.

How do you make an n8n backup that actually restores?

A complete n8n backup has four parts. A missing piece is usually discovered at the worst possible moment.

• The PostgreSQL database, with a periodic dump and a copy sent off the server.
• The encryption key, stored separately in a password vault.
• The configuration files: the Compose file, the environment variables and the proxy configuration.
• An export of workflows and credentials through the n8n CLI, or into a version control repository, as an extra and readable layer.

Agree with the process owner on how long the company can operate without the workflow (recovery time) and how much data it can afford to lose (the interval between backups). Those two answers determine the frequency and location of your copies, not the other way around.

The step almost nobody takes is restoring. Set aside time to bring up a clean instance on another machine, import the database, supply the key and check that the workflows open and the credentials work. Write down how long it took and what went wrong. Repeat it after any major infrastructure change.

On LGPD, remember that the backup also contains personal data. It needs restricted access, encryption at rest and a defined retention period.

How do you update n8n without breaking workflows?

Updating is necessary because security fixes arrive in new versions. But a rushed update can change how a node behaves and stop an important routine. The process below reduces the risk.

• Read the release notes and look for breaking changes.
• Take a full backup and confirm it finished.
• Start a test copy with the restored database and the new version.
• Run the critical workflows manually and compare the results with what you expect.
• Update production during a low-traffic window and keep the previous version ready for rollback.
• Record the date, the version and the outcome.

The same applies to the operating system, Docker, PostgreSQL and the proxy. A simple maintenance calendar with a named owner keeps the server from sitting on an old version for years.

How do you control access and webhook exposure?

n8n has two different surfaces, and they deserve different treatment.

The first is the editor, where workflows are built and where credentials and executions can be seen. It should not be open to anyone on the internet. Common options: restrict it by VPN, by an IP allowlist, or by an access provider with corporate login in front of the proxy. Use individual accounts, never a shared one, so the history shows who changed what.

The second is production webhooks, which must be reachable by external services such as a payment provider or the WhatsApp API. Here the goal is to expose as little as possible.

• Separate the paths: the proxy should forward only the webhook routes, not the editor.
• Require authentication on the webhook node (for example, a header with a secret) whenever the sender allows it.
• Validate the signature when the provider offers one. Stripe's webhook documentation is a good example of the pattern: verify the signature, reject anything that does not match, and handle repeated deliveries.
• Plan for idempotency: the same event can arrive twice, and the workflow must not charge or send a message twice.
• Apply rate limiting at the proxy and log the calls it rejects.
• Do not put sensitive data in the webhook URL, because URLs show up in logs.

If the workflow receives customer messages from WhatsApp, the care extends further: see the guide on how to integrate AI into your company's WhatsApp to understand what the platform requires before you connect a workflow to the number.

Finally, watch what happens. Alerts for failed executions, a full disk and a certificate close to expiry cost little and prevent surprises. The concepts of logs, metrics and traces are summarized in the OpenTelemetry observability primer.

How do you apply map, limit, pilot and hand over to n8n?

The method we use for AI automation works well for infrastructure too. Map: list the workflows that exist or will be built, the data that flows through them and the systems they connect to. Limit: give each workflow only the credentials and permissions it needs, and expose only the webhooks that are necessary. Pilot: start with one real workflow, with logs and an agreed success criterion, before migrating the rest. Hand over: give the team a short manual for backup, restore and updates, and decide together whether to expand, adjust or stop.

Illustrative scenario: a services company wants n8n to receive quote requests from a web form and log them in a spreadsheet, notifying the sales team. Instead of migrating everything at once, it installs n8n with PostgreSQL, turns on only that workflow, exposes only the form webhook with a secret header, and keeps the editor reachable only through the VPN. After a few weeks, it runs a restore test on another machine and only then decides to bring over the second workflow. For teams that prefer not to operate the server, managed operation can be provided through Be Human.

Final checklist before going to production

• PostgreSQL in use, with a persistent volume and a strong password.
• Image version pinned and recorded.
• Encryption key stored off the server.
• HTTPS active, editor restricted and individual accounts in place.
• Webhooks with authentication and, when possible, signature validation.
• Automatic backup, an off-site copy and a tested restore.
• Execution history pruning configured.
• A named owner for updates and alerts.

Frequently asked questions

Is it safe to use self-hosted n8n for customer data? It can be, as long as you control access, use HTTPS, restrict the editor, protect the backup and define how long you keep execution history. LGPD still applies to the server, and whoever decides the purpose of the processing has to document it. If you are unsure about the legal basis, consult a data protection professional.

Can I install n8n without Docker? Yes, the official documentation describes other installation methods. Docker Compose is usually preferred because it makes it easier to pin versions, repeat the installation on another machine and restore the environment. The choice should reflect what your team already knows how to operate.

What happens if I lose the n8n encryption key? The workflows can be restored from the database, but the saved credentials will no longer be readable, and you will need to re-enter each one. That is why the key should live in a password vault, separate from the database backup, and be part of your restore test.

How often should I update n8n and test the backup? Update when relevant security fixes are released, always passing through a test environment first. For backups, frequency comes from how much data the company accepts losing, and the restore should be tested periodically and after major infrastructure changes.

Sources

• n8n: documentação de hospedagem (self-hosting)
• Stripe: entrega e verificação de webhooks
• OWASP: guia de autorização
• ANPD: Autoridade Nacional de Proteção de Dados