Docker

Run your services in Docker Compose? Add our container to your project and your services become reachable from the internet on your dedicated public IPv4 address, without changing those services at all. You do not add ports: entries, you do not need a routable address from your ISP, and there is nothing to open on your router or your host firewall: inbound traffic arrives over the tunnel rather than through a published port.

Before you start

• A GetPublicIP IP address and its API key. See Create an API Key
• Linux: Docker Engine and Compose v2, meaning docker compose rather than the older docker-compose script
• macOS: Docker Desktop, on either Intel or Apple Silicon
• Windows: Docker Desktop in Linux containers mode, on a WSL2 6.6 kernel. Check with wsl --version, and run wsl --update if it reports anything older, because kernels before 6.6 are missing a netfilter module the tunnel needs

Everything on this page works unchanged on Windows and macOS with Docker Desktop, with nothing to install beyond Docker Desktop itself. It is free for personal use, education, non-commercial open source, and small businesses with fewer than 250 employees and under $10M in annual revenue; larger organisations need a paid subscription from Docker. See macOS and Windows for the detail on each.

The image is published for linux/amd64 and linux/arm64 at ghcr.io/getpublicip/getpublicip.

Put your API key in a .env file

Create a .env file next to your compose file. See Create an API Key for more information.

CopyGETPUBLICIP_API_KEY=your-api-key-from-the-dashboard

Compose reads the .env file automatically, which is why the compose files below refer to ${GETPUBLICIP_API_KEY} rather than containing the key itself. Add .env to your .gitignore.

Add to your Docker compose file

Add this service alongside the containers you already run:

Copyservices:
  getpublicip:
    image: ghcr.io/getpublicip/getpublicip:latest
    restart: unless-stopped
    environment:
      GETPUBLICIP_API_KEY: "${GETPUBLICIP_API_KEY}"
      GETPUBLICIP_MAPPINGS: "8080/tcp->web:80; 443/tcp->web:443"
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      net.ipv4.ip_forward: 1
      net.ipv4.conf.all.src_valid_mark: 1
      net.ipv6.conf.all.forwarding: 1
    networks:
      - appnet

Replace appnet with the network your own services are already on, and web with your own service names. Everything else can stay as it is.

Keep restart: unless-stopped. It is how the agent recovers from the faults it cannot fix in place, as described in Connection drops.

A complete working example

Nothing to add it to yet? This is a whole setup in one file: a web server on your own public IP address, reachable from anywhere. Save it as compose.yaml:

Copyservices:
  web:
    image: nginx:alpine
    restart: unless-stopped
    networks:
      - appnet

  getpublicip:
    image: ghcr.io/getpublicip/getpublicip:latest
    restart: unless-stopped
    environment:
      GETPUBLICIP_API_KEY: "${GETPUBLICIP_API_KEY}"
      GETPUBLICIP_MAPPINGS: "80/tcp->web:80"
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      net.ipv4.ip_forward: 1
      net.ipv4.conf.all.src_valid_mark: 1
      net.ipv6.conf.all.forwarding: 1
    networks:
      - appnet

networks:
  appnet:

Then start it:

Copydocker compose up -d

Give it about 30 to 60 seconds and open http://{YOUR IP ADDRESS} from any network, or from your phone on mobile data. The nginx welcome page means a request from the internet reached your container.

Two things are worth noticing about this compose project. web has no ports: entry, the nginx server is reached over the internal appnet network. Both services join appnet, because the agent resolves web by service name and can only do that on a network the two of them share. Compose would put both on the project's default network if you left the networks: blocks out entirely, and that works just as well, but naming the network makes the requirement visible.

Map your ports

GETPUBLICIP_MAPPINGS decides which ports on your public IP go to which of your containers. Separate entries with ; or newlines:

CopypublicPort[/proto[,proto]][/stack[,stack]]->service[:internalPort]

The segments after the port are matched by keyword, so their order does not matter. 8080/tcp/ipv4 and 8080/ipv4/tcp mean the same thing.

Note that you refer to your containers by service name, never by IP address. Compose assigns container IPs dynamically, so the agent resolves those names itself and re-checks them every 30 seconds. When a container restarts on a different IP, the forwarding rules are updated automatically.

A destination can also be any hostname that resolves, or a literal IPv4 address, and all three behave identically. A literal IPv6 address is not accepted; use a hostname with an AAAA record instead.

