Networking & DNS

Builds Failing with DNS Errors (Could Not Resolve Host)

On some VPS providers, the default DNS servers configured on the host don't resolve properly inside Docker containers. This is commonly reported on Hetzner Cloud, whose default resolvers (185.12.64.1 and 185.12.64.2) can fail recursive resolution from within Docker build containers, but it can affect other providers with restricted or misbehaving resolvers as well.

Typical symptoms:

• Nixpacks builds: Could not resolve host: github.com
• Railpack builds: lookup ghcr.io on 185.12.64.1:53: server misbehaving
• Dockerfile builds: npm ci, apt-get, or similar commands hang and time out (e.g., Exit handler never called!)
• Domain validation in the UI: fails with queryA ENOTFOUND <domain> even though the domain resolves correctly from the host with nslookup

Since every build type fails the same way, the problem is the DNS configuration Docker inherits from the host, not your application.

Solution: Configure Docker to use public DNS resolvers by adding a dns entry to /etc/docker/daemon.json:

sudo mkdir -p /etc/docker
echo '{"dns": ["1.1.1.1", "8.8.8.8"]}' | sudo tee /etc/docker/daemon.json
sudo systemctl restart docker

You can verify DNS resolution works inside containers after the change:

docker run --rm alpine nslookup github.com

Deployments Failing with "All Predefined Address Pools Have Been Fully Subnetted"

If a deployment fails with this error:

Error response from daemon: all predefined address pools have been fully subnetted

it means Docker ran out of subnets for new networks. By default, Docker can only allocate around 31 local networks, and every Docker Compose project you deploy creates at least one network of its own. On a server with many projects, you eventually hit the limit — this is a Docker default, not a Nomploy bug.

You can confirm it by counting your networks:

docker network ls | wc -l

If the count is around 30 or more, you've exhausted the default address pools.

Quick Fix: Remove Unused Networks

docker network prune -f

This only removes networks that no container is using, so it's safe to run. It frees up space immediately, but you'll hit the limit again as you deploy more projects.

Permanent Fix: Expand Docker's Address Pools

Configure larger address pools in /etc/docker/daemon.json. First check whether the file already has content:

cat /etc/docker/daemon.json

For example, on a typical Nomploy server that already has the log configuration, the merged file looks like this:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "default-address-pools": [
    { "base": "172.17.0.0/12", "size": 24 },
    { "base": "10.100.0.0/16", "size": 24 }
  ]
}

With "size": 24, each new network gets a /24 subnet (254 IPs — plenty for a Compose project) instead of a whole /16, raising the limit from ~31 networks to several thousand.

Restart Docker:

sudo systemctl restart docker

A few things to keep in mind:

• Existing networks and containers are not affected — they keep their current subnets. The new pools only apply to networks created afterwards, and Docker automatically skips any subnet that is already in use.
• No redeployment of your projects is needed.
• Choose base ranges that don't overlap with your VPS's private network or any VPN you use (this is why the example avoids 192.168.0.0/16, which is commonly taken by LANs).

Verify the new pools are active:

docker info | grep -A 5 "Default Address Pools"

# root@srv594061:~# docker info | grep -A 5 "Default Address Pools"
#  Default Address Pools:
#    Base: 172.16.0.0/12, Size: 24
#    Base: 10.100.0.0/16, Size: 24

# root@srv594061:~#