# davincibox: DaVinci Resolve in a container, and the GPU matrix behind it

> davincibox packages the dependencies DaVinci Resolve needs on Linux into a container aimed at atomic and image based desktops such as Fedora Silverblue, Bluefin and Bazzite. The container is the easy part; the interesting content is the README's account of which GPU stacks work, which do not, and who will not help you with them.

**zelikos/davincibox** — Container for DaVinci Resolve installation and runtime dependencies on Linux. Mirrored to https://codeberg.org/zelikos/davincibox

- Repository: https://github.com/zelikos/davincibox
- Stars: 1,028 · Forks: 31
- Language: Shell
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/zelikos-davincibox

## The problem is the dependency list, not the application

DaVinci Resolve is closed source software distributed by Blackmagic Design as a self-extracting installer, and on Linux that installer expects a particular set of libraries to be present. davincibox exists to put those dependencies in a container.

The project says it aims to provide a ready-to-go container with all of the needed dependencies to install and run DaVinci Resolve on Linux, and that the work is based on information compiled by bluesabre in a GitHub Gist. That attribution is the honest description of what the project is: a packaging of someone else's research into what a Resolve installation needs.

The target audience explains the design. davincibox is primarily intended for users of image based systems such as Fedora Atomic Desktops and Universal Blue images, but it can be used on any Linux distro that distrobox is available on.

The reasoning is a general one about atomic systems. On a Silverblue or Bluefin installation, the host is deliberately kept minimal and immutable, and a package that needs twenty specific libraries is exactly the case where installing into the host is wrong. Putting the application and its libraries in a container lets the host stay immutable and lets the whole environment be thrown away and rebuilt.

The project is written in shell, mirrored to Codeberg at `codeberg.org/zelikos/davincibox`, licensed Apache-2.0, and released as v3.3.0 on 2026-05-14, v3.2.1 on 2025-11-02 and v3.2.0 on 2025-06-07, with the last push on 2026-09-12.

## Three supported distributions and a long tail

The OS support section is short and honest. The distros considered officially supported are Fedora Atomic, which covers Silverblue and Kinoite, Bluefin, and Bazzite.

Everything else, and the README names Arch Linux, NixOS, Debian and their derivatives, is best effort and considered community supported. The reason given is a priority statement rather than a technical limitation: the priority for davincibox is image based and atomic systems, because those benefit most from the container based approach.

For Debian, Ubuntu and Linux Mint users who have difficulties, the README points at MakeResolveDeb by Daniel Tufvesson as another option, with a GPU caveat: with MakeResolveDeb, AMD users need to install ROCm or rusticl themselves, and Intel users need `intel-compute-runtime`. That is the shape of the trade-off. On a normal distribution you can install the dependencies natively and get a more integrated result, at the cost of a permanently modified system. On an atomic system you cannot, so the container is the answer.

The project also states plainly that it and its maintainer are not affiliated with or associated with Blackmagic Design, which matters for anyone who has to explain to an organisation why a container around a commercial product is in the pipeline.

## The GPU matrix, and the parts that are not supported

This is the section that makes the README worth reading, because it is where a container around a GPU application is most likely to fail.

The maintainer's own testing has been on an AMD RX 6600XT, an AMD RX 9070 and an Intel Core Ultra 5 125H with Arc integrated graphics, and other users have contributed results in a tracking issue. AMD GPUs use ROCm, AMD's official compute package, and there have been stability issues with ROCm, typically in Fusion, though most things do work. The README links AMD's own GPU support matrix and notes that older cards such as the RX 500 series may not work with ROCm at all.

Intel GPUs use `intel-compute-runtime`, which is included by default, and no issues have been found so far.

NVIDIA is the gap. The maintainer does not have an NVIDIA GPU and says they cannot directly troubleshoot issues with them, and that support for NVIDIA related problems relies on the community.

There is also a documented reversal. `rusticl`, via the `mesa-libOpenCL` package, was previously the default for AMD, but that was found to break ROCm entirely, so it is no longer included in `davincibox-opencl`. The fallback is still available by hand, and the README gives the sequence: enter the container, install the package, and launch Resolve through the wrapper with an explicit path.

```
sudo dnf install mesa-libOpenCL

# If you exclude the path below, run-davinci defaults to launching DaVinci Resolve.
# If you want to launch one of the other programs included with Resolve,
# use the path to its binary as shown below.
run-davinci -c /path/to/binary
```

The `run-davinci` wrapper is therefore not an implementation detail. It is the layer that decides which compute stack the application is launched against, and that decision is what the opencl and ROCm variants differ in.

## The setup script and what the host has to provide

The setup is a shell script that takes the path to the installer you downloaded from Blackmagic's website.

```bash
chmod +x /path/to/setup.sh

/path/to/setup.sh /path/to/DaVinci_Resolve_versionnumber_Linux.run
```

There is also a GUI path for people who prefer it, where on GNOME you open the file manager and run the script from where you downloaded it.

The host requirements are specific and worth listing. You need Podman, and either distrobox or toolbox. You need the latest release of DaVinci Resolve from Blackmagic's website, because the container does not ship the application, only its dependencies. Your host user may need to be a member of the `render` and `video` groups, added with `usermod -aG render,video USERNAME` on the host console, which is about device access to the graphics hardware.

