Why I built Wincontainer and why it matters

Headline: Minimal by design — the case for a Windows‑native container tool

Docker Desktop bundles a GUI, background services, a VM/WSL backend, Kubernetes, and a lot of convenience. That convenience comes with tradeoffs: memory, background processes, telemetry, and a larger security surface. Wincontainer intentionally strips those extras away so you get:

• Small runtime footprint — no always‑on GUI or heavy VM unless you opt in.
• Windows‑native integration — uses WSL/Windows APIs and native installers (MSI/portable).
• Auditability and privacy — fewer services to inspect, easier to self‑host update indexes.
• Composable tooling — CLI/TUI first, designed to be embedded in CI and custom installers.

Those differences aren’t “better” in every scenario — they’re different tradeoffs. The rest of this post shows how to turn those tradeoffs into practical advantages.

---

Feature comparison (practical lens)

Below are the attributes that matter to developers and teams, with concrete implications.

Scope and audience

• Wincontainer: Power users, CI, privacy‑sensitive teams, embedded tooling.
• Docker Desktop: General developer audience, teams needing GUI, Kubernetes, and out‑of‑the‑box integrations.

Resource footprint

• Wincontainer: Minimal idle RAM/CPU; no background GUI process.
• Docker Desktop: Idle memory for VM/WSL and GUI; Kubernetes adds more.

Installation and distribution

• Wincontainer: Portable binaries + MSI; easy to ship in CI images or internal tooling.
• Docker Desktop: Installer with system integration, auto‑start services, and optional telemetry.

Security & attack surface

• Wincontainer: Smaller surface; fewer privileged daemons; easier to audit.
• Docker Desktop: More components and services to secure and monitor.

Ecosystem & features

• Wincontainer: Focused on OCI image lifecycle, containers, volumes, networks, sessions, registry ops.
• Docker Desktop: Adds GUI, image browsing, Kubernetes, Compose integration, and enterprise features.

Telemetry & updates

• Wincontainer: You control update index (static JSON on GitHub Raw/CDN); telemetry is opt‑in or absent.
• Docker Desktop: Auto‑update and telemetry options; enterprise channels.

---

Real examples and commands (copy‑paste ready)

Run a container (Wincontainer CLI):

powershellCopy
wslc container run --name hello mcr.microsoft.com/library/hello-world

Install portable vs MSI (PowerShell):

powershellCopy
# Run portable from current folder
.\wslc-tui.exe

# Add MSI-installed folder to PATH (example)
setx PATH "$env:PATH;C:\Program Files\Wincontainer"

Enable nested virtualization for Hyper‑V VMs (for testing inside VMs):

powershellCopy
Stop-VM -Name "w11"
Set-VMProcessor -VMName "w11" -ExposeVirtualizationExtensions $true
Start-VM -Name "w11"

Static update index (example update-index.json):

jsonCopy
{
  "latest": "v1.2.4",
  "assets": {
    "windows-amd64-msi": {
      "url": "https://cdn.example.com/wincontainer/v1.2.4/wincontainer.msi",
      "sha256": "..."
    },
    "windows-amd64-portable": {
      "url": "https://raw.githubusercontent.com/japperJ/Wincontainer/main/releases/v1.2.4.zip",
      "sha256": "..."
    }
  },
  "releaseNotes": "Bugfixes and smaller memory footprint."
}

---

How to benchmark and prove the difference (do this yourself)

Numbers sell. Run these simple measurements on the same machine to show the practical gap.

1. Idle memory and processes

• Start Docker Desktop, wait 2 minutes, record Get-Process and Get-Counter '\Memory\Available MBytes'.
• Start Wincontainer (no GUI), run the same container, record the same counters.

2. Container startup time

• Measure Measure-Command { wslc container run ... } vs Measure-Command { docker run ... }.

3. Disk and install size

• Compare installer sizes and installed footprint (Get-ChildItem 'C:\Program Files\*' -Recurse | Measure-Object -Property Length -Sum).

4. Update traffic

• Host update-index.json on GitHub Raw and behind Cloudflare; measure requests and cache hits to show CDN benefits.

Include the raw commands and a short script in your repo so readers can reproduce the numbers.

---

Migration checklist: when to choose Wincontainer vs Docker Desktop

Use this checklist to recommend a path for readers:

Choose Wincontainer if:

• You need a small, auditable runtime for CI or constrained environments.
• You want to ship a portable binary or MSI without heavy background services.
• You prefer Windows‑native APIs and minimal telemetry.

Choose Docker Desktop if:

• You need an integrated GUI, Kubernetes, and Compose out of the box.
• Your team relies on Docker Desktop integrations and cross‑platform parity.
• You want a single installer that covers most developer workflows.

Migration steps (Docker Desktop → Wincontainer):

1. Inventory Docker Compose services and map them to wslc commands or simple scripts.
2. Replace Docker volumes with wslc volume equivalents or host paths.
3. Replace docker network usage with wslc network commands.
4. Add a CI job that runs wslc commands to validate parity.
5. Provide a small wrapper script for developers to mimic docker commands if needed.

---

Security and privacy: a short audit plan you can publish

1. List running services: Get-Service and Get-Process before/after install.
2. Check open ports: netstat -ano and map to processes.
3. Verify update sources: show update-index.json URL and CDN headers.
4. Telemetry review: document what (if anything) is sent and how to opt out.
5. Least privilege: show how Wincontainer avoids extra privileged daemons.

A short table of “what to audit” makes this section practical and shareable.

---

Conclusion and call to action

Wincontainer isn’t trying to replace Docker Desktop for everyone. It’s a different philosophy: minimal, Windows‑native, and composable. That philosophy unlocks real benefits for CI, privacy‑conscious teams, and anyone who wants a small, auditable container runtime on Windows.