wolf: streaming Moonlight sessions from containers, one guest at a time

A streaming server built for sharing hardware

The README describes wolf as a streaming server for Moonlight that lets you share a single server with multiple remote clients so several people can play. The epigraph above it, an attributed line about an intelligent wolf being better than a foolish lion, sets a tone that the rest of the document mostly keeps: the project knows exactly what it is and is comfortable saying so.

The primary goals list is the part to read closely, because it explains why this is not Sunshine with a different name. Multiple users stream different content while sharing one remote host's hardware. Virtual desktops are created on demand at any resolution or frame rate, with no monitor and no dummy plug required. Multiple GPUs can be used simultaneously for different jobs, and the example given is encoding on an integrated GPU while gaming on a discrete one. And the goal of low latency video and audio with full gamepad support is stated as a goal rather than an aspiration.

Two of those deserve emphasis because they are hard. On demand virtual desktops without a physical display removes the dummy plug problem that has dogged headless GPU servers for years. Using two GPUs for two jobs in one server is not a feature that falls out of a streaming server, it is a design decision that shapes everything above it.

The project is MIT licensed, written in C++, has 2,207 stars and 161 forks, and had its last push on 2026-09-22 with 110 open issues. The default branch is `stable`, not `main`, which is a detail worth knowing before you clone.

Linux and container first, not merely supported

The container claim is stated as a primary goal rather than a packaging option: Linux and Docker first, running games with low privileges in containers, based on the Games On Whales image. The word first does real work here. It means the deployment model is a container per session with a virtual input stack injected, not a desktop host with a process running somewhere on it.

That has a direct consequence for anyone evaluating it. Isolation is the point, so an image has to exist for the game or application you want to stream, and if it does not, you build one. The repository tree has a `docker/` directory and a `scripts/` directory, which is where that work lives, and the docs are structured as an Antora site under `docs/`.

The remaining goal in the list is the one that most affects day to day operation: mostly hackable, meaning you edit a config file to change encoding pipelines, GPU settings, or Docker and Podman details. There is also a `.devcontainer/` in the tree, so wolf can be developed inside its own container rather than only deployed in one.

Where wolf declines to compete

The README has a paragraph that many projects would be tempted to leave out, and it is the most useful paragraph on the page. It asks whether you are looking for a general purpose streaming solution, and if so, points you to Sunshine.

That is a real distinction rather than a courtesy. A general purpose streaming server wants to stream whatever is on the host, including a full desktop session, and it wants one session to be simple. wolf wants many isolated sessions and is willing to require a container image and a compositor per session in exchange. Neither is wrong. They are answers to different questions, and the fact that wolf describes the boundary is a reason to trust the rest of its claims.

The acknowledgements section adds useful colour about the project's lineage. Sunshine itself is credited to loki-47-6F-64, who also created the shared Moonlight Discord channel, and ReenigneArcher is credited with being the first stargazer and with keeping Sunshine alive. A separate line credits Drakulix for substantial help developing wolf. This is a small project with a real community around the problem rather than a solo effort, and the Open Collective badge plus the Discord link at the top of the README are how that community is reached.

The release history explains the architecture

There are three releases in the repository, and between them they describe how the current design was arrived at. Version 2023.02, published 2023-02-05, was the first Docker release bundling Gstreamer and wolf with hardware acceleration through VAAPI, NVENC and software encoding. It also added virtual inputs using libevdev and an upgrade to Gstreamer 1.22.0.

Version 2023.06 in June 2023 brought a custom Wayland compositor from Drakulix, plus a fix for scroll amount being sent big endian and an update adding input updates and horizontal scrolling. Both of those are input path bugs, and the fact that they appeared in a release titled around a compositor suggests how tightly input and display are coupled in this design.

Version 2024.07, published 2024-07-10, is the release that most resembles the current project. It implemented device hotplug inside Docker with full container isolation, and linked a rationale document for that decision, which is the kind of thing that signals the maintainers thought about the problem rather than patched around it. It added more joypads, including Nintendo joypads and DualSense with working gyro, acceleration, touchpad, LED and rumble. It split the project into reusable libraries: inputtino, a virtual input library that was also merged into Sunshine, and gst-wayland-display, a micro Wayland compositor usable as a Gstreamer plugin. It also added Sway and made it the default instead of Gamescope.

Why the default compositor changed

The switch from Gamescope to Sway as the default is a small entry with a large amount of information in it. The release notes give the reason: low support on recent Nvidia drivers. That is a compatibility statement, not a preference, and it tells you the project is tuned for current hardware rather than for the configuration its author happens to use.

The same release note explains the library split in a way that clarifies the architecture. If virtual input lives in a standalone library that another project, in this case Sunshine, could merge, and the compositor is a Gstreamer plugin, then both input and display sit inside the streaming pipeline rather than beside it. Input events become stream data, and the compositor becomes something the encoder can be pointed at. That is a coherent design and it explains the input bugs in the earlier release notes.

The practical consequence for a user is that Wolf's behaviour depends on a compositor running per session, and which one you get changes things. The v2024.07 default is Sway, and the README's mention of virtual desktops at any resolution or frame rate is a claim about what that compositor arrangement allows.

What the repository does not answer

The README is short, and it is honest about where the rest lives. Everything operational is one link away to the documentation site at games-on-whales.github.io, which is built from the `docs/` directory in the tree using what looks like an Antora module layout, since images are referenced through paths like `docs/modules/ROOT/images/`.

What the repository itself does not contain is any of the configuration reference, any of the image list, and any of the Docker or Podman details. The README's hackability claim is credible precisely because those details are in files you can edit, but you cannot evaluate them from the README alone. The same is true of the per provider GPU setup, which is what you would most want to check before deploying.

The tree does carry a few files worth knowing about. There is `CMakeLists.txt` and a `cmake/` directory for the C++ build, `.clang-format` and `.clang-tidy` for code style and static analysis, an `85-wolf.rules` file that is evidently a udev rules entry, and `tests/` for the test suite. `AGENTS.md` and `CLAUDE.md` sit at the root next to the README, which tells you something about how the project expects to be worked on by automated tooling as well as by people.

Editorial conclusion

wolf earns its place when one machine has to serve several people at once, because a general purpose host streaming server treats concurrent sessions as a compromise while wolf treats them as the design. The virtual desktop per session, the container boundary, and the shared GPU are all aimed at that. It will not replace Sunshine for the single user who just wants their own desktop on a laptop screen, and the README says so directly. Start with the documentation site linked from the README, read the fake udev page before debugging input, and pick Sway over Gamescope unless you have a reason not to, since that default was chosen for current Nvidia driver support rather than preference.

Frequently asked questions

Official sources

1. games-on-whales/wolf on GitHub
2. License: MIT
3. Project website
4. README
5. Releases