Protecting n8n with IP Whitelisting (Full Setup Guide)

Someone just tried to access your n8n editor from an IP address in a country where you have zero employees. Scary? It should be. Your workflow definitions contain everything: OAuth tokens, database credentials, and the logic powering your business.

IP whitelisting stops unauthorized users before they reach your door. Let’s set it up properly.

Secure VPS Platforms for IP Restricted n8n Deployments

Provider	User Rating	Recommended For
	4.8	Scalability	Visit Kamatera
	4.6	Affordability	Visit Hostinger
	4.7	Developers	Visit IONOS

Introduction to Securing Your n8n Instance

Why Protecting n8n with IP Whitelisting is Essential

Your n8n instance isn’t just another application. It’s the nerve center of your automation infrastructure. Every workflow you create contains sensitive data: API keys, database credentials, bearer token values, and the business logic connecting your systems.

The editor UI represents your most vulnerable surface area. Anyone with access can view your workflows, modify automation logic, and extract connected account credentials. IP whitelisting creates a network-level barrier that stops unauthorized traffic before it touches your application.

Think of it this way: basic authentication protects your front door. IP whitelisting removes your house from the map entirely for everyone except trusted visitors.

Setting up IP address restrictions requires initial configuration work. But the peace of mind? Worth every minute. You’re essentially hardening your production environment against external threats while maintaining full functionality for legitimate users.

The Balance of Security and Accessibility

Every security measure involves tradeoffs. IP whitelisting is no exception.

On the positive side, this approach offers robust protection that blocks unauthorized requests at the network layer. Attackers can’t probe your login page, attempt brute force attacks, or exploit potential vulnerabilities if their traffic never arrives.

The challenges? Managing dynamic IPs for remote teams gets tedious quickly. Cloud-based services rotate their source IPs constantly. If your marketing director works from coffee shops, their IP changes daily.

Here’s what works: combining IP whitelisting with strong authentication creates layered protection. Trusted IPs get through the first gate. Strong credentials guard the second. This defense-in-depth strategy safeguards your data while keeping legitimate users productive.

Understanding n8n Cloud and Outbound IP Address Challenges

How n8n Cloud Handles Outbound Traffic

When you choose n8n hosting through the cloud option, your instance runs within dynamic infrastructure designed for seamless scaling. The platform adjusts resources automatically based on demand.

Outbound traffic from n8n cloud routes through shared infrastructure using Cloudflare for egress management. This architecture prioritizes reliability and performance. The tradeoff? A single IP address for your outbound connections simply isn’t guaranteed.

Understanding this reality helps you plan your integration strategy. If you’re connecting to strict corporate firewalls or enterprise APIs, you’ll need workarounds.

The Problem with Rotating IP Addresses

n8n Cloud utilizes approximately 22 rotating IP addresses. These can change at any time without prior notice. Some users report rotations within 72-hour windows.

Why does this matter? Traditional IP whitelisting becomes unreliable. Your connections might work perfectly today and fail tomorrow. Common casualties include:

• Corporate firewalls and WAF rules configured on Cloudflare, Akamai, or AWS
• Enterprise APIs like Salesforce, HubSpot, and Marketo
• Financial and healthcare APIs with strict compliance requirements
• Secure databases including MongoDB Atlas and Amazon RDS

When your automation suddenly stops working, rotating IPs are often the culprit.

List of Current n8n Cloud IP Addresses and CIDRs

While subject to change, here are the specific IPs and CIDR blocks your outbound traffic might originate from.

Single IP Addresses (/32): 20.79.227.226, 20.113.47.122, 20.218.202.73, 98.67.233.91, 4.182.111.50, 4.182.129.20, 4.182.88.118, 4.182.212.136, 98.67.244.108, 72.144.128.145, 72.144.83.147, 72.144.69.38, 72.144.111.50, 4.182.128.108, 4.182.190.144, 4.182.191.184, 98.67.233.200

CIDR Blocks (/28): 20.52.126.0/28, 20.218.238.112/28, 4.182.64.64/28, 20.218.174.0/28, 4.184.78.240/28, 20.79.32.32/28, 51.116.119.64/28, 51.107.180.112/28