Port ranges

Some services need a whole block of ports rather than one: a TURN server for voice and video calls, FTP in passive mode, or anything carrying RTP media. Write the public port as a range and every port in it is forwarded to the same port on your container:

CopyGETPUBLICIP_MAPPINGS: "3478/tcp,udp->turn; 60000-60099/udp->turn"

Port 60042 on your public IP always arrives at port 60042 on turn. That matters for services like these, because they tell the other side which port to use, and a port that changed on the way in would quietly break the connection.

For the same reason, a range can only go to the same range. You can leave the internal port out, as above, or repeat the range exactly (60000-60099/udp->turn:60000-60099). Sending it to different ports, such as ->turn:61000-61099, is refused when the container starts, with a port range must forward to the same range. A range also cannot include port 51820, which the tunnel itself uses.

Open only as many ports as your service is set up to use. For a TURN server that means the relay range it is configured to allocate from, not everything above 49152. This needs image 1.3.1 or later.

Forwarding IPv6

Mappings are IPv4 unless you say otherwise, so add the ipv6 stack to forward your public IPv6 address, or ipv4,ipv6 to forward both. Two things have to line up for it to work.

Your compose network needs IPv6 enabled. Docker bridge networks are IPv4-only by default, so a container on one has no IPv6 address for the agent to forward to. Give the network enable_ipv6: true and an IPv6 subnet:

Copynetworks:
  appnet:
    enable_ipv6: true
    ipam:
      config:
        - subnet: 172.29.7.0/24
        - subnet: fd00:dead:beef::/64

The stack applies to the destination as well as the public port. The forwarding rules cannot translate between the two families, so an IPv6 request has to reach your container over IPv6. 8080/tcp/ipv4,ipv6->web:80 therefore needs web to hold both an IPv4 and an IPv6 address, which the network above gives it.

Keep net.ipv6.conf.all.forwarding: 1 in the agent's sysctls block. It is in the examples on this page already, and it is only needed when you forward IPv6.

If something is missing the agent tells you which destination and which family failed, with no destination resolved in the family its mapping asked for. An otherwise healthy setup that produces that line for an ipv6 mapping is almost always a network without enable_ipv6.

SSL / TLS

GetPublicIP works at the packet level. It forwards TCP and UDP to your containers and leaves everything else to you. You will need to manage encryption and SSL certificates. So if you serve HTTPS, your own service terminates the TLS connection. Map 443 to the container that already holds your certificate, and nothing about your TLS setup changes:

CopyGETPUBLICIP_MAPPINGS: "443/tcp->web:443; 80/tcp->web:80"

We do not decrypt your traffic

Your public IP is not a TLS proxy. It holds none of your certificates or private keys, so it has nothing to decrypt with. The TLS session is negotiated directly between your visitor's browser and your own service, and it stays encrypted the whole way: out of the browser, across the internet to your public IP, through the WireGuard tunnel, and into your container, where it is decrypted for the first time.

The tunnel adds a second layer of encryption between our network and your machine, but it is the outer layer. What travels inside it is the same TLS ciphertext your visitor sent. Your certificates and private keys never leave your machine, there is nothing to upload to us, and your traffic is never decrypted and re-encrypted on the way through. We do not decrypt TLS traffic, and we have no plans to.

Your service needs a valid certificate

Because the certificate lives on whichever service terminates the connection, that service needs a valid certificate, exactly as it would on any other public host.

• Point a domain at your public IP. Add an A record for your IPv4 address, and an AAAA record if you serve IPv6 as well. Certificate authorities issue for domain names, so a bare IP address is not enough.
• Get the certificate from Let's Encrypt. It is free, automated, and well suited to this. Caddy and Traefik request and renew for you with no more configuration than your domain name; nginx and Apache pair with certbot.
• If you use an HTTP-01 challenge, map port 80 as well as 443 to the same service. Let's Encrypt connects to port 80 on your public IP to answer the challenge, and it fails if only 443 is mapped. A DNS-01 challenge does not need port 80.
• Leave those ports mapped. Renewal repeats the same challenge every 60 days or so, and it fails quietly if the mapping has gone.

Plain HTTP is still plain

A mapping to port 80 serving unencrypted HTTP is unencrypted between your visitor and your public IP, exactly as it would be anywhere else on the internet. The WireGuard tunnel covers only the hop between our network and your machine. If the content matters, enable TLS.

