[GH-ISSUE #196] Manually installing apps?

bsakaguchi commented

2026-10-15 12:56:50 +00:00

Owner

Originally created by @Anachron on GitHub (Apr 22, 2025).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/196

I am not quite sure if I understood the docs at https://games-on-whales.github.io/wolf/stable/user/quickstart.html & https://games-on-whales.github.io/wildlife/ correctly.

Basically I am running podman and I want to install/run all my apps myself, also update them when neccessary. I use podman and have no socket file (systemd not available here).

Is this currently supported? I am guessing wolf only works when it has access to the podman.sock?

Originally created by @Anachron on GitHub (Apr 22, 2025). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/196 I am not quite sure if I understood the docs at https://games-on-whales.github.io/wolf/stable/user/quickstart.html & https://games-on-whales.github.io/wildlife/ correctly. Basically I am running `podman` and I want to install/run all my apps myself, also update them when neccessary. I use `podman` and have no `socket` file (systemd not available here). Is this currently supported? I am guessing wolf only works when it has access to the `podman.sock`?

bsakaguchi

2026-10-15 12:56:50 +00:00

closed this issue
added the
question
label

bsakaguchi commented

2026-10-15 12:56:52 +00:00

Author

Owner

@ABeltramo commented on GitHub (Apr 22, 2025):

Basically I am running podman and I want to install/run all my apps myself, also update them when neccessary

We provide some apps as Docker images, you are free to pull updates when you like or build and use your own images if you know how to create them. Wolf is not a desktop streaming solution though, if you want to install and run apps on a normal desktop I suggest to use Sunshine instead.

I use podman and have no socket file (systemd not available here).

My understanding is that you don't need to have systemd installed to have a socket available that provides the APIs

podman system service -t 0 &

should start the socket and keep it running forever (-t 0). You can then set the env variable WOLF_DOCKER_SOCKET=/run/podman/podman.sock so that Wolf will pick that up (assuming you bind mount it to the container).

@ABeltramo commented on GitHub (Apr 22, 2025): > Basically I am running podman and I want to install/run all my apps myself, also update them when neccessary We provide some apps as Docker images, you are free to pull updates when you like or build and use your own images if you know how to create them. Wolf is not a desktop streaming solution though, if you want to install and run apps on a normal desktop I suggest to use Sunshine instead. > I use podman and have no socket file (systemd not available here). My understanding is that you don't need to have systemd installed to have a socket available that provides the APIs ``` podman system service -t 0 & ``` should start the socket and keep it running forever (`-t 0`). You can then set the env variable `WOLF_DOCKER_SOCKET=/run/podman/podman.sock` so that Wolf will pick that up (assuming you bind mount it to the container).

bsakaguchi commented

2026-10-15 12:56:52 +00:00

Author

Owner

@Anachron commented on GitHub (Apr 22, 2025):

We provide some apps as Docker images, you are free to pull updates when you like or build and use your own images if you know how to create them. Wolf is not a desktop streaming solution though, if you want to install and run apps on a normal desktop I suggest to use Sunshine instead.

My idea was to use Wolf to stream games to whatever device I want to play with,- no matter if laptop, tablet or even a phone. I thought this was the general idea behind it?

My question is: How does wolf start/stop containers if I manually build them? I guess I always need a socket for it to work?
Or would it work if I just manually pull and start all containers and leave them running/pause them when needed?

Thanks for your quick reply, btw! :-)

@Anachron commented on GitHub (Apr 22, 2025): > We provide some apps as Docker images, you are free to pull updates when you like or build and use your own images if you know how to create them. Wolf is not a desktop streaming solution though, if you want to install and run apps on a normal desktop I suggest to use Sunshine instead. My idea was to use `Wolf` to stream games to whatever device I want to play with,- no matter if `laptop`, `tablet` or even a `phone`. I thought this was the general idea behind it? My question is: How does `wolf` start/stop containers if I manually build them? I guess I always need a `socket` for it to work? Or would it work if I just manually pull and start all containers and leave them running/pause them when needed? Thanks for your quick reply, btw! :-)

bsakaguchi commented

2026-10-15 12:56:52 +00:00