Add these to your whitelist for temporary testing. Just remember: they rotate.

Ultahost

Launch, Scale, and Manage your website with high-performance Web Hosting and VPS.

Visit Site Coupons6

Inbound Access Controls: Securing Self-Hosted n8n Instances

Why You Must Hide Port 5678

The default configuration exposes n8n on port 5678. Leaving this open to the internet is a critical security mistake.

Remove any Docker ports mapping that directly exposes the service to the web. Your n8n instance should only communicate through internal networks.

Verification step: Run curl -v http://YOUR_SERVER_IP:5678 from an external location. The connection should time out or be refused. If you see the n8n interface, you have a problem.

Setting Up a Reverse Proxy for Your n8n Instance

All inbound traffic should route through a reverse proxy like Caddy, Nginx, or Traefik. This setup provides several advantages.

The proxy handles TLS termination on standard ports 80 and 443. It masks your internal application structure from external observation. Most importantly, it creates a centralized point to configure access controls.

For affordable hosting options that support this architecture, look for VPS providers offering full root access and Docker support.

Configuring an IP Allowlist in Caddy

Caddy makes implementing strict IP restrictions straightforward. Here’s the configuration logic:

@blocked not remote_ip 203.0.113.10 198.51.100.0/24
respond @blocked 403
reverse_proxy n8n:5678

This configuration checks every incoming request. If the IP address falls outside your specified ranges, the server immediately returns a 403 Forbidden error. Authorized IPs pass through to your n8n instance seamlessly.

Protecting the Editor UI While Keeping Webhooks Public

Most deployments need split access. Your team accesses the editor. External services trigger webhooks. Different security requirements for each path.

Here’s a Caddyfile example that accomplishes this:

handle /webhook/* { reverse_proxy n8n:5678 }
handle /webhook-test/* { reverse_proxy n8n:5678 }
handle {
    @blocked not remote_ip 203.0.113.10
    respond @blocked 403
    reverse_proxy n8n:5678
}

Webhook URLs remain accessible from anywhere. The editor UI stays locked to specific IPs. Check our guide on securing webhooks in n8n for additional protection strategies.

Outbound IP Whitelisting: Static IP Solutions for n8n Cloud

Bypassing Dynamic IPs with a Static IP Proxy

Connecting n8n cloud to corporate firewalls requires static IPs. Services like QuotaGuard solve this problem by routing your traffic through dedicated addresses that never change.

Pricing and performance breakdown:

• QuotaGuard Static: $19/month (includes 2 IPs and 500GB bandwidth)
• QuotaGuard Shield: $29/month (adds HIPAA/PCI compliance and SSL passthrough)
• Latency impact: 10-20ms same-region, 50-100ms cross-region

For workflows hitting strict enterprise APIs, this investment pays for itself in reliability.

Configuring the HTTP Request Node for Static Egress

The HTTP request node offers the most reliable method for routing traffic through your proxy.

Inside the node settings, enable the Proxy option. Input your client URL in this format: http://username:password@us-east-static-01.quotaguard.com:9293

Test by sending a request to https://ip.quotaguard.com. The response should show your new static IP. Verification complete.

Managing Credentials and API Keys Securely

Never hardcode passwords or API keys directly into workflow nodes. Create an HTTP Basic Auth credential within n8n containing your proxy URL and authentication details.

Reference this credential across multiple nodes. Centralized management simplifies updates and enhances security. Consider using a secrets manager for production deployments handling encrypted customer data.

Setting Environment Variables for Global Proxy Access

Self hosted deployments can force all outbound traffic through your proxy using environment variables. Set HTTP_PROXY and HTTPS_PROXY in your server configuration to your proxy URL with credentials.

Note: global environment variable proxying currently isn’t supported in n8n cloud. You’ll need per-node configuration there.

Build Your App Now with Hostinger Horizons

Turn your idea into a powerful app in minutes with Hostinger Horizons. No coding, no hassle, just AI-powered building that brings your vision to life.

Visit Hostinger

Connecting Databases and SFTP Servers

Non-HTTP services like SFTP and direct database connections create unique challenges. n8n cloud lacks native SOCKS5 or QGTunnel support required for these protocols.

Workarounds exist: Create an HTTP intermediary API to interact with your database. Or migrate to a self hosted n8n instance where full network control becomes possible. Our n8n vs Make comparison explores platform differences relevant to this decision.

Advanced Security Measures and Access Controls

Implementing VPNs (WireGuard and Tailscale) as Alternatives

Remote teams make IP allowlist management exhausting. Every home network, coffee shop, and airport lounge means another IP to track.

VPN access through WireGuard or Tailscale places your n8n editor behind a private network. Team members connect to the VPN first, then access the instance. No more chasing dynamic IPs.

Webhook endpoints can remain public while everything else stays protected. Check our guide on security hardening for self-hosted n8n for complete implementation details.

Utilizing Cloudflare Access and Cloudflare Tunnels

Cloudflare tunnel creates secure connections between your server and Cloudflare’s network without opening public inbound ports. Your firewall stays locked down.

Layer Cloudflare access on top for SSO authentication. Users must verify their identity before reaching your n8n login screen. Two layers of protection before anyone sees a password field.

Firewall Configurations (UFW) and Port Management

A robust server-level firewall is non-negotiable. Using UFW, set your default policy to deny all incoming traffic, then explicitly enable only what’s needed:

• Allow 22/tcp (SSH for server management)
• Allow 80/tcp (HTTP for proxy routing)
• Allow 443/tcp (HTTPS encryption for secure routing)
• Ensure port 5678 remains blocked from public access

Rate Limiting and DDoS Mitigation Strategies

Public webhook endpoints attract abuse. Attackers flood them with requests, consuming resources and potentially triggering downstream costs.

Implement rate limiting at your proxy or CDN level. Restricting traffic to 60 requests per minute per IP stops most flooding attacks. Ensure your hosting provider offers DDoS protection—enterprise hosts provide up to 12 Tbps of mitigation capacity.

Session Timeouts and Execution Data Retention

Hijacked sessions need limited windows to cause damage. Configure strict timeouts using N8N_USER_MANAGEMENT_JWT_DURATION_HOURS=2 (range: 1-8 hours).

Prevent sensitive data from lingering by setting EXECUTIONS_DATA_MAX_AGE=168 (7 days) and enabling data pruning. Your logs and execution history won’t become compliance audit nightmares.

Automatic Security Updates and Maintenance

Enable automatic security updates for your host operating system. Vulnerabilities get patched without manual intervention.

Install Fail2ban to protect SSH access. Configure it to ban IPs for 3600 seconds after 3 failed login attempts within 600 seconds. This stops brute force attacks cold.

Keep n8n, PostgreSQL, and Redis on an internal Docker network with no published ports. Network isolation limits your blast radius if something goes wrong.

Comparing IP Whitelisting Methods for n8n Protection

Direct Cloud IP Whitelisting vs. Reverse Proxies

Your infrastructure determines your best approach. Here’s how methods compare:

For detailed reverse proxy alternatives, see our guide on using reverse proxies for n8n.

Building Your Secure Infrastructure Foundation

Running n8n requires solid hosting infrastructure. Whether you’re deploying automation workflows or launching a web store alongside them, the right VPS provider makes everything easier.

Look for hosts offering full root access, Docker support, and robust network capabilities. DDoS protection, monitoring, and alerts should come standard. Your automation infrastructure deserves the same enterprise-grade foundation as your customer-facing applications.

Cheap VPS

best option

Compare Now

Conclusion

Protecting n8n with IP whitelisting creates essential barriers between your automation workflows and potential threats.

Whether you’re managing n8n cloud’s rotating IPs through static proxy services or configuring reverse proxy rules for self-hosted instances, the investment in proper security pays dividends.

Combine network-level restrictions with strong authentication, regular updates, and proper credential management. Your workflows will run reliably while your sensitive data stays protected.

Next Steps: What Now?

1. Audit your current setup and verify port 5678 isn’t exposed to the internet.
2. Configure a reverse proxy with IP allowlist rules for your editor UI.
3. Implement static IP proxy service if connecting to enterprise firewalls.
4. Enable automatic security updates and install Fail2ban on your server.
5. Set session timeout and execution data retention environment variables.
6. Consider VPN access for remote team members with dynamic IPs.