A good container disappears. Quven Server now runs in one.

A container looks like a neutral box until something needs the hardware. The server starts, the library scans, the health checks are green, and then the first film needs a transcode and the GPU turns out to exist only outside the container. At that point you’re reading about device permissions instead of watching anything.

We didn’t want Docker support to mean that Quven happened to boot inside an image. The container should behave like any other Quven Server: discoverable on the home network, linked to the same account, keeping its state across restarts, leaving the library alone, and able to say which piece of hardware is doing the work. That version is now public.

We did not want to publish just an image

A registry will hold anything that reaches the end of a build, and that alone doesn’t make it a release. The Quven image is built for Linux AMD64 and ARM64, published under one versioned coordinate, signed with Cosign, and shipped with an SPDX attestation. The public manifest records the digest of the image index and the digest of each platform.

This matters the day a container gets recreated on a different machine. A version tag tells you what you asked for; a digest tells you what actually arrived. We publish both, so a home server can account for itself the way any other piece of infrastructure can.

The Compose bundle follows the same rule. It’s pinned to a published release, so a restart can’t quietly turn into an upgrade, and an upgrade will only happen when you ask for one.

The library comes in, but it is not handed over

Containers are easy to replace and a personal media library isn’t, so the default setup starts from that difference.

Quven keeps its database, its configuration and its logs in a persistent volume. The media directory is the one place it writes into your library, and the only thing it puts there is a subtitle it generated for a film, beside that film. The process runs without Linux capabilities, can’t raise its own privileges, and sees a read-only root filesystem. None of that can make a badly administered host safe on its own, but it gives an ordinary installation sensible boundaries before anyone has thought about hardening.

It also keeps the lifecycle uneventful. Recreate the service and the state is still there; change the image and the media paths don’t move; roll back and the previous digest still names the exact thing that used to run.

Hardware acceleration is not one checkbox

Does a container see the host’s GPU? Not on its own. NVIDIA, VA-API and V4L2 expose different interfaces, and Raspberry Pi HEVC decode uses the stateless Request API, which is a fourth. A single device mount that claims to cover all of them will look convenient and fail on the first difficult file.

The published bundle therefore treats hardware profiles as alternatives. Start with the base service, and if CPU playback already covers your library, you can stop there. If the host has an interface you’ve verified, you can add the matching NVIDIA, Intel/AMD or ARM profile, with only the devices it needs. A missing value fails before startup instead of silently exposing all of /dev. This is less convenient than an accelerate=true switch, and much easier to understand when something changes after a kernel or driver update.

We replayed the public image, not the bench build

For ARM64 we pulled the exact public multi-architecture image onto a Raspberry Pi 4, linked a real server, streamed through authenticated HLS, and used the published Compose profiles, the same ones you’d download.

H.264 decode and encode ran through V4L2. An HEVC source used the Pi’s Request decoder and hardware H.264 encode, and it sustained roughly one and a half seconds of output for every second measured. In a longer manual playback the buffer stayed well ahead of the viewer. The Pi is still an inexpensive small computer, but its hardware blocks were doing the work they were built for.

That evidence covers the Pi 4 configuration we tested and nothing else. Another ARM board or a NAS may well expose different interfaces, and the guide says so; you should check what is actually active on the box before assuming anything from the model name.

Download a release, not a promise

The quick path is short on purpose: download the versioned Compose file and the environment template, point QUVEN_MEDIA_DIR at the library, validate, start, and link the server. The optional hardware profiles come afterwards, one per hardware family, so you only run the commands that apply to your machine.

The image is Server-only. The native clients will still provide the local experience, and the hosted web client can reach a linked server through the managed relay with Pro. Docker changes where the server lives and nothing else about it.

Start with the Docker download on the Quven Downloads page, then follow the complete Docker setup guide.

Frequently asked questions

Why publish a digest as well as a version tag?

A version tag tells you what you asked for; the digest tells you what actually arrived. Both are in the public manifest, for the image index and for each platform, so a container recreated on another machine can be shown to be the same one.

Can the container touch my media?

Only to put a subtitle it generated beside the film it belongs to, and QUVEN_MEDIA_READ_ONLY=true in your .env stops even that. The process runs without Linux capabilities, can’t raise its privileges, and sees a read-only root filesystem. The database, the configuration and the logs live in a persistent volume that survives the service being recreated.

Does hardware transcoding work on a Raspberry Pi?

On the Pi 4 we tested, yes. H.264 decode and encode ran through V4L2, and an HEVC source used the Pi’s Request decoder with hardware H.264 encode, sustaining roughly one and a half seconds of output for every second measured. That evidence belongs to that configuration, and it doesn’t make every ARM board or NAS the same machine.