Forwarding to a service on the host

Already running something on the box and just want it public? Point a mapping at host.docker.internal, the address you would reach for anyway:

Copyservices:
  getpublicip:
    environment:
      GETPUBLICIP_MAPPINGS: "8081/tcp->host.docker.internal:8081"
    extra_hosts:
      - "host.docker.internal:host-gateway"   # needed on Linux; built in on Docker Desktop

• The host service must listen on 0.0.0.0, not 127.0.0.1. A service bound to loopback refuses the connection from the container. Confirm with ss -lntp.
• A host firewall will drop it silently unless you allow the bridge subnet inbound on docker0 or the br-* interface. You may need to configure a firewall rule to allow the Docker interfaces.

Host and container destinations can be mixed freely in a single GETPUBLICIP_MAPPINGS. The one exception is Seeing the real client IP address, which host destinations cannot work with at all.

Docker Compose networks

Because targets are resolved by service name, the getpublicip container has to be on the same Docker network as the containers it forwards to.

• One default network. Nothing to do, it works as-is.
• Several networks. List getpublicip on every network that holds a service it forwards to.
• Targets in a different compose project. Both projects need to join a shared external network:

  Copydocker network create shared
  

  
  Then in each compose file:

  Copyservices:
    getpublicip:
      networks:
        - shared
  
  networks:
    shared:
      external: true
  

If this is wrong, the logs repeat waiting for destinations to resolve and the agent keeps retrying rather than failing outright.

Check the logs

Copydocker compose up -d
docker compose logs -f getpublicip

A healthy start brings the tunnel up on interface pi0, resolves your destinations, installs the forwarding rules, and pushes the mappings to GetPublicIP. The agent then keeps running, re-checking the destinations and the tunnel itself on a 30 second interval.

This is what a healthy tunnel looks like in the log. It is worth knowing now, so you have something to compare against later:

Copytunnel status up=true interfaces=1 peers=1 healthy=true handshakeAge=31s rxDelta=0

healthy=true is the field that matters. up=true only means the interface exists, and it stays true even on a tunnel that has quietly stopped passing traffic.

Testing

Give it about 30 to 60 seconds before you test. Pushing new mappings puts your IP address into an updating state while we apply them, and requests made during that window will fail. Two or three failures followed by success is normal.

Test from a network that is not your own. Mobile data is the easiest option:

Copycurl http://{YOUR IP ADDRESS}

Connection drops

Nothing to restart and nothing to configure. The tunnel re-establishes itself after a dropped connection, a router reboot, or your ISP handing you a new address.

Most of the time it repairs itself without the agent having to do anything. The tunnel is an outbound connection held open by a keepalive every 25 seconds, and our server re-learns your address from any packet the agent sends, so when your router drops the mapping or moves you to a new port, the next keepalive puts it back.

For the rarer faults a keepalive cannot fix, the agent stops rather than trying to repair the tunnel in place and Docker restarts it into a clean, fresh connection. In the log you will see tunnel appears broken when it first notices, and then exiting so the container is restarted if the problem persists across several checks. That is the recovery working, not an error.

This is the one place the compose file has to be right: recovery depends on your restart policy, so keep restart: unless-stopped on the service. Without it the container stops and stays stopped.

What this does not do is keep your service reachable while your internet is down. If the internet connection to your host is gone, so is your services. The tunnel simply picks itself back up as soon as there is a connection to use.

Seeing the real client IP address

By default, your containers do not see the connecting IP address. Inbound traffic is forwarded to your container and its source address is rewritten by the GetPublicIP service container, so every visitor appears in your access logs as the same local IP address. Geolocation, per-client rate limiting, abuse blocking and fail2ban all see one IP address.

GETPUBLICIP_PRESERVE_CLIENT_IP turns the rewriting off, and your containers then see the real client IP address.

Read what it costs before you turn it on. Rewriting the source IP to a local IP in the compose network means your service containers will automatically reply to through the GetPublicIP container.

When you enable GETPUBLICIP_PRESERVE_CLIENT_IP, your service container must set the default IP route to the GetPublicIP service container so the replies reach the client back through your public IP address. Without it, replies will come out from your ISP connection and the client will drop it. Make sure your services default route is set.

This needs image 1.1.0 or later.

It is also all or nothing. The setting applies to the agent rather than to a single mapping, so it affects every service that agent forwards to.

Why the default route has to change