Author

Owner

@ABeltramo commented on GitHub (Apr 22, 2025):

My idea was to use Wolf to stream games to whatever device I want to play with,- no matter if laptop, tablet or even a phone. I thought this was the general idea behind it?

That is correct, I was just trying to be clear that "apps" are Docker images and not just any app that you can install on your host. I wasn't sure we were on the same page there.
As for clients, we stream to Moonlight which is available on almost any platform you can think of: laptops, tablets, phones, TVs and even more esoteric devices like PSVita and Nintendo Switch (homebrews).

My question is: How does wolf start/stop containers if I manually build them? I guess I always need a socket for it to work?
Or would it work if I just manually pull and start all containers and leave them running/pause them when needed?

That's the trick: Wolf will start the container once a Moonlight client starts an app and you'll be able to start and stop apps directly on your client.
Each client will get a complete separate virtual desktop, input devices and home folder so that they'll be completely separated and you can stream different apps to different clients and effectively share a single GPU.

@ABeltramo commented on GitHub (Apr 22, 2025): > My idea was to use `Wolf` to stream games to whatever device I want to play with,- no matter if `laptop`, `tablet` or even a `phone`. I thought this was the general idea behind it? That is correct, I was just trying to be clear that "apps" are Docker images and not just any app that you can install on your host. I wasn't sure we were on the same page there. As for clients, we stream to Moonlight which is available on almost any platform you can think of: laptops, tablets, phones, TVs and even more esoteric devices like PSVita and Nintendo Switch (homebrews). > My question is: How does `wolf` start/stop containers if I manually build them? I guess I always need a `socket` for it to work? > Or would it work if I just manually pull and start all containers and leave them running/pause them when needed? That's the trick: Wolf will start the container once a Moonlight client starts an app and you'll be able to start and stop apps directly on your client. Each client will get a complete separate virtual desktop, input devices and home folder so that they'll be completely separated and you can stream different apps to different clients and effectively share a single GPU.

bsakaguchi commented

2026-10-15 12:56:52 +00:00

Author

Owner

@Anachron commented on GitHub (Apr 23, 2025):

You've somehow answered my second part without answering it. 😆

But I think you're saying that I can't go my route,- wolf always needs the permission to start/stop containers itself and I'm hesistant on doing that. Having access to all my containers isn't something I give lightly. Is there maybe an alternative solution we could do?

Like running podman/docker inside the container itself?

@Anachron commented on GitHub (Apr 23, 2025): You've somehow answered my second part without answering it. 😆 But I think you're saying that I can't go my route,- wolf always needs the permission to start/stop containers itself and I'm hesistant on doing that. Having access to all my containers isn't something I give lightly. Is there maybe an alternative solution we could do? Like running podman/docker inside the container itself?

bsakaguchi commented

2026-10-15 12:56:52 +00:00

Author

Owner

@ABeltramo commented on GitHub (Apr 23, 2025):

The whole point of Wolf is to automate the deployment of virtual desktops, devices and apps in order to dynamically support multiple users. If you don't want that kind of automation and having the API is a deal breaker, it looks like Wolf isn't the right software for you?

I'm going to close this, it's not an issue with the codebase. Feel free to continue the thread if you have any more questions!

@ABeltramo commented on GitHub (Apr 23, 2025): The whole point of Wolf is to automate the deployment of virtual desktops, devices and apps in order to dynamically support multiple users. If you don't want that kind of automation and having the API is a deal breaker, it looks like Wolf isn't the right software for you? I'm going to close this, it's not an issue with the codebase. Feel free to continue the thread if you have any more questions!

bsakaguchi commented

2026-10-15 12:56:53 +00:00

Author

Owner

@yslai commented on GitHub (May 10, 2025):

From reading the code base, it appears there are two missing ingredients in order to support Podman and what has been raised here (i.e. to work out of the box with Podman):

