[GH-ISSUE #262] Support for container labels #179

New issue

Open

opened 2026-10-15 12:57:45 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 12:57:45 +00:00

Owner

Originally created by @salty2011 on GitHub (Oct 7, 2025).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/262

Add capability to specify labels on wolf created containers

Key Features

default labels via config
programmatic labels using API

Use Cases

inject lobby and user info labels
labels default labels to identify wolf
labels for use in triggering scripts

In essence labels allow the application of additional meta data that can be used in a variety of ways.

Originally created by @salty2011 on GitHub (Oct 7, 2025). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/262 Add capability to specify labels on wolf created containers Key Features - default labels via config - programmatic labels using API Use Cases - inject lobby and user info labels - labels default labels to identify wolf - labels for use in triggering scripts In essence labels allow the application of additional meta data that can be used in a variety of ways.

bsakaguchi added the

enhancement

label

2026-10-15 12:57:45 +00:00

bsakaguchi commented

2026-10-15 12:57:46 +00:00

Author

Owner

@simbacyde commented on GitHub (Oct 7, 2025):

One use case is to have a systemd unit check for active wolf sessions (Docker containers) and inhibit suspend on the host machine using, e.g.

docker ps --filter "label=wolf.session=true"

This can currently be done by modifying the base_create_json block in config.toml to include

"Labels": {
    "wolf.session": "true"
}

While this is a fine workaround, it requires modifying every single app to include this block, and managing this when adding new apps. Ideally, Wolf would set some sort of default label for all containers it spawns. This should distinguish from containers which are always active (Wolf itself and PulseAudio) and those which are transient (app containers.)

@simbacyde commented on GitHub (Oct 7, 2025): One use case is to have a systemd unit check for active wolf sessions (Docker containers) and inhibit suspend on the host machine using, e.g. ```shell docker ps --filter "label=wolf.session=true" ``` This can currently be done by modifying the `base_create_json` block in `config.toml` to include ```JSON "Labels": { "wolf.session": "true" } ``` While this is a fine workaround, it requires modifying every single app to include this block, and managing this when adding new apps. Ideally, Wolf would set some sort of default label for all containers it spawns. This should distinguish from containers which are _**always**_ active (Wolf itself and PulseAudio) and those which are transient (app containers.)

bsakaguchi referenced this issue

2026-10-15 12:59:27 +00:00

[GH-ISSUE #489] POST /api/v1/apps/add: apps added through the API have an empty video_producer_buffer_caps → no video until Wolf is restarted #300

bsakaguchi referenced this issue

2026-10-15 13:00:11 +00:00

[PR #179] [MERGED] Wolf UI #385