This is worth thirty seconds, because everything else in this section follows from it. Take one request coming in, and its reply going back out:

Flow on default

Copyvisitor 203.0.113.9 → your public IP → tunnel → agent 
agent rewrites the source to its own address, 172.29.7.2
web replies to 172.29.7.2, which is on its own subnet
agent puts the real address back, reply leaves through the tunnel

When preserve IP on

Copyvisitor 203.0.113.9 → your public IP → tunnel → agent
web sees 203.0.113.9 and then send replies to 203.0.113.9
the web container reply will follow the default route 

A container decides where to send a reply by looking at its own subnet first and its default route second. While the source address is being rewritten, every reply is addressed to something on the local subnet and the default route never comes into it. When you enable preserve IP, every reply is addressed to somewhere out on the internet, so the default route decides all of them. That is why the fix is a route rather than a setting, and why it has to be applied inside each service rather than once on the agent.

Unfortunately Docker does not support this nativly, and so we have to configure the default route on each service container

Example Project

Two versions of the same project. Start with the IPv4-only one unless you are forwarding your public IPv6 address as well — every IPv6 line below is a second thing to get right, and getting it half right gives you a service that works over IPv4 and hangs over IPv6.

IPv4 only

Copyservices:
  getpublicip:
    image: ghcr.io/getpublicip/getpublicip:latest
    restart: unless-stopped
    environment:
      GETPUBLICIP_API_KEY: "${GETPUBLICIP_API_KEY}"
      GETPUBLICIP_MAPPINGS: "80/tcp->web:80"
      GETPUBLICIP_PRESERVE_CLIENT_IP: "true"
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      net.ipv4.ip_forward: 1
      net.ipv4.conf.all.src_valid_mark: 1
    networks:
      appnet:
        ipv4_address: 172.29.7.2      # fixed, because the sidecar routes to it

  web:
    image: nginx:alpine
    restart: unless-stopped
    networks:
      appnet:
        ipv4_address: 172.29.7.3      # give every service a fixed address, not just the agent

  # Points web's default route at the agent, from inside web's own network
  # namespace. Runs once and exits.
  web-route:
    image: alpine:3.20
    network_mode: "service:web"
    cap_add:
      - NET_ADMIN
    restart: "no"
    command: sh -c 'ip route replace default via 172.29.7.2'
    depends_on:
      web:
        condition: service_started
        restart: true               # re-run this sidecar whenever web restarts
      getpublicip:
        condition: service_started

networks:
  appnet:
    driver: bridge
    ipam:
      config:
        - subnet: 172.29.7.0/24
          gateway: 172.29.7.1

IPv4 and IPv6

The same project with the IPv6 half added. Four things change: the network gains enable_ipv6: true and an IPv6 subnet, every service gains a fixed ipv6_address, the agent gains the net.ipv6.conf.all.forwarding sysctl, and the sidecar sets a second default route.

Copyservices:
  getpublicip:
    image: ghcr.io/getpublicip/getpublicip:latest
    restart: unless-stopped
    environment:
      GETPUBLICIP_API_KEY: "${GETPUBLICIP_API_KEY}"
      GETPUBLICIP_MAPPINGS: "80/tcp/ipv4,ipv6->web:80"
      GETPUBLICIP_PRESERVE_CLIENT_IP: "true"
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      net.ipv4.ip_forward: 1
      net.ipv4.conf.all.src_valid_mark: 1
      net.ipv6.conf.all.forwarding: 1
    networks:
      appnet:
        ipv4_address: 172.29.7.2      # fixed, because the sidecar routes to it
        ipv6_address: fd00:c0de:7::2

  web:
    image: nginx:alpine
    restart: unless-stopped
    networks:
      appnet:
        ipv4_address: 172.29.7.3      # give every service a fixed address, not just the agent
        ipv6_address: fd00:c0de:7::3

  # Points web's default routes at the agent, from inside web's own network
  # namespace. Runs once and exits. Both families need their own route.
  web-route:
    image: alpine:3.20
    network_mode: "service:web"
    cap_add:
      - NET_ADMIN
    restart: "no"
    command: >
      sh -c 'ip route replace default via 172.29.7.2;
      ip -6 route replace default via fd00:c0de:7::2'
    depends_on:
      web:
        condition: service_started
        restart: true               # re-run this sidecar whenever web restarts
      getpublicip:
        condition: service_started

