DEV Community: Sanghun Yun

Best Cloud VPS for Self-Hosting Docker & Automation in 2026: DigitalOcean vs Hetzner vs AWS Lightsail

Sanghun Yun — Sat, 10 Oct 2026 06:47:52 +0000

In 2026, software engineers, devops teams, and bootstrapped technical founders are actively reclaiming ownership of their software stack. By self-hosting open-source platforms like n8n, Supabase, PostgreSQL, and Plausible Analytics, teams save thousands of dollars each month compared to traditional SaaS tools like Zapier and Airtable.

However, self-hosting is only as reliable as your cloud infrastructure. Choosing the wrong Virtual Private Server (VPS) results in throttled burst CPUs, unexpected data transfer surcharges, and sudden account suspensions during automated fraud checks.

In this benchmark guide, we compare the top three cloud VPS providers: DigitalOcean Droplets, Hetzner Cloud, and AWS Lightsail.

The Decision Matrix

flowchart TD
    Start["Self-Hosting Docker & Automation Workloads (2026)"] --> NeedCheck{"What is your primary decision criteria?"}

    NeedCheck -->|Simplicity, Reliable Support & Global Fast Edge| DOPriority["Need 1-Click Docker Marketplace,<br/>Zero Setup Friction & Global Datacenters?"]
    NeedCheck -->|Lowest Raw Hardware Cost in Europe| HetznerPriority["Experienced Linux Sysadmin &<br/>Strictly European Low Latency?"]
    NeedCheck -->|Existing AWS Cloud Footprint| AWSPriority["Existing Enterprise AWS Architecture<br/>(VPC Peering, IAM, RDS)?"]

    DOPriority --> DO["DigitalOcean Droplets (Top Recommendation)<br/>- $4 to $6/mo Entry Points<br/>- 1-Click Docker App Marketplace<br/>- $200 Free Developer Credit<br/>- Predictable Bandwidth & Global SLA"]

    HetznerPriority --> Hetzner["Hetzner Cloud<br/>- High raw CPU per dollar<br/>- Primarily European regions<br/>- Strict manual KYC approval<br/>- DIY networking & firewall management"]

    AWSPriority --> AWS["AWS Lightsail<br/>- Native integration with AWS APIs<br/>- Steeper pricing over time<br/>- Slower web management dashboard<br/>- Unexpected data egress surprises"]

2026 Cloud VPS Comparison Matrix

Feature / Metric	DigitalOcean Droplets	Hetzner Cloud	AWS Lightsail
Entry Price	$4.00 – $6.00 / mo	~€4.50 / mo (~$4.90)	$3.50 – $5.00 / mo
RAM & vCPU (Entry)	1 GB RAM / 1 vCPU	2 GB RAM / 1 vCPU	1 GB RAM / 1 vCPU
Storage Type	High-Speed NVMe SSD	NVMe SSD	Standard SSD
Included Bandwidth	1,000 GB (1 TB)	20 TB (Europe only)	1,000 GB (1 TB)
Global Datacenters	15+ (US, EU, Asia, India, Aus)	5 (Primarily Germany/Finland)	13 (Global AWS AZs)
1-Click Docker Setup	Yes (Official Marketplace)	No (Manual setup)	No (Basic OS only)
Account Activation	Instant (Zero KYC friction)	Strict (Manual ID/Passport review)	Complex (AWS IAM setup)
New Account Bonus	$200 for 60 Days	None	3 Months Free (Select tiers)

1. DigitalOcean Droplets (Score: 9.6/10) - Overall Winner

DigitalOcean remains the developer community's top choice because it eliminates operational friction:

1-Click Docker Marketplace Image: You can spin up a fully configured, security-hardened Docker and Docker Compose environment on Ubuntu in 50 seconds without manual package installation.
15+ Global Datacenter Regions: From New York and San Francisco to Frankfurt, Singapore, Bangalore, and Sydney, your webhooks and APIs enjoy ultra-low latency worldwide.
Transparent Pooled Bandwidth: Every Droplet includes 1,000 GB of outbound transfer, which pools across your entire account, preventing unexpected egress billing spikes.
Frictionless Onboarding: Instant account approval with credit card or PayPal, with zero invasive passport verification hurdles.

2. Hetzner Cloud (Score: 8.8/10) - The European Heavyweight

Hetzner is famous on Reddit (r/selfhosted) for offering incredible raw CPU performance per euro:

The Pros: 2 GB of RAM and 20 TB of bandwidth for ~€4.50/month in German and Finnish datacenters.
The Cons: An aggressive fraud detection algorithm frequently terminates accounts of non-EU developers or demands unredacted passport uploads. Furthermore, with virtually no presence in Asia or South America, international webhook latency can exceed 250ms.

3. AWS Lightsail (Score: 8.2/10) - The Enterprise Bridge

AWS Lightsail is Amazon's simplified VPS tier:

The Pros: Native, private VPC peering directly into AWS managed databases (RDS Aurora) and Amazon S3 buckets.
The Cons: A sluggish web console, complex snapshot rotation, burstable CPU credit throttles during continuous batch processing, and steep $0.09/GB egress fees if you exceed bundle limits.

Conclusion & Verdict

If your time is valuable and you want high-performance NVMe storage, 1-Click Docker convenience, and datacenters close to your global users, DigitalOcean Droplets are the clear winner for 2026.

Originally published on GearFlow Lab.

How to Migrate Local Docker & n8n from WSL2 to a $6 DigitalOcean Droplet

Sanghun Yun — Sat, 10 Oct 2026 06:46:45 +0000

Running mission-critical automation workflows (n8n, PostgreSQL, Redis, web scrapers) on Windows 11 via WSL2 inevitably hits two fatal operational bottlenecks:

vmmem RAM Ballooning: The Linux page cache greedily eats 8 to 16 GB of host RAM, starving your IDE and browser.
Offline Webhooks: Whenever your laptop sleeps, reboots for Windows Updates, or drops Wi-Fi, incoming Stripe, GitHub, or CRM webhooks fail with silent timeouts.