The `lshw` requirement is easy to miss and it is not optional. The README insists on ensuring `lshw` is installed, because `setup.sh` uses it to detect whether you are using an NVIDIA GPU. It is pre-installed on Universal Blue images and may need installing elsewhere.

For NVIDIA hosts there is one more step, the `nvidia-container-toolkit`, which is already present on Universal Blue images such as Bluefin. You may also need an SELinux policy to allow containers to use the GPU, otherwise the symptom is an "Unsupported GPU processing mode" error when launching Resolve.

For AMD on distributions such as Debian, the `rocm-podman-support` package may be needed on the host rather than inside the container.

## Entering the container and wiring it to the desktop

Once the container exists, you get into it with the tool you installed:

```
# Distrobox: `distrobox enter davincibox`
# Toolbox: `toolbox enter davincibox`
```

The README then covers making that work from a desktop icon, which is where the container stops being a command line tool and becomes part of a working desktop. The launcher is the `DaVinciResolve.desktop` file in `$HOME/.local/share/applications`, and the `Exec=` line has to invoke the container with the right tool and pass the binary path through the `run-davinci` wrapper:

```
# Distrobox: `Exec=distrobox enter -n davincibox -- /usr/bin/run-davinci -c /opt/resolve/bin/resolve %u`
# Toolbox: `Exec=/usr/bin/toolbox run -c davincibox /usr/bin/run-davinci -c /opt/resolve/bin/resolve %u`
```

The `-c` flag is the same one from the rusticl instructions, and the README notes you can do the same for the other programs that ship with Resolve by adding the flag after `/usr/bin/run-davinci`.

The repository layout supports the picture that emerges. There is a `Containerfile` rather than a Dockerfile, a `Justfile` for the tasks, a `setup.sh`, a `davinci-dependencies` directory holding the dependency layer, `host_files/` and `system_files/` for what is copied into and out of the container, a `CHANGELOG.md`, and a `cosign.pub` file, which is a public key for signature verification of the container image.

## Where davincibox is the wrong tool

The first wrong case is a conventional distribution with a conventional package manager. On Debian, Ubuntu or Mint, MakeResolveDeb is the documented alternative and gives a more integrated result. davincibox is the answer to a problem that only exists on an immutable host, and using it elsewhere means paying the container overhead for nothing.

The second is an NVIDIA GPU. The maintainer has no NVIDIA hardware, cannot troubleshoot it, and points to the community for support. The container also needs the NVIDIA container toolkit and possibly an SELinux policy, and the failure mode is an error message at launch rather than a clean diagnosis.

The third is a codec workflow. The README says DaVinci Resolve on Linux, especially the free version, has limited codec support, and asks readers not to report missing codec issues unless they can show the codec works outside davincibox but not inside it. That is a fair rule, and it also means the container inherits the codec limits of the application rather than solving them.

The fourth is DaVinci Resolve Studio. The README says there has been limited testing with the Studio version and to use it at your own risk, with a tracking issue.

The fifth is a machine that cannot run Podman with GPU access. Every step above assumes container access to the graphics hardware, and the group membership, the container toolkit and the SELinux policy are all host configuration that has to be right before the container can do anything useful.

## Conclusion

Adopt davincibox if you run an atomic or image based Linux desktop such as Fedora Silverblue, Bluefin or Bazzite and want DaVinci Resolve without turning your host into a distribution specific package zoo. Do not adopt it if your host is a conventional Debian or Ubuntu installation, where a purpose built package such as MakeResolveDeb is the better route, and do not expect NVIDIA to be a smooth path, because the maintainer has no NVIDIA hardware and says so. Before you run the setup script, install `lshw` so it can detect your GPU, add your user to the render and video groups, and check the ROCm support matrix for your card, since the container inherits the limits of the compute stack underneath it.

## FAQ

### What does davincibox actually install?

It provides a ready-to-go container with the dependencies needed to install and run DaVinci Resolve on Linux, based on information compiled by bluesabre in a GitHub Gist. You still download the application itself from Blackmagic's website.

### Which Linux distributions does davincibox support?

Fedora Atomic, which includes Silverblue and Kinoite, Bluefin and Bazzite are considered officially supported. Support for other distributions such as Arch Linux, NixOS, Debian and their derivatives is best effort and community supported.

### Does davincibox work with NVIDIA GPUs?

The maintainer does not have an NVIDIA GPU and says they cannot directly troubleshoot NVIDIA issues. Those users need the nvidia-container-toolkit on the host and may need an SELinux policy, otherwise Resolve fails to launch with an unsupported GPU processing mode error.

### What do I need on the host before running setup.sh?

Podman, either distrobox or toolbox, and the lshw command, because setup.sh uses it to detect an NVIDIA GPU. Your user may also need to be added to the render and video groups with usermod.

## Sources

- [Issues](https://github.com/zelikos/davincibox/issues)
- [License: Apache-2.0](https://github.com/zelikos/davincibox/blob/main/LICENSE)
- [README](https://github.com/zelikos/davincibox/blob/main/README.md)
- [Releases](https://github.com/zelikos/davincibox/releases)
- [zelikos/davincibox on GitHub](https://github.com/zelikos/davincibox)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zelikos-davincibox