Windows support without Docker Desktop

[bjornbyte]

Hello,
is it possible to use daytona on windows without Docker Desktop? Unfortunately in some contexts Docker Desktop requires a paid license and may not be an option to use. However, installing and running docker in WSL is pretty trivial, but daytona doesn't seem to work with that setup out of the box. Running on windows powershell in this case gives:

WARN[0004] Provider requirement not met: Docker is not running. Error: error during connect: in the default daemon configuration on Windows, the docker client must be run with elevated privileges to connect: Get "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.47/info": open //./pipe/docker_engine: The system cannot find the file specified.
INFO[0004] Providers registered
INFO[0005] API REQUEST                                   URI=/health/ latency=0s method=GET status=200
ERRO[0005] Failed to start local container registry: cannot connect to the Docker daemon. Is the Docker daemon running?

and attempting to run in bash in WSL gives

 Starting the Daytona Server daemon...

FATA[0000] on Linux, `server` is only supported with systemd. unix-systemv detected

I think the preferred solution would be to connect //./pipe/docker_engine to docker in WSL, but I don't really know enough to know if that's feasible and sufficient. My main goal is really just to try it out and assess if it would be a useful tool for my team, but wasn't able to get it running following the docs because of lack of Docker Desktop.

[idagelic]

@bjornbyte Setting $env:DOCKER_HOST="unix:///var/run/docker.sock" before running daytona serve in PowerShell should work, but I will check it myself and get back to you.

Regarding the 'server' is only supported with systemd. unix-systemv detected error - we currently don't support daemonizing the server in non-systemd environments, however you may run the server in the foreground - using daytona serve inside WSL

[bjornbyte]

Oh thanks! I'll give those a try.

[idagelic]

@bjornbyte Using the unix sock actually won't work - the way to go is to either do everything on WSL - the Daytona client and server --- or if you prefer the client on Windows with PowerShell, 1. run the Daytona server in WSL, then 2. run "daytona api-key generate" in WSL, and then 3. use the Daytona CLI inside Windows to do "daytona profile add -a http://localhost:3986 -k <API_KEY>"

The approach with connecting just the Docker engine and not the entire Daytona server from Windows to WSL is something we can't support since it would require mounting volumes across OS's . Let me know if the suggested options work for you.

[bjornbyte]

With the first approach (client and server in WSL) creating the workspace worked fine, but I couldn't get the IDEs (tried vscode and goland) to work/connect. For VSCode I suspect it was https://www.daytona.io/docs/misc/troubleshooting/#wsl2-with-visual-studio-code (I didn't try following those steps before moving on to client on windows). I have less solid theories about the goland error, `daytona code' downloaded the ide and then when it tried to open it:

[27990:28066:0110/093617.177279:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[27990:28079:0110/093620.837528:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[27990:28079:0110/093620.837574:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[27990:28066:0110/093620.905426:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[27990:28066:0110/093620.907236:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
. . . repeating the above error over and over . . . 

So I tried the second approach (generate an api key and run the client in windows) and it's working just fine. Thank you for the guidance!

[bjornbyte]

oh, for anyone else that finds this and wants to use that second option, note that I used what the CLI output after generating the api key to add the profile: daytona profile add -a https://api-<SOME_GUID>.try-us.daytona.app -k <API_KEY> rather than -a http://localhost:3986.

daytona profile list seems to already have a "default" entry using "http://localhost:3986", but using daytona profile edit default and adding the api key and doing daytona use default followed by daytona code just gives me

time="2025-01-10T10:22:07-08:00" level=fatal msg="exit status 255"

[idagelic]

I will check why connecting to the API port directly instead of using the reverse proxy didn't work since the proxy approach has some downsides in terms of speed.

You were right in identifying the VSCode issue, I believe GoLand should require a similar "workaround" so we'll make sure to update the docs and test that out too - opened issue #231 for this - so that we can ideally get you fully up and running inside of WSL. Thanks for the follow up and let me know if you run into any other issues