In this guide, we'll execute an atomic volume snapshot in WSL2, securely transfer it to a $6/month DigitalOcean Basic Droplet, and configure production Nginx with Let's Encrypt SSL for 24/7 always-on reliability.

Migration Architecture

Here is the migration pipeline from local WSL2 to a hardened cloud droplet:

flowchart TD
    subgraph LocalWSL["1. Local Development Environment (WSL2)"]
        WSL["Local Windows 11 PC<br/>- vmmem RAM exhaustion<br/>- Shuts down when PC sleeps"]
        DockerLocal["Local Docker Containers<br/>(n8n, Postgres, Redis)"]
        Dump["Volume Snapshot Export<br/>docker run --rm -v ... tar -czf"]
    end

    subgraph Transit["2. Secure Network Migration"]
        RSync["Encrypted SSH Sync<br/>rsync -avz -e ssh backup.tar.gz root@droplet:/srv/"]
    end

    subgraph DigitalOcean["3. DigitalOcean Cloud Droplet ($6/mo Standard)"]
        UFW["UFW Firewall Protection<br/>(Open 22, 80, 443 | Block raw app ports)"]
        DockerHost["Docker Engine + Compose<br/>(24/7 Dedicated Cloud Compute)"]

        subgraph Stack["Production Microservices Stack"]
            Nginx["Nginx Reverse Proxy<br/>(Let's Encrypt SSL Auto-Renewal)"]
            N8nProd["n8n Automation Engine<br/>(Webhooks Active 24/7)"]
            DBProd[("Restored Persistent Volumes<br/>(Fast NVMe SSD Storage)")]
        end
    end

    DockerLocal --> Dump
    Dump --> RSync
    RSync --> UFW
    UFW --> DockerHost
    DockerHost --> Nginx
    Nginx -->|HTTPS Reverse Proxy| N8nProd
    N8nProd --> DBProd

Step 1: Provision and Secure the Cloud Droplet

Spin up an Ubuntu 24.04 LTS Droplet on DigitalOcean (Basic $6/mo tier: 1 GB RAM / 1 vCPU / 25 GB NVMe SSD).
SSH into your droplet and configure the host firewall with UFW:

ssh root@<droplet_ip>

# Restrict inbound traffic strictly to SSH, HTTP, and HTTPS
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Note: Never expose port 5678 (n8n) or 5432 (Postgres) directly to the public internet.

Step 2: Atomic Volume Snapshot in WSL2

Stop your local stack cleanly to guarantee zero open file-lock corruption:

# Inside local WSL2 terminal
cd ~/my-n8n-project
docker compose stop

Create a point-in-time tarball snapshot of your persistent named volume using a disposable Alpine container:

docker run --rm \
  -v n8n_data:/data:ro \
  -v $(pwd):/backup \
  alpine tar -czf /backup/n8n_data_export.tar.gz -C /data .

Step 3: Transfer Volume & Configuration Over SSH

Push the archive, your docker-compose.yml, and your .env file directly to the Droplet:

# Run from local WSL2
scp -P 22 n8n_data_export.tar.gz root@<droplet_ip>:/srv/
scp -P 22 docker-compose.yml root@<droplet_ip>:/srv/
scp -P 22 .env root@<droplet_ip>:/srv/

Step 4: Restore Volume and Boot Production Stack

SSH into the cloud server:

ssh root@<droplet_ip>
cd /srv

# 1. Create target named volume
docker volume create n8n_data

# 2. Extract backup into cloud volume
docker run --rm \
  -v n8n_data:/data \
  -v /srv:/backup \
  alpine tar -xzf /backup/n8n_data_export.tar.gz -C /data

Production `docker-compose.yml`

version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n-automation
    restart: always
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - GENERIC_TIMEZONE=UTC
      - N8N_PAYLOAD_SIZE_MAX=64
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - internal-net

  nginx:
    image: nginx:alpine
    container_name: nginx-proxy
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./certbot/conf:/etc/letsencrypt:ro
      - ./certbot/www:/var/www/certbot:ro
    networks:
      - internal-net
    depends_on:
      - n8n

networks:
  internal-net:
    driver: bridge

volumes:
  n8n_data:
    external: true

Step 5: Issue SSL and Launch

Point your domain A record (n8n.yourdomain.com) to your Droplet IP.
Issue Let's Encrypt certificates:

   docker run -it --rm \
     -v /srv/certbot/conf:/etc/letsencrypt \
     -v /srv/certbot/www:/var/www/certbot \
     certbot/certbot certonly --webroot -w /var/www/certbot \
     -d n8n.yourdomain.com

Start the stack:

   docker compose up -d

Your workflows, API keys, database connections, and executions are now running 24/7 in the cloud without consuming a single megabyte of memory on your local machine.

Originally published on GearFlow Lab.

How to Secure the Docker Daemon Socket: Preventing Root Escalation & Container Escapes

Sanghun Yun — Sat, 10 Oct 2026 06:30:13 +0000

Mounting the Docker Unix socket (/var/run/docker.sock) into an application container is one of the most dangerous anti-patterns in modern DevOps.

While tools like Portainer, Traefik, Watchtower, and CI/CD agents often request socket access to discover services or build images, giving an application raw access to /var/run/docker.sock is equivalent to handing it passwordless root privileges on the host operating system.

In this guide, we examine the mechanics of the 1-line Docker socket breakout, and deploy three battle-tested defenses to eliminate privilege escalation risks.

The Threat & Multi-Layer Defense Architecture

