# backblaze-personal-wine-container: the Backblaze desktop client under Wine > This container runs the Backblaze Personal Backup client, a Windows application, inside Wine on Linux, with a virtual X display, an x11vnc server and a noVNC web interface so the installer can be driven from a browser. It suits Linux administrators who want Backblaze specifically, and it comes with the awkward parts of Wine and a GUI-driven client in an unattended container. **JonathanTreffler/backblaze-personal-wine-container** — Run the Backblaze personal backup client in a docker container - Repository: https://github.com/JonathanTreffler/backblaze-personal-wine-container - Website: https://hub.docker.com/r/tessypowder/backblaze-personal-wine - Stars: 651 · Forks: 54 - Language: Shell - License: AGPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/jonathantreffler-backblaze-personal-wine-container ## A Windows backup client in a Linux container The project runs the Backblaze personal backup client inside a Docker container through WINE, so that the separation and portability capabilities of Docker are available on Linux. The Backblaze client is a Windows desktop program with a graphical interface, and the documentation does not pretend otherwise: the container starts a virtual X server and a VNC server with a web GUI so that you can interact with it. That is the whole design in one sentence, and it is an unusual one. The usual reason to containerise a backup client is to keep it away from the machine it backs up, or to give it a predictable runtime. Here the container is also the only way the Windows binary will run at all on a Linux host. The README carries a clear disclaimer that this project is not affiliated with Backblaze Inc., which is worth noting because the name of the image on Docker Hub carries a maintainer handle rather than a Backblaze one. Anyone deploying this is trusting the container image with the credentials to their backup account, which makes the security section of the documentation the part to read first. The audience is narrow and specific: Linux administrators who have decided on Backblaze and want the client isolated. It is not a general backup solution and does not attempt to be one. ## The stack inside the image The image is assembled from a documented list of components, and reading the list tells you exactly what problem each piece solves. S6-overlay is the process supervisor. x11vnc is the X11 VNC server, and xvfb is the X virtual framebuffer that provides the display the client draws into. openbox supplies a window manager, which matters because a virtual framebuffer alone has no window manager and applications behave oddly without one. noVNC is the HTML5 VNC client, so the interface is reachable from a browser rather than requiring a VNC client on your machine. NGINX is the HTTP server in front of noVNC. stunnel is a proxy that encrypts arbitrary TCP connections with SSL or TLS, and it is what sits in front of the VNC port to keep it off the network in cleartext. WINE is the compatibility layer for Windows applications on Linux, and Winetricks is the helper script that downloads and installs the redistributable runtime libraries some programs need under Wine. The Backblaze client is the final piece, the actual thing being run. That is a heavy image for what it does, and the weight is a direct consequence of the approach. Each of these components is a separate thing that can fail, and the VNC and browser interface in particular mean there is a network-facing surface that a native command-line backup tool would not have. The project says as much in its own status note: this docker should just work for most people, but if you have a complex permissions setup in the filesystem you are trying to back up you will need good knowledge of docker to get it set up. ## Image tags, base versions and platform support The tag table is more informative than it first appears. latest and ubuntu22 both point at the latest stable image based on Ubuntu 22.04, and there are separate ubuntu24 and ubuntu26 tags for the newer base releases. Versioned tags of the form vX.Y are stable releases based on Ubuntu 22.04, and the main tag is an automatic build of the main branch, which the documentation warns may be unstable and is also based on Ubuntu 22.04. The older ubuntu18 and ubuntu20 images are described as end-of-life and no longer built, so a deployment that pinned one of those tags is now running an image nobody rebuilds. The platform table is blunt. linux/amd64 is fully supported. linux/arm64 and linux/riscv64 are marked as currently no support, with a parenthetical maybe in the future. linux/arm/v7, linux/arm/v6, linux/s390x, ppc64le and 386 have no support at all. The justification given is short: as Backblaze runs on Windows and macOS, there is no point in supporting these platforms. That is a fair argument, and it is worth understanding what it means rather than dismissing it. A Raspberry Pi or an ARM server cannot run this image today, so a Linux administrator on ARM hardware is excluded regardless of how convenient the container would otherwise be. The repository layout is consistent with that: three separate Dockerfiles, Dockerfile.ubuntu22, Dockerfile.ubuntu24 and Dockerfile.ubuntu26, each presumably adding the base specific pieces, alongside a rootfs directory, a scripts directory, a patches directory and a renovate.json for dependency updates. ## Environment variables that change how the client behaves Environment variables are set by adding one or more -e arguments to the docker run command, and the table of them is where the operational behaviour is actually defined. DISABLE_VIRTUAL_DESKTOP disables Wine's Virtual Desktop Mode, and it defaults to true. DISABLE_AUTOUPDATE also defaults to true, and its meaning is specific: when true, the container never updates the installed Backblaze client, and it stays on whatever version was current when it was first installed. When false, the container checks Backblaze's client-version feed on start and reinstalls the latest release if a newer one is available. So by default the image pins a version at first run and does not move afterwards, which is the safer default for a backup client but also means you inherit whatever was current the day the container first started. FORCE_LATEST_UPDATE is documented as deprecated and a no-op, and the reason is a good one: Backblaze no longer publishes old installer versions and the Internet Archive no longer mirrors them, so there is no pinned version to choose. The container always installs the current release from backblaze.com, and the variable is kept only for backwards compatibility. ENABLE_NETWORK_MOUNT_MASKING is the one with real operational weight. When true, network-backed mounts, NFS, SMB and CIFS, are overlaid with a local overlayfs so Backblaze treats them as fixed disks and backs them up, because Backblaze otherwise refuses network drives. It requires the container to run with cap_add: SYS_ADMIN and security_opt: apparmor:unconfined, and the documentation says to leave it unset for local mounts. That combination is a meaningful reduction in confinement, so it belongs in a security review rather than in a quickstart. Two more round out the set. UMASK controls the permissions of newly created files, unset by default, in which case the default umask of 022 applies, meaning new files are readable by everyone but writable only by the owner. TZ sets the container timezone, defaulting to Etc/UTC, and the documentation notes you can also map /etc/localtime between host and container. APP_NICENESS sets the priority the application runs at, with a niceness value of -20 the highest and 19 the lowest, unset by default so the default of 0 applies, and a negative value requiring additional permissions on the container. ## The GUI problem and why the container exposes a browser The reason the image ships x11vnc, xvfb, openbox, noVNC and NGINX is that there is no command line for the Backblaze client. Installation of the client requires interaction, and the client presents its own interface. So a container that must be operated by someone who has not sat at the machine, or by an automated pipeline, needs a way to see and drive that interface. What the container provides is a browser-based remote desktop. NGINX serves noVNC, which is a HTML5 VNC client, and x11vnc exports the virtual framebuffer created by xvfb. The Security section of the documentation lists SSVNC, certificates, the VNC password and DH parameters, which tells you the connection is meant to be wrapped in TLS and protected by a password, with stunnel in the image to do the encryption. This is also the project's main operational weakness, and the Project Status section is candid about the class of risk involved. The container, by design, has read and write access to all the data you are trying to back up, and the documentation warns that if you make a grave mistake you could delete stuff. In other words, the isolation that motivated the container does not extend to the backup source, because the client has to be able to read it, and it has write access too. That is worth sitting with before deploying. The mechanism that makes the tool usable is the same mechanism that makes a mistake dangerous. ## Where the image lives and how to point it at your data The image is published on Docker Hub under the maintainer handle, and the repository homepage points at that page, which is where you pull it from. The README also has an Installation Guide section and a Config Directory, Ports, Volumes and Accessing the GUI section that together describe the rest of the setup, along with a set of deployment notes. The README does not publish a copy-and-paste run command for this project, and the copy of the documentation available here does not include the body of the installation guide, so there is no verified command to reproduce here. What the documentation does state is the mechanism: environment variables are supplied by adding one or more -e arguments to the docker run command, and the values are given as a name and a value pair. The volume configuration is the other half of the task, and the network mount option in the environment table refers to Option 2 in the Volumes section of the documentation, which is where the local mount and the network share approaches are laid out. A sensible first session is therefore: pull the image, create the config directory the documentation describes, run the container with the environment variables you actually need rather than all of them, open the noVNC web interface, and complete the Backblaze account setup and backup selection through the browser. After the first successful run, decide about DISABLE_AUTOUPDATE deliberately, because the default pins the client version to whatever was current at first install and the container will not move on its own. The Project Status warning applies to this whole sequence. The container has read and write access to all the data you are trying to back up, and a grave mistake could delete things, so it is worth taking a snapshot of the source before the first run rather than after. ## Licence, versioning and what to check before deploying The licence is AGPL-3.0, which is the strongest copyleft and a deliberate choice for a container that ships a proprietary vendor's client. The repository is not archived, the last push was on 2026-08-06, and that push is the same moment as the v2.2 release, with v2.1.1 on 2026-08-03 and v2.1 on 2026-08-02. The CHANGELOG.md file at the repository root is the place to read what changed between those tags. The AGPL matters in a specific way for a container image. The image is distributed to you and you run it as a network service, and the AGPL's network clause is what governs that use. This review does not give legal advice, and a company running this image internally for a backup job should read the licence and consult whoever handles licence questions for the organisation, because the obligation is triggered by the way the service is offered rather than by whether you modify the code. The practical checklist before a first deployment is short and concrete. Read the Security section on the VNC password, the certificates and the DH parameters, because the VNC surface should not be exposed to a network you do not control. Decide whether your backup source is a local path or a network share, because the second case requires ENABLE_NETWORK_MOUNT_MASKING and the SYS_ADMIN plus unconfined AppArmor settings that come with it. Set TZ so timestamps in the backup log make sense. Leave DISABLE_AUTOUPDATE at its default of true for a first run, so the client version is predictable, and be aware that you will have to revisit the pinned version later. And check the image size, since the Docker Hub image size badge is there because a container carrying a full desktop stack is not small. ## Where this container is the wrong choice The first case is a general backup requirement. This project exists to run one specific vendor's Windows client on Linux. If the need is simply to back up a filesystem, a native Linux tool that runs as a scheduled service with a config file and a log file is smaller, faster to operate and has no browser interface exposed. The container adds Wine, a virtual display, a VNC server, a web proxy and a TLS tunnel to a job that does not need any of them. The second case is an ARM host. linux/amd64 is the only fully supported platform, and arm64, riscv64 and the rest are unsupported, so the container is simply not an option on a Raspberry Pi or an ARM server. The third is a fully unattended operation. DISABLE_AUTOUPDATE defaults to true, and the client itself is graphical. Somebody or something has to drive the install through the noVNC interface at least once, and the documentation does not describe a documented path for a completely hands-off lifecycle, for example initialising the account and setting the backup selection without a human at the browser. The alternative worth comparing is a native backup agent with the same job description. A Linux-native client, or a filesystem snapshot mechanism combined with an object storage target, gives you a service you can configure from a file, monitor with a log and restart without a GUI. The difference in approach is exactly the one this project makes: reality here is a Windows binary being emulated and driven remotely, and everything in the image exists to make that possible. If the vendor client is not a hard requirement, taking it out of the picture removes every complexity the project has. ## Conclusion backblaze-personal-wine-container is the right choice for a Linux host that must use Backblaze Personal Backup specifically, for example because an existing plan or a compliance requirement names it, and where running the Windows client under Wine is acceptable. It is the wrong choice for a general backup need, where a native Linux client or a filesystem-level snapshot tool would be simpler, and it is a poor fit for a fully unattended environment because the client is driven through a graphical interface. Before deploying it, read the Security section on the VNC password, the certificates and the DH parameters, decide whether you need ENABLE_NETWORK_MOUNT_MASKING and therefore SYS_ADMIN and an unconfined AppArmor profile, and mount the backup source read only if the tool supports it so a mistake in the client cannot delete the data it is meant to protect. ## FAQ ### What does the backblaze-personal-wine-container do? It runs the Backblaze Personal Backup client, a Windows program, inside a Docker container through WINE on Linux. It also starts a virtual X server and a VNC server with a web GUI so the client can be interacted with. ### Which platforms does backblaze-personal-wine-container support? Only linux/amd64 is fully supported. linux/arm64 and linux/riscv64 are currently unsupported, as are linux/arm/v7, linux/arm/v6, linux/s390x, ppc64le and 386, with the stated reason that Backblaze itself runs on Windows and macOS. ### How do I update the Backblaze client inside the container? By default DISABLE_AUTOUPDATE is true, so the container never updates the client and it stays on the version current at first install. Setting it to false makes the container check Backblaze's client-version feed on start and reinstall the latest release if a newer one exists. ### Can the container back up network shares? Yes, with a caveat. ENABLE_NETWORK_MOUNT_MASKING overlays NFS, SMB and CIFS mounts with a local overlayfs so Backblaze treats them as fixed disks, and it requires the container to run with cap_add: SYS_ADMIN and security_opt: apparmor:unconfined. ### What licence is backblaze-personal-wine-container released under? AGPL-3.0, with the LICENSE file at the repository root. The project is not affiliated with Backblaze Inc. The last push was on 2026-08-06, the same day as the v2.2 release. ## Sources - [JonathanTreffler/backblaze-personal-wine-container on GitHub](https://github.com/JonathanTreffler/backblaze-personal-wine-container) - [License: AGPL-3.0](https://github.com/JonathanTreffler/backblaze-personal-wine-container/blob/main/LICENSE) - [Project website](https://hub.docker.com/r/tessypowder/backblaze-personal-wine) - [README](https://github.com/JonathanTreffler/backblaze-personal-wine-container/blob/main/README.md) - [Releases](https://github.com/JonathanTreffler/backblaze-personal-wine-container/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jonathantreffler-backblaze-personal-wine-container