Self Hosting n8n on Docker for Privacy: Complete Setup Guide

Quick Answer: A guide to self hosting n8n on Docker for privacy involves provisioning a Linux server, setting up Docker and Docker Compose, and deploying n8n alongside a PostgreSQL database. By routing traffic through a reverse proxy with SSL and isolating the Docker network, you ensure that sensitive workflow data, API keys, and internal automation logic remain strictly under your control, entirely separate from third-party cloud infrastructure.

As automation becomes deeply integrated into everyday business operations, the volume of sensitive data passing through integration platforms has skyrocketed. When you connect your CRM, email provider, internal databases, and communication tools, you are creating a central nervous system for your digital operations. Using hosted SaaS solutions means trusting a third party with the credentials and raw data from every single connected service.

For privacy-conscious individuals and organizations handling sensitive information, this presents a significant risk. The alternative is bringing the automation engine in-house. n8n is a powerful, source-available workflow automation tool that rivals commercial alternatives while allowing you to run it on your own hardware.

This guide outlines the precise steps and architectural decisions required to deploy n8n securely using Docker. By isolating the application and its database, controlling the environment variables, and managing network access, you establish a resilient and private automation hub.

Why Self-Host n8n Instead of Cloud?

When you choose to host automation software yourself, you are making a deliberate trade-off between convenience and control. The primary driver for self-hosting n8n is data sovereignty.

Cloud-based automation platforms process your webhooks, API requests, and data payloads on their servers. If a platform experiences a security breach, your API keys and workflow data could be exposed. Furthermore, compliance requirements like GDPR, HIPAA, or strict internal security policies often mandate that data must not leave specific geographic regions or controlled environments.

By running n8n on your own Docker infrastructure, the execution happens on your terms. The database storing your execution logs, credentials, and workflow definitions resides on a disk you own. You dictate the backup schedules, the retention policies, and the network access rules. If you need to restrict access strictly to a corporate VPN or a specific set of static IP addresses, you have the authority to implement those firewall rules at the host level.

Prerequisites for Running n8n on Docker

Before executing the deployment, ensure your infrastructure meets the necessary specifications. While n8n can run on minimal hardware, executing complex workflows with large data payloads requires adequate resources.

You will need a Linux-based server or virtual machine running Ubuntu 22.04 LTS or Debian 12. A minimum of 2GB of RAM is required, but 4GB of RAM and at least 2 CPUs are strongly recommended if you expect parallel workflow executions or heavy data processing. For storage, start with a 40GB SSD, keeping in mind that execution logs can consume disk space rapidly over time.

From a software perspective, your server must have Docker Engine and Docker Compose installed. You also need a registered domain name and the ability to modify its DNS records to point a subdomain (such as n8n.yourdomain.com) to your server’s public IP address.

Step 1: Preparing Your Server Environment

Security begins at the host operating system. Before touching Docker, you must secure the foundation. Connect to your server via SSH using key-based authentication, and disable password logins in your SSH configuration to prevent brute-force attacks.

Ensure your system packages are up to date. Establish a basic firewall using UFW (Uncomplicated Firewall). You only need to expose port 22 for SSH, port 80 for HTTP (which will redirect to secure traffic), and port 443 for HTTPS. All internal communication between n8n and its database will happen within an isolated Docker network, meaning the database port should never be exposed to the public internet.

Create a dedicated system user for managing Docker deployments. Running applications as the root user is a massive security vulnerability. Create a standard user account, add it to the Docker group, and execute all subsequent deployment steps under this context.

Next, establish a clean directory structure. Create a dedicated folder named n8n-docker in your home directory. Inside this folder, create two files: docker-compose.yml for the service definitions, and .env for your sensitive configuration variables.

Step 2: Creating the Docker Compose File

While n8n can run using a default SQLite database, this is not recommended for production environments or heavy usage. Database locking issues will inevitably cause workflow failures. Instead, a robust setup pairs the n8n application container with a dedicated PostgreSQL database container.

Your docker-compose.yml file must define a custom bridge network. Both the PostgreSQL container and the n8n container will attach to this network, allowing them to communicate securely using container names as hostnames.

Define the PostgreSQL service first. Map a persistent Docker volume to the database data directory inside the container. This ensures that your workflow configurations and execution history survive container restarts or image updates. Set the container to restart automatically unless explicitly stopped.

Next, define the n8n service. Specify the official n8nio/n8n image. Map a second persistent volume for the n8n local files, which handles binary data from workflows and SSH keys for local git nodes. Connect the n8n service to the custom network and specify that it depends on the successful startup of the PostgreSQL database.

Crucially, do not expose the n8n application port directly to the host machine’s public interface. Instead, you will bind it to the local loopback address or rely on a reverse proxy container defined in the same compose file, ensuring that all external traffic must pass through an encrypted HTTPS layer before reaching the n8n application.

Step 3: Configuring Environment Variables for Privacy

The .env file is where you enforce your privacy and security policies. Never hardcode credentials into your docker-compose.yml file.

First, define the database credentials. Set strong, randomized strings for the PostgreSQL user, password, and database name. In the n8n service configuration, reference these same variables to establish the database connection. Instruct n8n to use Postgres instead of its default SQLite engine by setting the DB_TYPE variable to postgresdb.