networks:
  appnet:
    driver: bridge
    enable_ipv6: true
    ipam:
      config:
        - subnet: 172.29.7.0/24
          gateway: 172.29.7.1
        - subnet: fd00:c0de:7::/64
          gateway: fd00:c0de:7::1

Whichever you start from, repeat the sidecar for each service you forward to, and check the four things below. Each of them produces a service that hangs rather than an error.

Give every service on the network a fixed address, not just the agent. An unpinned service takes the lowest free address, which is the one you reserved for the agent, and depends_on means it often starts first and takes it. The agent then fails to start at all with Address already in use.

If you forward IPv6, set both routes. The IPv6 default route is a separate thing from the IPv4 one, so a sidecar that only sets the IPv4 route leaves IPv6 replies going out through the bridge and those connections hang while IPv4 works. That is what the second ip -6 route replace line in the dual-stack example is for, and it is the most common way that version goes wrong: everything you test over IPv4 looks perfect.

The route does not survive a restart of your service. Docker builds a new network namespace with a clean routing table, so the route is gone and inbound traffic stops until the sidecar runs again. The depends_on above is what handles this: restart: true tells Compose to re-run the sidecar whenever web restarts, so docker compose restart web and docker compose up -d both repair the route on their own.

What it does not cover is your service being restarted by Docker rather than by you. If web crashes, or is killed by the out-of-memory killer, its own restart: policy brings it back without Compose being involved, and nothing re-runs the sidecar. The route is missing, inbound traffic stops, and nothing anywhere reports a problem. Put it back with:

Copydocker compose up -d web-route

We recconmend adding the default IP route in the service Dockerfile so it will survive restarts. Alternativly you can watch for IP routes via docker exec web ip route and then apply the default route when the routes reset.

Host destinations cannot work in this mode. Forwarding to a service on the Docker host needs the reply to come back through the agent as well, and that would mean changing the default route of the host itself.

Check it worked

Run a request against your IP address:

Copycurl http://{YOUR IP ADDRESS}              # one request through your public IP
docker compose logs --tail 10 web           # what your container recorded

You should see the real client IP address in the logs. If you see 172.29.7.2 then the preserve client IP is not enabled and your looking at the default behaviour.

Testing from the Docker host itself is fine. The request still goes out to your public IP, reaches our network and comes back through the tunnel, so what your container records is your ISP connection's public address, which is nothing like the bridge address the rewriting would have put there.

If you forward IPv6, check it separately with curl -6. The two families have separate default routes, so one can work perfectly while the other is silently broken.

When it does not work

Getting the default route wrong looks like nothing at all. The connection just hang. The tunnel stays up and healthy=true keeps appearing, the forwarding rules stay correct, and nothing in docker compose logs getpublicip reports a problem, because from the agent's side there isn't one. The replies are leaving your container by the wrong path and not through your public IP address.

Check the routing table inside the service itself, which is where the problem actually is:

Copydocker exec web ip route      # default must be via the agent's address
docker exec web ip -6 route   # and this one too, if you forward IPv6

Sending outbound traffic through your IP

Everything above is about traffic coming in. This is the other direction: your containers reaching the internet from your public IP rather than from your ISP's address. Useful when something you connect to only allows a known address, or when you want your outbound traffic to come from the same place as your inbound.

GETPUBLICIP_OUTBOUND turns it on, and it needs the same default-route change as client IP preservation does, for the same reason: the reply has to come back through the agent. If you have already set up the sidecar for that, this costs you one line and nothing else.

Copyservices:
  getpublicip:
    image: ghcr.io/getpublicip/getpublicip:latest
    restart: unless-stopped
    environment:
      GETPUBLICIP_API_KEY: "${GETPUBLICIP_API_KEY}"
      GETPUBLICIP_MAPPINGS: "80/tcp->web:80"
      GETPUBLICIP_OUTBOUND: "true"
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      net.ipv4.ip_forward: 1
      net.ipv4.conf.all.src_valid_mark: 1
      net.ipv6.conf.all.forwarding: 1
    networks:
      appnet:
        ipv4_address: 172.29.7.2

Then point each container that should use it at the agent, exactly as in the Example Project above. A container whose route you leave alone carries on using the normal Docker bridge, so you can move one service at a time rather than switching everything at once.

Check it from inside a container you have routed:

Copydocker exec web curl -s https://api.getpublicip.com/ip

