Allow users to choose installed WSL distribution on connection

[quentingosset]

Description

Since my last attempt, I noticed that it is now possible to connect a WSL environment, which is a great improvement.

However, it seems that there is currently no option to choose which installed WSL distribution to use when connecting.

Expected Behavior

It should be possible to select a specific WSL distribution (e.g., Ubuntu, Debian, etc.) among the installed ones.

Suggestion

Add an option to list and select available WSL distributions when establishing the connection.

Additional Context

This would be especially useful for users who have multiple distributions installed for different use cases.

Questions

I also noticed that a licensing mode has been introduced.

• Is the license only required for remote usage?
• Will local usage always remain free?
• Do you plan any changes similar to Docker Desktop licensing, where companies must pay for local usage?
• Finally, have you decided whether the source code will remain public or become private?

Thank you for your work and continuous improvements!

[ZingerLittleBee]

Thanks for the feedback, and good catch on the WSL flow.
Selecting a specific installed WSL distribution is a good suggestion, and I plan to add that in a future iteration.

Regarding licensing: yes, a license is only required for remote usage. The same applies to remote Kubernetes and Podman connections. Local usage will remain free.

There are no plans to introduce a Docker Desktop-style licensing model for local usage in companies. Dockerman is positioned much more as a product for individual users.

As for the source code, the current situation will stay the same for now. The project is still evolving quickly, and it is not ready to be open-sourced yet.

Thanks again for the thoughtful feedback.

[quentingosset]

Hi @ZingerLittleBee , thanks again for the improvements in v5.3.0.

Do you have any ETA for the ability to select a custom WSL distribution instead of using the Dockerman-managed one?

In my case, I’m working with a custom enterprise WSL image where Docker is already running inside the distribution. There is no Docker installed or running on the host machine itself, only inside this WSL environment.

Because of that, I’m currently blocked:

• I can’t use the default Dockerman WSL setup
• And I also can’t use the TCP connection, since it requires a Docker engine running on the host to establish the connection to the endpoint exposed by my custom WSL

Being able to directly target an existing WSL distribution would solve this limitation.

For personal use at home, the current setup works perfectly fine, but in a professional environment this is a blocker for me.

Thanks again for your work and improvements!

[quentingosset]

Hey @ZingerLittleBee i see you close this issue, seems not possible on version 5.3.1 is it normal ?
If still on your roadmap please, can you reopen the issue.

[ZingerLittleBee]

Hi @quentingosset, sorry — I missed your May 5th comment and only caught it now. The close was not intentional, I've reopened the issue.

Realistic ETA: ~1–2 weeks. Happy to share a release build for you to test against your enterprise image once ready.

Thanks for the patience.

[ZingerLittleBee]

Hi @quentingosset — note that Dockerman already supports TCP connections. The "TCP connection" option is a plain HTTP client and does not require Docker running on the Windows host; it connects directly to whatever tcp://host:port you provide, and WSL2 forwards the distro's localhost to Windows.

You'd previously mentioned TCP was working for you — is it not working anymore? If you point the TCP connection at the endpoint your enterprise WSL exposes, what error do you get?

[quentingosset]

Hi @quentingosset — note that Dockerman already supports TCP connections. The "TCP connection" option is a plain HTTP client and does not require Docker running on the Windows host; it connects directly to whatever tcp://host:port you provide, and WSL2 forwards the distro's localhost to Windows.

You'd previously mentioned TCP was working for you — is it not working anymore? If you point the TCP connection at the endpoint your enterprise WSL exposes, what error do you get?

Hey @ZingerLittleBee,

It seems to be working now. I probably used the wrong IP address the last time. Since my WSL environment is local, I initially assumed the IP would be 0.0.0.0 or localhost, but I noticed that it actually uses the WSL adapter IP, which is not always 0.0.0.0 or localhost.

Because of this, I cannot test further for now since Dockerman considers it a remote connection and therefore requires a license :D

In any case, the connection itself seems to work correctly.

However, I would already like to report one bug: on the screenshot below, you can see that the runtime detection is not displayed.

I also wanted to raise a design/question point:
Should I ask my company, which created the image, to expose Docker TCP on 0.0.0.0 / localhost, or would it be possible for Dockerman to detect the local WSL IP range and automatically treat those addresses as non-remote connections? This would avoid triggering the remote licensing restriction for local WSL environments.

Best regards.

[quentingosset]

Hey @ZingerLittleBee do you have any new ?

[ZingerLittleBee]

Local/private TCP endpoints (incl. WSL IPs like 172.x) won't need a license, and the blank "Detected runtime" label is fixed. These will ship a bit later, together with some new features.