Remote Docker Proxy
Monitor an engine located on another server over LAN, VPN, or Tailscale.
A remote Docker proxy grants significant administrative privileges. Never expose it to the Internet and never publish the raw Docker socket. Prefer a private network with source filtering; for untrusted networks, add TLS or an authenticated tunnel.
LAN or Tailscale Architecture
On the remote Docker host:
services:
docker-proxy:
image: tecnativa/docker-socket-proxy:v0.5.0
restart: unless-stopped
environment:
CONTAINERS: 1
IMAGES: 1
VOLUMES: 1
NETWORKS: 1
INFO: 1
POST: 1
DELETE: 0
AUTH: 0
BUILD: 0
EXEC: 0
SYSTEM: 0
ports:
# Définissez cette variable dans le .env local de l'hôte distant.
- "${DOCKER_PROXY_BIND_IP}:2375:2375"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:roSet DOCKER_PROXY_BIND_IP in the local .env file to the actual Tailscale or LAN IP of the remote host. Do not commit this file. Add a firewall rule that allows only the source IP of the NasDash host to TCP 2375.
In NasDash:
http://PRIVATE_PROXY_IP:2375SSH Variant Without Publishing 2375
Create a persistent tunnel from the NasDash host that binds a local port to 127.0.0.1:2375 on the remote host, then make this port reachable from the NasDash container. This approach requires rigorous management of the SSH key and tunnel service; it is not provided automatically by NasDash.
Testing from the Container
docker compose exec nasdash node -e "fetch('http://PRIVATE_PROXY_IP:2375/_ping').then(r=>r.text()).then(console.log)"If the host responds from the machine but not from the container, check Docker routing, firewall rules, and Tailscale rules. Also see Remote Access.
HTTP is only acceptable on a trusted private network
The proxy does not authenticate this URL itself. On a shared or untrusted network, use an authenticated TLS layer or a tunnel, and maintain source filtering.