flowchart TD
    subgraph DangerZone["Vulnerability: Exposed /var/run/docker.sock"]
        VulnContainer["Compromised Container / Web App"]
        RawSocket["Direct /var/run/docker.sock Mount<br/>(Root-Equivalent Daemon API)"]
        HostTakeover["Container Escape & Host Takeover<br/>docker run -v /:/host alpine chroot /host<br/>(Complete Root Compromise)"]
    end

    subgraph DefenseLayer["Multi-Layer Socket Defense Architecture"]
        subgraph Proxy["Defense 1: Docker Socket Proxy (Tecnativa)"]
            SocketProxy["HAProxy Security Gateway<br/>CONTAINERS=1, POST=0, EXEC=0"]
            SafeAgent["Monitoring Tools (Portainer, Traefik)<br/>(Restricted to Read-Only GET)"]
        end

        subgraph Rootless["Defense 2: Rootless Docker Engine"]
            RootlessDaemon["Rootless dockerd (User Namespaces)<br/>Daemon runs as UID 1000"]
            HostSafety["Host Kernel Security<br/>(Escapes drop to unprivileged user)"]
        end

        subgraph TLSAuth["Defense 3: Mutual TLS (mTLS)"]
            CertAuth["TCP 2376 with Client Certificate<br/>(Replaces raw unencrypted TCP 2375)"]
        end
    end

    VulnContainer -->|Direct mounting| RawSocket
    RawSocket -->|Arbitrary container creation| HostTakeover

    SafeAgent --> SocketProxy
    SocketProxy -->|Filtered Safe API Calls| RawSocket
    SocketProxy -.->|Blocks POST /containers/create & /exec| RawSocket

    RootlessDaemon --> HostSafety
    CertAuth --> RootlessDaemon

1. The Threat: The 1-Line Host Escape Exploit

The Docker daemon (dockerd) executes as host root (UID 0). The socket /var/run/docker.sock is the Unix IPC bridge to that daemon.

If a web application has a remote code execution (RCE) or Server-Side Request Forgery (SSRF) flaw and has /var/run/docker.sock mounted, an attacker does not need an unpatched Linux kernel vulnerability to take over the host.

They can issue a single command via the socket:

# Executed by an attacker inside the compromised container:
docker run --rm \
  -v /:/host \
  --net=host \
  --pid=host \
  --privileged \
  alpine chroot /host /bin/bash

Why Read-Only (`:ro`) Fails

Many teams believe mounting the socket with :ro protects them:

docker run -v /var/run/docker.sock:/var/run/docker.sock:ro my-app

This does not stop an attack. The :ro flag prevents modifying the Unix socket file inode on disk. It does not stop processes from writing HTTP POST requests into the socket stream to instruct the daemon to launch new containers.

2. Defense 1: Deploying Tecnativa Docker Socket Proxy

When dashboard and monitoring tools need Docker metrics, place Tecnativa's Docker Socket Proxy in front of the daemon. This hardened HAProxy image inspects API paths and enforces strict HTTP verb filtering:

version: '3.8'

services:
  socket-proxy:
    image: tecnativa/docker-socket-proxy:latest
    container_name: docker-socket-proxy
    restart: always
    environment:
      # Block all state-mutating verbs
      - POST=0
      - DELETE=0
      - EXEC=0
      - BUILD=0
      - VOLUMES=0
      # Allow strictly read-only inspection
      - CONTAINERS=1
      - SERVICES=1
      - NETWORKS=1
      - VERSION=1
      - INFO=1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - mgmt-net

  traefik:
    image: traefik:v3.0
    restart: always
    command:
      - "--providers.docker=true"
      - "--providers.docker.endpoint=tcp://socket-proxy:2375"
    depends_on:
      - socket-proxy
    networks:
      - mgmt-net
      - web-net

networks:
  mgmt-net:
    internal: true # No external egress
  web-net:
    driver: bridge

If an attacker tries to call POST /containers/create through this proxy, HAProxy immediately denies the request with an HTTP 403 Forbidden.

3. Defense 2: Migrating to Rootless Docker

Rootless Docker runs both dockerd and container runtimes entirely inside a user namespace (userns).

In standard Docker: Container root (UID 0) is host kernel UID 0.
In Rootless Docker: Container root (UID 0) maps to an unprivileged host user (UID 100000+).

Even if a malicious actor escapes a container, they land on the host as an unprivileged user without sudo or raw hardware privileges.

Quick Setup on Ubuntu:

# 1. Install prerequisites
sudo apt-get install -y uidmap dbus-user-session fuse-overlayfs

# 2. Disable system daemon
sudo systemctl disable --now docker.service docker.socket

# 3. Install rootless daemon for your user
dockerd-rootless-setuptool.sh install

# 4. Point Docker CLI to user socket
export DOCKER_HOST=unix:///run/user/$UID/docker.sock
echo 'export DOCKER_HOST=unix:///run/user/$UID/docker.sock' >> ~/.bashrc

4. Defense 3: Remote Socket Security with Mutual TLS (mTLS)

If you must manage Docker across the network, never bind raw TCP port 2375. Anyone with local network access can execute arbitrary commands.

Instead, configure Mutual TLS (mTLS) on port 2376:

In /etc/docker/daemon.json:

{
  "tls": true,
  "tlsverify": true,
  "tlscacert": "/etc/docker/ca.pem",
  "tlscert": "/etc/docker/server-cert.pem",
  "tlskey": "/etc/docker/server-key.pem",
  "hosts": ["fd://", "tcp://0.0.0.0:2376"]
}

Clients must present valid cryptographic certificates signed by your private CA to establish connections:

docker --tlsverify \
  --tlscacert=ca.pem \
  --tlscert=cert.pem \
  --tlskey=key.pem \
  -H=tcp://docker.example.com:2376 ps

Security Audit Summary

Protection Layer	Implementation	Threat Prevented
API Firewall	Tecnativa Socket Proxy (`POST=0`)	Host takeover via container mounts
Namespace Isolation	Rootless Docker (`dockerd-rootless`)	Root filesystem breakout
Encrypted Transit	Port 2376 with mTLS (Never 2375)	Unauthenticated remote execution
OS Auditing	`auditctl -w /var/run/docker.sock -p wa`	Silent unauthorized socket access

Originally published on GearFlow Lab.

How to Fix Nginx 502 Bad Gateway with Docker (Resolving Upstream Connection Refused)

Sanghun Yun — Sat, 10 Oct 2026 06:29:58 +0000