Build the image conforming to the UID/GID mapping and FUSE overlay configuration for a nested rootless container (i.e. like in https://github.com/containers/image_build/tree/main/podman)
Instead of starting containers using the Docker API socket, call Podman (or runc, etc.) with the appropriate command line

This seems to be also related to https://github.com/games-on-whales/wolf/issues/89, which I think was not really answered conclusively. Out of the box, Wolf inside Podman can only run the ball demo. Actually, attempting to call any containerized apps currently will even crash Wolf.

@yslai commented on GitHub (May 10, 2025): From reading the code base, it appears there are two missing ingredients in order to support Podman and what has been raised here (i.e. to work out of the box with Podman): - Build the image conforming to the UID/GID mapping and FUSE overlay configuration for a nested rootless container (i.e. like in https://github.com/containers/image_build/tree/main/podman) - Instead of starting containers using the Docker API socket, call Podman (or runc, etc.) with the appropriate command line This seems to be also related to https://github.com/games-on-whales/wolf/issues/89, which I think was not really answered conclusively. Out of the box, Wolf inside Podman can only run the ball demo. Actually, attempting to call any containerized apps currently will even crash Wolf.

bsakaguchi commented

2026-10-15 12:56:53 +00:00

Author

Owner

@salty2011 commented on GitHub (May 10, 2025):

Thanks for your input!

Right now, we don’t have any plans to support Podman directly and there are a few other items on the teams priority list.

But you're welcome to submit a PR with the functionality.

@salty2011 commented on GitHub (May 10, 2025): Thanks for your input! Right now, we don’t have any plans to support Podman directly and there are a few other items on the teams priority list. But you're welcome to submit a PR with the functionality.

bsakaguchi commented

2026-10-15 12:56:53 +00:00

Author

Owner

@ABeltramo commented on GitHub (May 11, 2025):

Instead of starting containers using the Docker API socket, call Podman (or runc, etc.) with the appropriate command line

@yslai I'll repeat this again: this doesn't make any sense.

It's not "more secure" than using the API, if anything, it's less secure since you are exposing a whole lot more of your host environment instead of just a single unix socket.
Podman is fully supported, as long as you just expose the socket API via

podman system service -t 0

or via systemd, or any other mechanism based on your host OS..
As I said before:

The whole point of Wolf is to automate the deployment of virtual desktops, devices and apps in order to dynamically support multiple users. If you don't want that kind of automation and having the API is a deal breaker, it looks like Wolf isn't the right software for you?

@ABeltramo commented on GitHub (May 11, 2025): > Instead of starting containers using the Docker API socket, call Podman (or runc, etc.) with the appropriate command line @yslai I'll repeat this again: this doesn't make any sense. It's not "more secure" than using the API, if anything, it's less secure since you are exposing a whole lot more of your host environment instead of just a single unix socket. **Podman is fully supported**, as long as you just expose the socket API via ``` podman system service -t 0 ``` or via systemd, or any other mechanism based on your host OS.. As I said before: > The whole point of Wolf is to automate the deployment of virtual desktops, devices and apps in order to dynamically support multiple users. If you don't want that kind of automation and having the API is a deal breaker, it looks like Wolf isn't the right software for you?

bsakaguchi commented

2026-10-15 12:56:53 +00:00

Author

Owner

@yslai commented on GitHub (May 13, 2025):

Thanks for the clarification.

The issue is not just security, and to note my envisioned usage scenario is not that different (“virtual desktops, devices and apps”). But for interoperability/integration into established HPC environment, e.g. Slurm, you do need to adhere to rootlessness and forgoing the API — even when running Docker: https://slurm.schedmd.com/containers.html#docker-scrun Otherwise there is no proper workload scheduling and accounting, if the same hardware is shared for non-graphical (e.g. CUDA) workloads.

@yslai commented on GitHub (May 13, 2025): Thanks for the clarification. The issue is not just security, and to note my envisioned usage scenario is not that different (“virtual desktops, devices and apps”). But for interoperability/integration into established HPC environment, e.g. Slurm, you do need to adhere to rootlessness and forgoing the API — even when running Docker: https://slurm.schedmd.com/containers.html#docker-scrun Otherwise there is no proper workload scheduling and accounting, if the same hardware is shared for non-graphical (e.g. CUDA) workloads.

Rows
Columns

[GH-ISSUE #196] Manually installing apps? #129