docker-makemkv puts MakeMKV in a browser over VNC

MakeMKV with a whole desktop behind it in the browser

The problem this solves is a physical one. MakeMKV is a disc ripper, and a disc ripper needs an optical drive, so the machine that rips has to be the machine the drive is plugged into. In a household with a NAS, that means the NAS. This container puts MakeMKV and a graphical Linux desktop into a container and serves the desktop to a browser, so you drive the ripper from a laptop over the network. The README describes it as a lightweight and secure Docker container for MakeMKV, and says you can access the application's full graphical interface directly from any modern web browser with no downloads, installs or setup required on the client side, or connect with any VNC client. It also lists audio playback, seamless clipboard sharing, an integrated file manager and terminal for the container's files and shell, and desktop notifications. A note says the container is entirely unofficial and not made by the creators of MakeMKV.

The quick start passes two device nodes into the container

The launch command is the whole setup, and the parts that matter are the volumes and the device flags:

docker run -d \
    --name=makemkv \
    -p 5800:5800 \
    -v /docker/appdata/makemkv:/config:rw \
    -v /home/user:/storage:ro \
    -v /home/user/MakeMKV/output:/output:rw \
    --device /dev/sr0 \
    --device /dev/sg2 \
    jlesage/makemkv

The README walks through each argument. The appdata directory holds the application's configuration, state, logs and anything that has to persist. The /storage mount exposes host files to the container, and the output mount is where the extracted video is written, both given read-write or read-only as appropriate. The two device flags are the part that trips people up. /dev/sr0 is the first Linux device file corresponding to the optical drive and /dev/sg2 is the second, and an optical drive normally presents both, which is why two are passed. After the container starts you browse to port 5800 on the host, and files from the host appear under the /storage folder inside the container.

Automatic mode rips a disc with no interaction at all

The most interesting capability is the one the README describes as a fully automated mode, where you insert a DVD or Blu-ray disc into an optical drive and MakeMKV rips it without any user interaction. That is the whole point of running this on a server rather than on a desktop, because the server has no screen and nobody sitting in front of it. The Dockerfile shows what that mode depends on, since the runtime image installs xdpyinfo, which the comment says is for the automatic disc ripper, alongside wget for beta key fetching and findutils for the init script. The optical drive detection is handled by a further package that the truncated file listing does not show, and the init script in rootfs/ is the piece that watches for a disc and triggers the rip.

Two MakeMKV builds, one of them closed source

The Dockerfile is the clearest explanation of how MakeMKV's licensing shaped the image. There are two build stages, one called makemkv-bin and one called makemkv-oss, and the comment on the first says it builds the MakeMKV libraries needed by the closed source binary. The OSS stage builds the open source binaries, and the resulting executables are listed: makemkv, mmccextr and mmgplsrv. The closed source side produces libmakemkv.so.1, libdriveio.so.0 and libmmbd.so.0, and the binary stage is verified with xx-verify to check those files landed. Both stages take a download URL as a build argument, pointing at makemkv-oss and makemkv-bin tarballs on makemkv.com, with the version pinned through MAKEMKV_VERSION at 2.0.0. The cross-compilation helpers come from tonistiigi/xx, and the final base image is jlesage/baseimage-gui on alpine 3.19.

Environment variables for identity, files and the running user

The container is configured through environment variables passed with the -e flag, and the ones that matter first are about identity. USER_ID and GROUP_ID set the user and group the application runs as, both defaulting to 1000, and there is a SUP_GROUP_IDS variable for a comma-separated list of supplementary group IDs, which is what lets the container read a disc whose device nodes are group owned. UMASK controls the permissions of newly created files and folders in octal notation, with 0022 as the default. The reason this matters is that a ripper writes large media files, and if the container writes them as root you get files on the NAS that your other accounts cannot read. The README's own note in the table of contents flags that environment variables can also be changed on a running container, and the usage block shows the full run signature with the -e, -v and -p placeholders.

A browser control panel with a terminal inside it

The table of contents reads like a list of web applications, and that is the shape of the thing. There is a web control panel, a web file manager, a web terminal, a web app installable as a PWA, host clipboard sync, web notifications and web audio, each with its own section in the README. The terminal and file manager are the parts that distinguish this from a plain remote desktop. They give you shell access to the container and a browser file manager for the mounted volumes, which means the ripper can be driven from a phone if the disc is already in the drive. The README also documents security topics in sequence, including SSVNC, certificates, the VNC password, web authentication with user credentials, and reverse proxying with routing by hostname or by URL path, which tells you this container was built for people running it behind a shared domain.

Unofficial, MIT, and released in step with MakeMKV itself

Two things shape the maintenance picture. The first is that the container is unofficial, stated in the README, so there is no arrangement with the MakeMKV authors and no guarantee that a MakeMKV change will be matched by a container update. The second is the release pattern, which is unusually tight. The recent tags are v26.09.2 dated 2026-09-23, v26.09.1 dated 2026-09-22 and v26.08.2 dated 2026-08-17, and the names follow the container version, which follows the upstream MakeMKV version, so each release tracks an upstream change rather than a change in the container itself. The licence is MIT with the LICENSE file at the root. The repository layout shows how much is shared infrastructure rather than MakeMKV code, with a deps/ directory, a src/ directory holding the two build stages, a rootfs/ directory for the runtime filesystem, a Dockerfile, an appdefs.yml, and a DOCKERHUB.md alongside the README.

Editorial conclusion

docker-makemkv suits someone with an optical drive attached to a server or NAS who wants to rip discs without a desktop machine, and who is comfortable mapping device nodes into a container and exposing a web interface to their own network. It does not suit a case where you need the GUI to be reachable from the public internet, since the container is designed for a trusted LAN and the README covers authentication and certificates for that reason. Before deploying, confirm your drive maps to the device nodes you pass with the device flags, set the user and group IDs so ripped files land with the right ownership, and note that the last push to the repository was on 2026-09-23 with release v26.09.2 dated the same day.

Frequently asked questions

Official sources

1. Issues
2. jlesage/docker-makemkv on GitHub
3. License: MIT
4. README
5. Releases