It should report your GetPublicIP address rather than your home or office one.

Outbound only, with no ports forwarded

If all you want is the outbound direction, GETPUBLICIP_MAPPINGS becomes optional:

Copy    environment:
      GETPUBLICIP_API_KEY: "${GETPUBLICIP_API_KEY}"
      GETPUBLICIP_OUTBOUND: "true"

An agent started this way leaves the port mappings on your IP address exactly as they are. It will not clear the ones you set up in the dashboard, because asking it to forward nothing is not the same as asking it to delete everything.

What to know before you turn it on

Your containers share one address. Everything behind the agent leaves from the same public IPv4 and the same public IPv6, because one address is what your IP is. Nothing distinguishes one container from another at the far end.

It fails closed. A container routed through the agent has no internet at all while the tunnel is down, where before it would have used your normal connection. That is deliberate — your traffic never quietly falls back to leaving from your ISP address — but it is a real change in behaviour, so think about it before pointing something you depend on at it.

If a container cannot reach the internet, the problem is almost always its route rather than the agent. Check inside the container itself:

Copydocker exec web ip route      # default must be via the agent's address
docker exec web ip -6 route   # and this one too, if you use IPv6

Container permissions

macOS

Use Docker Desktop and the compose file above works unchanged, on both Intel and Apple Silicon.

Other Docker runtimes for macOS (Colima, OrbStack, Rancher Desktop) run different kernels and have not been verified, so we cannot say whether the tunnel comes up on them.

Windows

The compose file above needs no changes on Windows using Docker Desktop.

Docker Desktop needs 64-bit Windows 10 or 11, on a version still supported by Microsoft, and the WSL 2 backend, which is the default. There are then two things to check before you start.

1. Docker Desktop must be in Linux containers mode. The Windows containers engine cannot run this image, and it is not available on the WSL 2 backend in any case.

2. Your WSL2 kernel must be 6.6.x. Older kernels, 5.15 among them, are missing a netfilter module the tunnel needs, and there is no way to work around it from inside the container. The tunnel simply fails to come up with unknown option '--save-mark'. Check and update from PowerShell:

Copywsl --version    # need "Kernel version: 6.6.x"
wsl --update     # if it reports anything older

6.6 only became the settled default around WSL 2.4 to 2.7, so a machine that has not been updated in a while can still be on 5.15. The same requirement applies if you run Docker CE inside a WSL2 distribution rather than Docker Desktop, because it shares the same kernel.

On 6.6, tun is a module rather than built in, so it is worth confirming the device node actually exists before blaming the agent. This command fails at container creation if it is missing:

Copydocker run --rm --device /dev/net/tun alpine ls -l /dev/net/tun

No Windows Firewall rule or port forward is needed. Inbound traffic arrives over the tunnel, so neither Windows Firewall nor WSL's NAT is in the path.

Laptops and sleep

Sleep drops the tunnel. On macOS and Windows the Linux VM suspends when your machine does, and your public IP is unreachable until it wakes, at which point the tunnel re-establishes itself automatically. Try it on your laptop by all means, but run it on a server: a machine that sleeps is a poor host for an always-on public IP.

One API key, one tunnel

A WireGuard key belongs to a single endpoint. If two containers run with the same API key, they will knock each other offline. Whichever one handshaked most recently wins, and the other silently drops traffic until its next keepalive. It looks like random flakiness rather than a clear error. The usual cause is testing on a laptop while a server is already connected with the same key.

This one is self-diagnosing: both containers restart over and over, because each keeps deciding it is the broken one. A container that is restart-looping on a machine whose internet is fine almost always means a second agent is using the same key.

Use one API key per running tunnel.

Troubleshooting

docker compose logs -f getpublicip is the place to start.

To check a configuration without bringing anything up or contacting the API, run it in dry run mode. It prints the rules it would apply and exits:

Copydocker run --rm \
  -e GETPUBLICIP_API_KEY=x -e GETPUBLICIP_DRY_RUN=true \
  -e GETPUBLICIP_ISOLATED_INTERFACE=eth0 \
  -e GETPUBLICIP_MAPPINGS="8080/tcp->web:80" \
  ghcr.io/getpublicip/getpublicip:latest

Frequently Asked Questions

New to GetPublicIP? Start with Getting Started for how the service works. Running your services directly on a host instead of in containers? See the Linux and Windows guides.