To enforce privacy, you must disable n8n’s telemetry. By default, n8n sends anonymous usage statistics to its developers. While benign, strict privacy policies dictate that no outbound connections should be made without explicit consent. Set the N8N_DIAGNOSTICS_ENABLED variable to false.

You must also secure the n8n frontend. Define a username and a strong passphrase for basic authentication, or configure n8n to use an external identity provider if your organization relies on SSO. Specify the WEBHOOK_URL variable to match the full HTTPS domain name you intend to use. This is critical for workflows that receive incoming data from external services; n8n must know its own external address to generate correct webhook endpoints.

Configure your execution settings carefully. Set EXECUTIONS_DATA_PRUNE to true and define a reasonable EXECUTIONS_DATA_MAX_AGE, such as 168 hours (7 days). If you do not prune execution logs, the database will eventually consume all available disk space, causing the server to crash.

Step 4: Launching and Securing Your Instance

With the configuration files staged, you need a reverse proxy to handle SSL/TLS termination. Caddy is highly recommended for privacy setups because it automatically provisions and renews SSL certificates from Let’s Encrypt without complex configuration.

You can add Caddy as a third service in your docker-compose.yml. Map port 80 and port 443 to the host, and attach it to the same internal Docker network as n8n. Create a Caddyfile in your deployment directory. The configuration only requires your domain name and a directive to reverse proxy all traffic to the internal n8n container port.

Once the reverse proxy is configured, execute the deployment by running the Docker Compose up command in detached mode. Docker will pull the PostgreSQL, n8n, and Caddy images, create the isolated network, initialize the database, and start the application. Caddy will detect the domain, negotiate an SSL certificate, and secure the connection.

Navigate to your domain in a web browser. You should be greeted by the n8n setup screen over a secure HTTPS connection. Create your owner account immediately. Do not leave a newly provisioned instance sitting idle on the internet without an owner account established.

Practical Advice for Maintenance and Longevity

Running an automation server is an ongoing responsibility. To maintain privacy and security, you must implement a rigorous update schedule. Subscribe to the n8n release notes. When a security patch or minor version is released, update your instance by pulling the latest Docker images and recreating the containers. Because your data is safely stored in persistent volumes, your workflows will remain intact during this process.

Implement a 3-2-1 backup strategy for your Docker volumes. The workflow definitions and execution logs reside inside the PostgreSQL database volume. Use a cron job on the host machine to execute pg_dump against the database container nightly. Encrypt this backup archive locally before transmitting it to secure offsite storage, such as an S3-compatible bucket or an encrypted internal file server. Never rely solely on snapshotting the virtual machine.

Consider the network placement of your webhooks. If your n8n instance only automates internal infrastructure and does not need to receive data from public APIs like Stripe or GitHub, do not expose the Caddy reverse proxy to the public internet. Instead, bind the proxy only to a local Tailscale or Wireguard network interface. This creates a zero-trust automation environment where workflows can reach out to the internet, but the internet cannot reach your n8n instance.

Lastly, monitor your resource consumption. Workflows that manipulate large files, process thousands of rows of database data, or utilize complex image manipulation nodes will spike CPU and RAM usage. Set up Docker resource limits in your compose file to prevent a runaway workflow from starving the host operating system of resources and crashing the server.

Conclusion

Taking ownership of your automation infrastructure is the definitive way to protect sensitive data flows. A guide to self hosting n8n on docker for privacy culminates in an environment where you dictate the rules of engagement. By leveraging Docker for isolation, PostgreSQL for stability, and a reverse proxy for encrypted transport, you remove third-party risk from your critical operations. Maintain strict network controls, adhere to a regular backup schedule, and your self-hosted instance will serve as a secure, high-performance engine for all your automation requirements.

Frequently Asked Questions

Can I self-host n8n for free?

Yes, n8n has a community edition available under a fair-code license that allows you to self-host it for internal use free of charge. You only pay for the infrastructure (like your VPS or server) required to run the Docker containers.

Is SQLite sufficient for a production n8n environment?

No. While SQLite is acceptable for testing or isolated local development, it struggles with concurrent database writes. For a stable, private production environment, you should always configure n8n to use a PostgreSQL database container.

How do I update n8n when running it via Docker?

Updating is straightforward. Navigate to the directory containing your docker-compose.yml file, run a command to pull the latest image versions, and then run the command to recreate the containers in detached mode. Your data remains safe in the persistent volumes.

Can I hide my n8n instance from the public internet entirely?

Absolutely. If you do not require webhooks from external services, you can configure your firewall to block external port 443 access and strictly route traffic through a private VPN like WireGuard or Tailscale, keeping your instance completely hidden.

Does n8n send my data back to its creators?

By default, n8n collects anonymous telemetry data for diagnostic purposes. However, when self-hosting, you have the ability to completely disable all outbound telemetry by setting the N8N_DIAGNOSTICS_ENABLED environment variable to false.

---

Related Reading

• Automate Content with n8n and Claude: Complete Guide

• Setup Local First AI Research Assistant with Mistral: Full Guide

• 15 Best n8n Workflow Templates for Marketing Agencies 2026