An HTTP 502 Bad Gateway error in an Nginx + Docker architecture is one of the most common—and frustrating—production roadblocks. Unlike a 504 Gateway Timeout where an upstream server is simply slow, a 502 Bad Gateway means Nginx is actively unable to complete the TCP handshake with your upstream container or received an invalid response header.

In this guide, we’ll break down the socket mechanics behind connect() failed (111: Connection refused), examine the three most common architectural misconfigurations, and implement bulletproof Docker DNS resolvers.

The System Architecture & Failure Flow

Here is how traffic flows through Nginx and Docker, and where the connection refused error is triggered:

flowchart TD
    subgraph Client["1. External Traffic Layer"]
        Browser["Web Client / API Request<br/>(HTTPS GET / POST)"]
    end

    subgraph NginxProxy["2. Nginx Reverse Proxy Container"]
        NginxListener["Nginx Listener (Port 80 / 443)"]
        NginxDNS["Nginx Dynamic Resolver<br/>(resolver 127.0.0.11 valid=10s)"]
        ProxyPass["proxy_pass $upstream_app<br/>(Prevents startup IP caching trap)"]
    end

    subgraph DockerNetwork["3. Shared Docker Bridge Network (app-tier)"]
        DockerDNS["Docker Embedded DNS<br/>(127.0.0.11:53)"]

        subgraph BackendApp["Backend Application Container"]
            PortListen["Bound to 0.0.0.0:3000<br/>(Container Interface)"]
            AppLogic["Node.js / Python / Go Server"]
        end

        subgraph StaleTrap["Failure Scenario: 502 Bad Gateway"]
            DeadSocket["connect() failed (111: Connection refused)<br/>- App bound to 127.0.0.1 only<br/>- Unshared Docker network<br/>- Stale IP after container recreate"]
        end
    end

    Browser -->|1. Incoming Request| NginxListener
    NginxListener --> ProxyPass
    ProxyPass -->|2. Resolve container hostname| NginxDNS
    NginxDNS -->|3. Query 127.0.0.11| DockerDNS
    DockerDNS -->|4. Return active container IP| NginxDNS
    ProxyPass -->|5. Clean TCP Stream| PortListen
    PortListen --> AppLogic
    ProxyPass -.->|Misconfiguration| DeadSocket

1. The Anatomy of POSIX Error 111 (Connection Refused)

When you inspect Nginx container logs:

docker logs <nginx_container> --tail 50

You will almost always find this exact signature:

2026/10/10 05:14:22 [error] 28#28: *104 connect() failed (111: Connection refused) 
while connecting to upstream, client: 198.51.100.45, server: api.gearflowlab.com, 
request: "POST /v1/auth/login HTTP/1.1", upstream: "http://172.22.0.4:8080/v1/auth/login", 
host: "api.gearflowlab.com"

In POSIX socket networking, 111 means the target host responded with an immediate TCP RST (Reset) flag. Nginx sent a SYN packet to establish a TCP session, but the operating system at 172.22.0.4 replied: "No process is listening on port 8080."

2. Root Cause 1: Binding to `127.0.0.1` Inside Containers

The #1 reason for a 502 Bad Gateway in Docker: your application server binds to localhost or 127.0.0.1.

In Docker, every container has an isolated network namespace and its own loopback interface (lo).

When your app listens on 127.0.0.1:3000, it is only accessible from inside that same container.
Nginx connects via the Docker bridge network interface (eth0, e.g., 172.22.0.4). Because your app is not listening on eth0, the kernel drops the packet with Connection refused.

The Solution: Bind to `0.0.0.0`

In Node.js / Express:

// Correct: Listen on all network interfaces
const PORT = process.env.PORT || 3000;
app.listen(PORT, '0.0.0.0', () => {
  console.log(`Server listening on 0.0.0.0:${PORT}`);
});

In Python FastAPI / Uvicorn:

uvicorn main:app --host 0.0.0.0 --port 8000

3. Root Cause 2: The Stale IP Dynamic DNS Caching Trap

This is the silent killer of container deployments.

When you define a static proxy_pass in Nginx:

location / {
    proxy_pass http://backend-api:3000;
}

Nginx queries DNS for backend-api once during boot or reload.

When you subsequently update your backend service (docker compose up -d --no-deps backend-api), Docker destroys the old container and creates a new container with a new IP address (e.g., 172.22.0.4 becomes 172.22.0.5).

Nginx continues sending packets to 172.22.0.4 until you reload Nginx. Every request fails with 502 Bad Gateway (Connection refused).

The Fix: Variable `proxy_pass` with Docker DNS

By using an Nginx variable inside proxy_pass and configuring Nginx's resolver to point to Docker's internal DNS daemon (127.0.0.11), Nginx dynamically re-resolves the IP every few seconds:

server {
    listen 80;
    server_name api.gearflowlab.com;

    # 127.0.0.11 is Docker's embedded DNS server
    resolver 127.0.0.11 valid=5s ipv6=off;
    resolver_timeout 3s;

    # Storing in a variable forces runtime DNS resolution
    set $backend_service "http://backend-api:3000";

    location / {
        proxy_pass $backend_service;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Retry on transient rollout hiccups
        proxy_next_upstream error timeout http_502;
        proxy_next_upstream_tries 3;
    }
}

4. Root Cause 3: Default Bridge vs. User-Defined Bridge Networks

Containers on Docker's default bridge network do not support automatic DNS resolution by container name.

Always ensure both services share a named, user-defined bridge network in docker-compose.yml:

version: '3.8'

services:
  reverse-proxy:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    networks:
      - internal-net
    depends_on:
      backend-api:
        condition: service_healthy

  backend-api:
    image: my-node-api:latest
    environment:
      - HOST=0.0.0.0
      - PORT=3000
    networks:
      - internal-net
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://127.0.0.1:3000/health || exit 1"]
      interval: 5s
      timeout: 3s
      retries: 3
      start_period: 10s

networks:
  internal-net:
    driver: bridge

