Skip to content

Docker model runner cannot be used with -H flag to connect to remote server #653

@blackblather

Description

@blackblather

Description

Client:

  • Windows
  • Client version: 29.2.0
  • Server version: 29.2.0
  • API version: 1.51

Server:

  • Mac Studio M4
  • Client version: 29.2.0
  • Server version: 29.2.0
  • API version: 1.51

When running docker -H ssh://blackblather@192.168.1.151 model <sub-command> I get the following error:

unable to initialize standalone model runner: unable to identify existing standalone model runner: unable to prune stopped model runner containers: unable to identify model runner containers: error during connect: Get "http://blackblather%40192.168.1.151/v1.51/containers/json?all=1&filters=%7B%22label%22%3A%7B%22com.docker.desktop.service%22%3Atrue%2C%22com.docker.model-runner.role%3Dcontroller%22%3Atrue%7D%7D": dial tcp: lookup blackblather@192.168.1.151: no such host

Docker model runner is trying to make an http request to the daemon using the ssh connection params I provided.

SSH connection works fine with "non docker model runner" commands. Eg: docker -H ssh://blackblather:192.168.1.151 ps works just fine.

Using SSH to create a non-interactive session works just fine:
ssh blackblather@192.168.1.151 docker model ps
In this scenario you first log into the server, then run the docker command in the server directly.

But this is not ideal. It means whenever I wanna run some containers in the Mac, I have to first push the images to docker hub for example, or manually move the image to the Mac in some other way.

Reproduce

docker -H ssh://<username>@<server_ip> model <sub-command> (sub-command --> list | ps | etc...)

Expected behavior

I bought the Mac to run local LLMs on the backend for a website I run.
I want to keep using my Windows laptop to develop, and simply have the resources of the Mac easily available from the Windows machine.

The ideal setup:

  • I have some directory within my project (in the windows machine) with the Dockerfile and docker-compose files (using docker model runner inside compose)
    • by the way, I also tried creating a docker-compose.yml in my mac and tried running docker -H ssh://blackblather@192.168.1.151 compose up from the windows machine and it also fails
  • Then create a docker context with the connection properties to connect to the mac.
  • Then simply run docker compose up and have the images build and run on the mac.

This is already possible when not using docker model runner. Normal docker commands already allow for this type of setup.

docker version

Client:
Version: 29.2.0
API version: 1.53
Go version: go1.25.6
Git commit: 0b9d198
Built: Mon Jan 26 19:25:17 2026
OS/Arch: linux/amd64
Context: default

Server: Docker Desktop 4.59.0 (217644)
Engine:
Version: 29.2.0
API version: 1.53 (minimum version 1.44)
Go version: go1.25.6
Git commit: 9c62384
Built: Mon Jan 26 19:26:07 2026
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.2.1
GitCommit: dea7da592f5d1d2b7755e3a161be07f43fad8f75
runc:
Version: 1.3.4
GitCommit: v1.3.4-0-gd6d73eb8
docker-init:
Version: 0.19.0
GitCommit: de40ad0

docker info

Client:
Version: 29.2.0
Context: default
Debug Mode: false
Plugins:
ai: Docker AI Agent - Ask Gordon (Docker Inc.)
Version: v1.17.2
Path: /usr/local/lib/docker/cli-plugins/docker-ai
buildx: Docker Buildx (Docker Inc.)
Version: v0.31.1-desktop.1
Path: /usr/local/lib/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v5.0.2
Path: /usr/local/lib/docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.47
Path: /usr/local/lib/docker/cli-plugins/docker-debug
desktop: Docker Desktop commands (Docker Inc.)
Version: v0.2.0
Path: /usr/local/lib/docker/cli-plugins/docker-desktop
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.31
Path: /usr/local/lib/docker/cli-plugins/docker-extension
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.4.0
Path: /usr/local/lib/docker/cli-plugins/docker-init
mcp: Docker MCP Plugin (Docker Inc.)
Version: v0.37.0
Path: /usr/local/lib/docker/cli-plugins/docker-mcp
model: Docker Model Runner (Docker Inc.)
Version: v1.0.8
Path: /usr/local/lib/docker/cli-plugins/docker-model
offload: Docker Offload (Docker Inc.)
Version: v0.5.41
Path: /usr/local/lib/docker/cli-plugins/docker-offload
pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
Version: v0.0.24
Path: /usr/local/lib/docker/cli-plugins/docker-pass
sandbox: Docker Sandbox (Docker Inc.)
Version: v0.10.1
Path: /usr/local/lib/docker/cli-plugins/docker-sandbox
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /usr/local/lib/docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.19.0
Path: /usr/local/lib/docker/cli-plugins/docker-scout

Server:
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 36
Server Version: 29.2.0
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Discovered Devices:
cdi: docker.com/gpu=webgpu
Swarm: inactive
Runtimes: runc io.containerd.runc.v2 nvidia
Default Runtime: runc
Init Binary: docker-init
containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
runc version: v1.3.4-0-gd6d73eb8
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.6.87.2-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 15.22GiB
Name: docker-desktop
ID: 4a2c5c4b-eb16-40d2-8d2a-a32c44bc7cf4
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Labels:
com.docker.desktop.address=unix:///var/run/docker-cli.sock
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
::1/128
127.0.0.0/8
Live Restore Enabled: false
Firewall Backend: iptables

Additional Info

I am not sure this is is a bug or the intended behavior.
I did notice in the documentation for DRM, it mentions it's possible to "Enable 👉host-side👈 TCP support".

This leaves me thinking if my problem is bug or a design choice.
On the other hand, I don't understand why it would be a design choice because it's already possible to trigger DMR on the remote server using an SSH non-interactive shell (you have to jump around some hoops, but possible nonetheless)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions