Summary
Dokploy's Swarm Settings dialog (Advanced → Cluster Settings → Swarm Settings) covers most ContainerSpec fields (Health Check, Restart Policy, Placement, Update Config, Rollback Config, Mode, Network, Labels, Stop Grace Period, Endpoint Spec) but is missing ContainerSpec.Hosts — the Swarm equivalent of Docker's --add-host / Compose's extra_hosts.
Tested on Dokploy v0.28.6.
Use case
Any app that needs to make SSR / server-side requests to a hostname that resolves publicly to the same host it runs on (hairpin-NAT situations). Concrete example: a Next.js app doing fetch('https://pre-prod.example.com/api/...') from inside the container, where pre-prod.example.com resolves to the droplet's public IP — Docker's default bridge usually cannot NAT the packet back to the host's own traefik, so the fetch times out.
The standard fix is to add a hosts entry inside the container pointing the public hostname to traefik's IP on the overlay network (extra_hosts: ["pre-prod.example.com:10.0.1.2"]). This works perfectly when applied manually via docker service update --host-add, but is wiped on every Dokploy Deploy / Rebuild because the UI recreates the service spec without it.
Other scenarios where this is needed:
- Pointing a service at an internal API that isn't in public DNS
- Overriding a hostname for staging (so the same code/env vars work in both environments)
- Working around DNS issues on specific providers
Expected
New section inside Swarm Settings → Hosts (or a top-level "Extra Hosts" field under Advanced) accepting a list of entries like:
These should populate ServiceSpec.TaskTemplate.ContainerSpec.Hosts (array of "IP HOSTNAME" strings) and survive redeploys.
Technical pointer
Docker Swarm API: https://docs.docker.com/reference/api/engine/version/v1.45/#tag/Service/operation/ServiceCreate — TaskTemplate.ContainerSpec.Hosts. The Go SDK accepts this as swarm.ContainerSpec.Hosts []string.
Current workaround
Running a small systemd reconciler on the worker node that watches docker events --filter type=service --filter service=<name> and reapplies --host-add whenever the spec is regenerated. Works but obviously shouldn't be necessary.
Happy to open a PR if there's interest — most of the wiring already exists for the other ContainerSpec fields in the Swarm Settings modal.
Summary
Dokploy's Swarm Settings dialog (Advanced → Cluster Settings → Swarm Settings) covers most
ContainerSpecfields (Health Check, Restart Policy, Placement, Update Config, Rollback Config, Mode, Network, Labels, Stop Grace Period, Endpoint Spec) but is missingContainerSpec.Hosts— the Swarm equivalent of Docker's--add-host/ Compose'sextra_hosts.Tested on Dokploy v0.28.6.
Use case
Any app that needs to make SSR / server-side requests to a hostname that resolves publicly to the same host it runs on (hairpin-NAT situations). Concrete example: a Next.js app doing
fetch('https://pre-prod.example.com/api/...')from inside the container, wherepre-prod.example.comresolves to the droplet's public IP — Docker's default bridge usually cannot NAT the packet back to the host's own traefik, so the fetch times out.The standard fix is to add a hosts entry inside the container pointing the public hostname to traefik's IP on the overlay network (
extra_hosts: ["pre-prod.example.com:10.0.1.2"]). This works perfectly when applied manually viadocker service update --host-add, but is wiped on every Dokploy Deploy / Rebuild because the UI recreates the service spec without it.Other scenarios where this is needed:
Expected
New section inside Swarm Settings → Hosts (or a top-level "Extra Hosts" field under Advanced) accepting a list of entries like:
These should populate
ServiceSpec.TaskTemplate.ContainerSpec.Hosts(array of"IP HOSTNAME"strings) and survive redeploys.Technical pointer
Docker Swarm API: https://docs.docker.com/reference/api/engine/version/v1.45/#tag/Service/operation/ServiceCreate —
TaskTemplate.ContainerSpec.Hosts. The Go SDK accepts this asswarm.ContainerSpec.Hosts []string.Current workaround
Running a small systemd reconciler on the worker node that watches
docker events --filter type=service --filter service=<name>and reapplies--host-addwhenever the spec is regenerated. Works but obviously shouldn't be necessary.Happy to open a PR if there's interest — most of the wiring already exists for the other
ContainerSpecfields in the Swarm Settings modal.