Notice the condition: service_healthy directive: Nginx will not accept traffic until the backend passes its internal healthcheck, eliminating startup race condition 502s.

Diagnostic Cheat Sheet

Run these commands inside your environment to pinpoint the root cause in 30 seconds:

# 1. Test DNS resolution from Nginx container
docker exec -it reverse-proxy getent hosts backend-api

# 2. Test HTTP response directly from Nginx container
docker exec -it reverse-proxy wget -qO- http://backend-api:3000/health

# 3. Check what port the app is listening on inside its container
docker exec -it backend-api netstat -tulpn | grep LISTEN

Originally published on GearFlow Lab.

Fix n8n Webhook 413 Payload Too Large on Docker & Nginx (The 3-Layer Solution)

Sanghun Yun — Sat, 10 Oct 2026 03:57:33 +0000

You’re self-hosting n8n on Docker behind an Nginx reverse proxy. Your workflows run flawlessly with small test payloads and test webhooks.

Then, a real production request hits: a Stripe webhook carrying a heavy metadata object, an external form pushing a 25MB PDF attachment, or a web scraper dispatching a large JSON dataset.

Suddenly, the sender receives:

HTTP/1.1 413 Request Entity Too Large

or inside your Docker logs:

PayloadTooLargeError: request entity too large

[Image Guide / Prompt]:

Screenshot Capture: Screenshot of Postman, Insomnia, or a dark terminal sending a POST request with a ~20MB file returning 413 Request Entity Too Large and an HTML body containing <center>nginx</center>.

AI Generation Prompt: "A realistic screenshot of a dark-mode developer API client (Postman or Insomnia) showing a failed POST request to an n8n webhook endpoint with an HTTP 413 Payload Too Large error status badge in red, raw response body showing HTML header, ultra-clean software engineer UI, 4k."

The most infuriating part? The workflow execution log in n8n is completely blank. The request was dropped before the Webhook node ever received it.

Most quick forum posts say "just add client_max_body_size 64M; to Nginx." But if you only do that, you'll still hit a wall. In real-world self-hosting, there are three distinct layers that enforce payload limits, plus a hidden Node.js V8 memory heap trap.

Here is the complete engineering walkthrough to identify which layer is rejecting your request and the configuration required to fix all of them permanently.

The Webhook Chain: Three Layers, Three Limits

A webhook request passes through a multi-tiered pipeline before reaching your n8n canvas:

flowchart LR
    Client["Webhook Sender<br/>(Stripe, Web Scraper, Form)"]
    CF["Cloudflare Proxy<br/>(100MB Cap on Free/Pro)"]
    Nginx["Nginx Reverse Proxy<br/>(client_max_body_size: 1MB Default)"]
    n8n["n8n Express Server<br/>(N8N_PAYLOAD_SIZE_MAX: 16MiB Default)"]
    V8["Node.js V8 Heap<br/>(max-old-space-size)"]
    Node["Webhook Node Execution<br/>(n8n Canvas Workflow)"]

    Client --> CF
    CF -- "< 100MB" --> Nginx
    Nginx -- "< 64MB" --> n8n
    n8n --> V8
    V8 --> Node

Each layer enforces its own payload cap, and the smallest limit always wins:

Layer	Directive / Setting	Default Limit	Error Signature
Nginx	`client_max_body_size`	1 MB	HTML page: `<title>413 Request Entity Too Large</title>...<center>nginx</center>`
n8n (JSON / Body)	`N8N_PAYLOAD_SIZE_MAX`	16 MiB	`PayloadTooLargeError: request entity too large` in Docker logs
n8n (Multipart File)	`N8N_FORMDATA_FILE_SIZE_MAX`	200 MiB	Upload rejected by busboy parser in container logs
Cloudflare	Plan-based upload limit	100 MB (Free/Pro)	Cloudflare branded error page, `Server: cloudflare` header

Step 1: Isolate Which Layer is Rejecting the Payload

Before editing configs, determine exactly where the payload is dropped:

Send a 20 MB test payload through your public URL (full chain):

python3 -c "import json; print(json.dumps({'data': 'x' * 20_000_000}))" > payload.json

curl -s -i -X POST "https://n8n.yourdomain.com/webhook-test/your-path" \
  -H "Content-Type: application/json" \
  --data-binary @payload.json | head -n 20

Send the identical payload directly to n8n from the host machine (bypassing Nginx):

curl -s -i -X POST "http://127.0.0.1:5678/webhook-test/your-path" \
  -H "Content-Type: application/json" \
  --data-binary @payload.json | head -n 20

How to diagnose the response:

Public URL returns 413 with <center>nginx</center>, but local 127.0.0.1 succeeds: Nginx is the culprit. Proceed to Step 2.
Direct curl to 127.0.0.1 returns 413 or logs PayloadTooLargeError: n8n itself rejected it. Proceed to Step 3.
Public URL returns Server: cloudflare: Cloudflare's edge proxy rejected it before reaching your origin.

Step 2: Raise Nginx Limits & Adjust Timeouts

In /etc/nginx/sites-available/n8n (or /etc/nginx/conf.d/n8n.conf), scope the body size to your webhook endpoints so your administrative editor UI remains strictly protected:

[Image Guide / Prompt]:

Screenshot Capture: Screenshot of VS Code or Neovim with Nginx syntax highlighting on a Linux server, showing the location ~ ^/(webhook|webhook-test)/ block with client_max_body_size 64m; highlighted in line numbers.

AI Generation Prompt: "High-resolution screenshot of a code editor with a dark modern theme (One Dark / Dracula) displaying an nginx configuration file, highlighting client_max_body_size 64m; and proxy_read_timeout 300s; within a location block, syntax-highlighted Nginx directives."

