Windows: auto-install Docker Desktop instead of Podman #17

Merged
amiryahaya merged 1 commit from fix/docker-desktop-windows-install into main 2026-08-13 08:02:49 +02:00
Owner

Fixes #11

get.ps1's runtime auto-install path only ever installed Podman on a clean machine, even though install.ps1/upgrade.ps1/uninstall.ps1 already prefer Docker when present. This switches the auto-install target to Docker Desktop.

Resolves the open questions from #11:

  1. Scope — went with option (a): only change what get.ps1 auto-installs on a machine with neither runtime present. install.ps1/upgrade.ps1/uninstall.ps1 needed no changes — they already detect and prefer Docker, falling back to a manually-installed Podman. The rootless-Podman TLS-volume workaround in install.ps1 stays, since Podman support isn't being dropped.
  2. Unattended install fit — confirmed via Docker's own docs: Docker Desktop Installer.exe supports --always-run-service, which starts com.docker.service as an Automatic Windows service. That makes the engine reachable without a signed-in user session or manually launching the Docker Desktop GUI — the same unattended characteristic the Podman CLI-only install had. Installed via winget install ... --override "--quiet --accept-license --backend=wsl-2 --no-windows-containers --always-run-service", passing Docker's documented silent-install flags straight through rather than relying on winget's own --silent mapping (which has open reliability reports for this package).
  3. Licensing — confirmed acceptable.

Also updated the Windows requirements line in README.md.

Not in this PR: install.ps1/upgrade.ps1 are missing TRITON_MANAGE_JWT_SIGNING_KEY generation (same bug as the one just fixed for Linux in #16). Filing that separately since it's unrelated to the runtime choice.

Fixes #11 `get.ps1`'s runtime auto-install path only ever installed Podman on a clean machine, even though `install.ps1`/`upgrade.ps1`/`uninstall.ps1` already prefer Docker when present. This switches the auto-install target to Docker Desktop. **Resolves the open questions from #11:** 1. **Scope** — went with option (a): only change what `get.ps1` auto-installs on a machine with neither runtime present. `install.ps1`/`upgrade.ps1`/`uninstall.ps1` needed no changes — they already detect and prefer Docker, falling back to a manually-installed Podman. The rootless-Podman TLS-volume workaround in `install.ps1` stays, since Podman support isn't being dropped. 2. **Unattended install fit** — confirmed via Docker's own docs: `Docker Desktop Installer.exe` supports `--always-run-service`, which starts `com.docker.service` as an Automatic Windows service. That makes the engine reachable without a signed-in user session or manually launching the Docker Desktop GUI — the same unattended characteristic the Podman CLI-only install had. Installed via `winget install ... --override "--quiet --accept-license --backend=wsl-2 --no-windows-containers --always-run-service"`, passing Docker's documented silent-install flags straight through rather than relying on winget's own `--silent` mapping (which has open reliability reports for this package). 3. **Licensing** — confirmed acceptable. Also updated the Windows requirements line in README.md. Not in this PR: `install.ps1`/`upgrade.ps1` are missing `TRITON_MANAGE_JWT_SIGNING_KEY` generation (same bug as the one just fixed for Linux in #16). Filing that separately since it's unrelated to the runtime choice.
get.ps1's runtime auto-install path only ever installed Podman on a clean
machine, even though install.ps1/upgrade.ps1/uninstall.ps1 already prefer
Docker when present. Switch the auto-install target to Docker Desktop via
winget, using the official installer's --always-run-service flag so
com.docker.service comes up as an Automatic Windows service — matching the
unattended, no-GUI behaviour the Podman CLI-only install had, without
requiring a signed-in user session to reach the engine.

A manually-installed Podman is still detected and used (install.ps1 already
prefers Docker but falls back to Podman); this only changes what gets
auto-installed on a machine with neither runtime present.

Fixes #11
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
primatekuntech/triton-install!17
No description provided.