server {
    listen 443 ssl http2;
    server_name n8n.yourdomain.com;

    # General protection for the editor UI & API
    client_max_body_size 4m;

    # Dedicated block for incoming Webhook payloads
    location ~ ^/(webhook|webhook-test)/ {
        client_max_body_size 64m;

        # Prevent 504 Gateway Timeouts while uploading large payloads
        client_body_timeout 120s;
        proxy_read_timeout  300s;
        proxy_send_timeout  300s;

        proxy_pass http://127.0.0.1:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;

        # Disable buffering so large uploads stream directly to n8n
        proxy_request_buffering off;
        proxy_buffering off;
    }

    # Main editor & websocket block
    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Verify the syntax and reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

Step 3: Tune n8n Environment Variables & Node.js V8 Heap

n8n parses JSON bodies using its internal Express body-parser middleware. By default, N8N_PAYLOAD_SIZE_MAX is capped at 16 MiB.

Furthermore, if you accept a 50 MB JSON payload, Node.js will parse that entire object tree into the V8 memory heap. By default, Node.js inside the official Alpine container runs with limited heap memory (~1.4 GB) and will crash with JavaScript heap out of memory.

[Image Guide / Prompt]:

Screenshot Capture: A split-screen terminal showing docker-compose.yml on the left and docker exec n8n printenv | grep N8N on the right confirming the 64M payload limit and 4096MB heap allocation.

AI Generation Prompt: "A developer workstation split-screen terminal in dark mode, showing a clean docker-compose.yml configuration with environment variables N8N_PAYLOAD_SIZE_MAX=64 and NODE_OPTIONS=--max-old-space-size=4096, modern terminal font (JetBrains Mono), clean contrast."

Update your docker-compose.yml:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      # 1. Raise n8n JSON / raw body limit (in MiB)
      - N8N_PAYLOAD_SIZE_MAX=64

      # 2. Raise multipart/form-data binary upload limit (in MiB)
      - N8N_FORMDATA_FILE_SIZE_MAX=250

      # 3. CRITICAL: Store binary files on disk instead of holding them in RAM
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

      # 4. Prevent Node.js V8 Heap OOM crashes on large JSON parsing (allocate 4GB heap)
      - NODE_OPTIONS=--max-old-space-size=4096

      # Generic timezone settings
      - GENERIC_TIMEZONE=UTC
      - TZ=UTC
    volumes:
      - n8n_data:/home/node/.n8n
      # If using binary data mode filesystem, ensure local mount persists:
      - ./n8n-local-files:/files

volumes:
  n8n_data:

Warning: Running docker restart n8n does NOT apply new environment variables. You must recreate the container:

docker compose up -d --force-recreate

Confirm that the variables are active inside the container:

docker exec n8n printenv | grep -E "N8N_PAYLOAD_SIZE_MAX|NODE_OPTIONS"

Step 4: Verification & End-to-End Test

Re-run your 20MB payload test through your public domain:

curl -s -o /dev/null -w "HTTP %{http_code} | sent %{size_upload} bytes | %{time_total}s\n" \
  -X POST "https://n8n.yourdomain.com/webhook/your-path" \
  -H "Content-Type: application/json" \
  --data-binary @payload.json

[Image Guide / Prompt]:

Screenshot Capture: Screenshot of the n8n Workflow canvas with the Webhook node glowing green with a checkmark ("Executed successfully"), showing an input payload of 20MB and a status badge of 200 OK.

AI Generation Prompt: "UI screenshot of n8n automation canvas in dark mode, showing a Webhook node connected to a Code node, green success badges, node output inspector open showing a clean 200 OK response with a large JSON data payload."

Expected output:

HTTP 200 | sent 20000013 bytes | 1.84s

Check your n8n workflow execution history: the execution now appears immediately, and the node outputs the full payload without dropping or choking the container.

Production Architecture Best Practices

Keep Nginx limit ≥ n8n limit: If n8n allows 64 MiB but Nginx allows 32 MB, Nginx will drop the connection before n8n ever sees it.
Never inline massive binaries as base64 in JSON: Base64 inflates payload size by ~33% and forces the V8 engine to allocate massive contiguous memory chunks. Always use multipart/form-data with N8N_DEFAULT_BINARY_DATA_MODE=filesystem.
If behind Cloudflare: Cloudflare Free and Pro plans hard-cap uploads at 100 MB. If you need payloads >100 MB, route webhooks through a DNS-only (grey-cloud) subdomain or have the client upload directly to S3/Cloudflare R2 and pass a pre-signed URL to n8n instead.

Originally published at GearFlow Lab.

How to Fix WSL2 and Docker (vmmem) Eating 90% of Your RAM on Windows 11

Sanghun Yun — Sat, 10 Oct 2026 03:51:52 +0000

You’re running Windows 11 as your daily driver for software engineering. You launch Docker Desktop, spin up your local dev containers (Postgres, Redis, an API server), and start writing code. Everything feels snappy.

A few hours into your workday, your entire system starts stuttering. Browser tabs crash or constantly reload, typing inside VS Code starts lagging, and your laptop fans sound like a jet engine preparing for takeoff.

You open Windows Task Manager (Ctrl + Shift + Esc), sort by Memory, and discover this:

Process Name           PID       Status       CPU       Memory (Private Working Set)
vmmemWSL (or vmmem)    4128      Running      1.5%      24,180.4 MB (88%)
Docker Desktop         11452     Running      0.1%         412.0 MB
Windows Explorer       2840      Running      0.0%         185.3 MB

[Image Guide / Prompt]:

Screenshot Capture: Capture the Windows 11 Task Manager Processes tab sorted by Memory descending, showing vmmemWSL consuming over 24 GB of RAM (80–90% total system memory), with high system memory gauge in red.

AI Generation Prompt: "High-resolution desktop UI screenshot of Windows 11 Task Manager in dark mode, showing the 'Processes' tab sorted by Memory, with 'vmmemWSL' highlighted consuming 24.2 GB of RAM, memory utilization bar graph showing 91% total usage, clean authentic Windows 11 design language."

Even after you run docker stop $(docker ps -q), terminate all active terminal sessions, and close VS Code, vmmemWSL continues holding 20+ GB of RAM hostage. Windows 11 never reclaims it.

Here is why this happens, how WSL2's memory model actually works, and the step-by-step configuration to permanently tame vmmem.

Root Cause: Why Doesn't Linux Give Memory Back to Windows?

To understand this problem, you need to know how WSL2 works under the hood.

WSL2 is not a container engine or an emulation layer; it runs a real Linux kernel inside a lightweight Hyper-V utility virtual machine.

Unlike traditional virtualization platforms where you assign a static block of RAM (e.g., exactly 8 GB), Hyper-V uses Dynamic Memory Allocation:

flowchart TD
    subgraph Host["Windows 11 Host OS (e.g. 32 GB RAM)"]
        subgraph HyperV["Hyper-V Dynamic Memory Manager"]
            VM["vmmemWSL Virtual Machine Allocation<br/>(Expands up to 50% - 80% Total RAM by default)"]
            subgraph WSL2["WSL2 Linux Kernel Guest"]
                AppMem["Active App / Container RAM<br/>(e.g. 2 - 4 GB)"]
                PageCache["Linux Page Cache & Buffers<br/>(Files cached during docker build, npm, git)<br/>(Inflates to 18+ GB)"]
            end
        end
        WinApps["Windows Host Processes<br/>(Chrome, VS Code, OS Services)<br/>(Starved when vmmem expands)"]
    end

    PageCache -- "1. Reads files, inflates memory" --> PageCache
    WSL2 -- "2. Requests memory expansion" --> VM
    VM -- "3. Hyper-V allocates host RAM" --> Host
    Host -. "4. Linux DOES NOT return idle cache<br/>to host without .wslconfig caps" .-> WinApps

1. The Page Cache Trap

The Linux kernel operates on a fundamental principle: "Free RAM is wasted RAM."

When you build a Docker image (docker build), run package managers (npm install, pip install), or perform Git operations on large repositories, Linux reads and writes thousands of files. Linux automatically keeps every single file it reads cached in memory (in buffers, dentries, and inodes) so subsequent access is instantaneous.

2. Hyper-V Ballooning

Hyper-V detects the Linux kernel asking for more memory to satisfy these caches and dutifully expands the host RAM assigned to vmmemWSL.

3. The Lack of Automatic Deflation

When your build or container workload finishes, Linux marks that cached RAM as "available for other Linux processes," but it does not surrender it back to the Hyper-V host. To Windows 11, that memory is still actively locked by the Hyper-V VM.

4. Overly Generous Defaults

By default, WSL2 on Windows 11 is allowed to claim up to 50% of your total host RAM (capped at 32 GB), and up to 80% on earlier Windows builds. On a 32 GB machine, WSL2 will happily balloon to 16-24 GB and never let go.

Step 1: Hard-Cap WSL2 in `%UserProfile%\.wslconfig`

The permanent solution is to define hard resource boundaries using a global .wslconfig file in your Windows user profile directory.

Press Win + R, type notepad %UserProfile%\.wslconfig, and press Enter. (If prompted to create the file, click Yes).
Paste the following configuration:

[Image Guide / Prompt]:

Screenshot Capture: Screenshot of VS Code or Notepad editing .wslconfig, highlighting memory=8GB, processors=4, and autoMemoryReclaim=gradual with line numbers visible.

AI Generation Prompt: "A modern dark-themed code editor window (VS Code) displaying a .wslconfig configuration file, showing clean INI syntax highlighting with sections [wsl2] and [experimental], highlighting memory=8GB and autoMemoryReclaim=gradual in golden accents, professional developer workstation capture."

# Settings apply globally to all WSL2 distributions & Docker Desktop backend
[wsl2]
# Hard limit memory allocated to the WSL2 virtual machine
memory=8GB

# Limits virtual CPU cores allocated to WSL2 (leaves headroom for Windows)
processors=4

# Sets the swap virtual disk size (prevents Linux OOM crashes during build spikes)
swap=4GB

# Windows 11 23H2+ Memory Reclaim feature:
# Automatically releases cached page cache memory back to Windows
autoMemoryReclaim=gradual

# Enable clean localhost forwarding from containers to Windows
localhostForwarding=true

[experimental]
# Automatically drops Linux page caches when memory pressure drops
autoMemoryReclaim=dropcache
# Enables automatic sparse disk compaction for virtual hard drives
sparseVhd=true

Sizing Rule of Thumb for Your Hardware:

Host Physical RAM	Recommended `.wslconfig` `memory` Cap	Recommended `swap`
16 GB	`4GB` or `6GB`	`2GB`
32 GB	`8GB` or `12GB`	`4GB`
64 GB+	`16GB` or `24GB`	`8GB`

Step 2: Restart WSL2 to Apply the Changes

WSL2 only evaluates .wslconfig during initial VM boot. Restarting Docker Desktop alone will not reload .wslconfig.

Open PowerShell (Administrator).
Force-shutdown all running WSL2 instances and Hyper-V utility VMs:

wsl --shutdown

Look at Task Manager: vmmemWSL will vanish immediately.
Launch your WSL2 terminal or Docker Desktop. Hyper-V will now boot strictly constrained to your configured memory ceiling.

Verify the active ceiling from inside your Linux terminal:

free -h

[Image Guide / Prompt]:

Screenshot Capture: Terminal screenshot of free -h running in an Ubuntu WSL2 shell showing total: 7.8Gi, used: 1.2Gi, free: 5.8Gi, and Swap: 4.0Gi, displaying memory usage under full control.

AI Generation Prompt: "Terminal window in dark mode displaying the output of free -h command in Linux, showing 7.8Gi total memory with 5.8Gi available and 4.0Gi swap space, clean monospace font, green terminal prompt, high contrast."

Output will now show your configured cap:

               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       1.2Gi       5.8Gi       4.0Mi       840Mi       6.4Gi
Swap:          4.0Gi          0B       4.0Gi

Step 3: Flush Cached RAM on Demand (Without Rebooting)

If you are running back-to-back heavy builds and want to reclaim cached memory immediately without restarting your containers, you can manually trigger a kernel cache flush.

Run this inside your WSL2 terminal:

sudo sh -c "sync; echo 3 > /proc/sys/vm/drop_caches"

To make this seamless, add a quick alias to your shell configuration (~/.bashrc or ~/.zshrc):

echo 'alias dropmem="sudo sh -c \"sync; echo 3 > /proc/sys/vm/drop_caches\" && free -h"' >> ~/.bashrc
source ~/.bashrc

Whenever RAM usage climbs, simply run dropmem in any terminal to release gigabytes of cache back to your system in under 500ms.

Step 4: Reclaim Docker BuildKit Cache & Disk Space

A huge hidden contributor to WSL2 memory and NVMe disk bloat is Docker's BuildKit layer cache. Over weeks of development, BuildKit accumulates tens of gigabytes of cached layers inside WSL2's virtual disk (ext4.vhdx).

[Image Guide / Prompt]:

Screenshot Capture: Terminal output running docker builder prune -a -f showing deleted build cache IDs followed by Total reclaimed space: 14.82GB.

AI Generation Prompt: "A sleek dark-mode terminal showing Docker CLI output for docker builder prune -a -f, listing multiple purged layer hashes and concluding with Total reclaimed space: 14.8GB highlighted in bold green."

1. Prune BuildKit Cache

docker builder prune -a -f

2. Prune Dead Containers, Networks, and Dangling Images

docker system prune -a --volumes -f

3. Compact the Expanding Virtual Disk (`ext4.vhdx`)

Even after deleting 30 GB of Docker images, the .vhdx file on your Windows drive does not shrink automatically. Run diskpart in PowerShell to shrink it:

wsl --shutdown
diskpart

Inside the diskpart prompt:

select vdisk file="C:\Users\<YourUsername>\AppData\Local\Packages\CanonicalGroupLimited...\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

(For Docker Desktop data distro, target %LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx)

Summary Checklist

[x] Configure %UserProfile%\.wslconfig with an explicit memory and swap cap.
[x] Enable autoMemoryReclaim=gradual to return idle page cache to Windows automatically.
[x] Run wsl --shutdown from PowerShell to apply settings.
[x] Use dropmem alias for instant manual cache purging.
[x] Regularly prune Docker's build cache using docker builder prune -a.

Originally published at GearFlow Lab.

DEV Community: Sanghun Yun

Best Cloud VPS for Self-Hosting Docker & Automation in 2026: DigitalOcean vs Hetzner vs AWS Lightsail

The Decision Matrix

2026 Cloud VPS Comparison Matrix

1. DigitalOcean Droplets (Score: 9.6/10) - Overall Winner

2. Hetzner Cloud (Score: 8.8/10) - The European Heavyweight

3. AWS Lightsail (Score: 8.2/10) - The Enterprise Bridge

Conclusion & Verdict

How to Migrate Local Docker & n8n from WSL2 to a $6 DigitalOcean Droplet

Migration Architecture

Step 1: Provision and Secure the Cloud Droplet

Step 2: Atomic Volume Snapshot in WSL2

Step 3: Transfer Volume & Configuration Over SSH

Step 4: Restore Volume and Boot Production Stack

Production docker-compose.yml

Step 5: Issue SSL and Launch

How to Secure the Docker Daemon Socket: Preventing Root Escalation & Container Escapes

The Threat & Multi-Layer Defense Architecture

1. The Threat: The 1-Line Host Escape Exploit

Why Read-Only (:ro) Fails

2. Defense 1: Deploying Tecnativa Docker Socket Proxy

3. Defense 2: Migrating to Rootless Docker

Quick Setup on Ubuntu:

4. Defense 3: Remote Socket Security with Mutual TLS (mTLS)

Security Audit Summary

How to Fix Nginx 502 Bad Gateway with Docker (Resolving Upstream Connection Refused)

The System Architecture & Failure Flow

1. The Anatomy of POSIX Error 111 (Connection Refused)

2. Root Cause 1: Binding to 127.0.0.1 Inside Containers

The Solution: Bind to 0.0.0.0

3. Root Cause 2: The Stale IP Dynamic DNS Caching Trap

The Fix: Variable proxy_pass with Docker DNS

4. Root Cause 3: Default Bridge vs. User-Defined Bridge Networks

Diagnostic Cheat Sheet

Fix n8n Webhook 413 Payload Too Large on Docker & Nginx (The 3-Layer Solution)

The Webhook Chain: Three Layers, Three Limits

Step 1: Isolate Which Layer is Rejecting the Payload

How to diagnose the response:

Step 2: Raise Nginx Limits & Adjust Timeouts

Step 3: Tune n8n Environment Variables & Node.js V8 Heap

Step 4: Verification & End-to-End Test

Production Architecture Best Practices

How to Fix WSL2 and Docker (vmmem) Eating 90% of Your RAM on Windows 11

Root Cause: Why Doesn't Linux Give Memory Back to Windows?

1. The Page Cache Trap

2. Hyper-V Ballooning

3. The Lack of Automatic Deflation

4. Overly Generous Defaults

Step 1: Hard-Cap WSL2 in %UserProfile%\.wslconfig

Sizing Rule of Thumb for Your Hardware:

Step 2: Restart WSL2 to Apply the Changes

Step 3: Flush Cached RAM on Demand (Without Rebooting)

Step 4: Reclaim Docker BuildKit Cache & Disk Space

1. Prune BuildKit Cache

2. Prune Dead Containers, Networks, and Dangling Images

3. Compact the Expanding Virtual Disk (ext4.vhdx)

Summary Checklist

Production `docker-compose.yml`

Why Read-Only (`:ro`) Fails

2. Root Cause 1: Binding to `127.0.0.1` Inside Containers

The Solution: Bind to `0.0.0.0`

The Fix: Variable `proxy_pass` with Docker DNS

Step 1: Hard-Cap WSL2 in `%UserProfile%\.wslconfig`

3. Compact the Expanding Virtual Disk (`ext4.vhdx`)