Bottles: a Wine prefix manager for Linux, packaged as a Flatpak

What Bottles solves for people running Windows software on Linux

Wine works, but managing it by hand is tedious. Each application may need a different Windows version, a different set of DLL overrides, its own registry state, and its own installed dependencies such as .NET or Visual C++ runtimes. Mixing those into a single default prefix is how you get an application that worked yesterday and fails today.

Bottles organizes that state as discrete prefixes, which the project calls bottles. The repository topics list wineprefix and wineprefix-manager, so the prefix is the unit of management. The application is written in Python with a GTK4 and libadwaita interface, and it targets Linux desktop users rather than server or CI environments. The README states the purpose plainly: "Run Windows Software on Linux."

Who it is for: desktop users who want a graphical way to create a prefix, pick a Windows version for it, install a runtime dependency into it, and launch an installer without typing Wine commands. The topics list also includes games, gaming, dxvk and proton, so gaming is an explicit audience, not an afterthought.

How the prefix model and dependency layer fit together

The application is a front end over Wine. A bottle is a directory on disk holding a Wine prefix; the GUI creates it, records configuration for it, and runs Windows executables against it. Because each bottle is separate, a broken dependency in one does not contaminate another. That is the whole architectural argument for the tool, and it is a sound one.

The repository topics name DXVK and Proton. DXVK translates Direct3D calls to Vulkan, and Proton is Valve's Wine-based compatibility layer. Bottles exposes those as components you can install into a bottle rather than requiring you to compile or fetch them yourself. The dependency list in requirements.txt is revealing about the plumbing: pycurl and requests for downloads, patool for archive extraction, icoextract and pefile for reading Windows executables and their icons, and yara-python, which is a pattern-matching engine commonly used for scanning files. That last dependency suggests some amount of inspection happens around the Windows binaries you bring in.

One structural consequence is worth naming. Because the interface is GTK4 and libadwaita, and because the README carries the stopthemingmy.app badge, the project does not treat heavy desktop theming as a supported configuration. If your workflow depends on restyling every application to match a custom theme, this one pushes back.

Installing Bottles from Flathub and creating a first bottle

The README's installation section offers two routes: a Flathub badge for com.usebottles.bottles and a cpak badge. Flathub is the primary one, and the project describes itself as "primarily and officially distributed as a Flatpak."

Install the application from Flathub:

flatpak install flathub com.usebottles.bottles

After that completes, launch it:

flatpak run com.usebottles.bottles

You should see the Bottles window with an empty list of bottles and an option to create one. Creating a bottle in the interface is where you choose the environment for that prefix. The README does not document the individual environment names or the per-bottle settings in the repository text, so treat the in-app labels as the source of truth for what each option does.

If you prefer to build rather than install, the README gives a development Flatpak path. It requires org.flatpak.Builder from Flathub, a clone of the repository, and this command run from the repository root:

flatpak run org.flatpak.Builder --install --install-deps-from=flathub --default-branch=master --force-clean build-dir build-aux/com.usebottles.bottles.Devel.json

Then launch the development build with `flatpak run com.usebottles.bottles.Devel`. The README warns in bold to back up data before testing experimental builds, which is a fair warning given that the development build shares the same application ID and data directory as the stable one.

Where the Flatpak-first design becomes a constraint

The README is direct about this: because Bottles is primarily distributed as a Flatpak, the project only provides instructions to build it inside a Flatpak environment. The Meson section says as much, and the workaround it offers is to download a nightly Flatpak bundle, install it, then run the build inside that sandbox with `flatpak run -d --filesystem=$PWD --command=bash com.usebottles.bottles.Devel` followed by `./build-aux/install.sh`.

That is a real limitation, not a footnote. If your distribution's packaging policy, your CI, or your personal preference rules out Flatpak, you are outside the supported path. The README also notes that GNOME Builder cannot build Bottles at the time of writing, citing GNOME/gnome-builder#2061, and calls the described workaround "the best workaround we can provide."

A second constraint is the shared data directory. The README states that the `local` branch for release builds is installed alongside the Flathub branch, that both use the same application ID and Bottles data directory, and that changes made by either build affect the other. So running a locally built release next to your Flathub install is not an isolated experiment. Back up first.

There is no documented command-line interface in the repository text. If you need to script prefix creation and application launches from a shell, Bottles is the wrong layer; the GUI is the product.

Bottles compared with running Wine or Proton directly

The honest alternative is Wine itself, plus a launcher such as Lutris, or Proton through Steam for games. The difference is where the management lives.

With plain Wine, you set WINEPREFIX yourself, run winecfg to choose a Windows version, and install dependencies with winetricks. Everything is a command, everything is scriptable, and nothing is hidden. The cost is that you own the bookkeeping. When an application breaks after a dependency update, you reconstruct what changed.

Bottles moves that bookkeeping into a GUI with a per-bottle record. You get discoverability and separation between applications, and you give up the shell-level control that comes with a bare prefix. Proton, by contrast, is aimed at Steam's library and its own runtime; it is not a general manager for arbitrary Windows installers outside Steam. Lutris sits closer to Bottles in intent, but its emphasis is on game installation scripts rather than a general prefix manager with a dependency installer.

If your use case is one game on Steam, Proton already handles it. Bottles earns its place when you have several unrelated Windows applications, each wanting its own environment.

Licence, release cadence and the cost of keeping up

Bottles is licensed GPL-3.0. For end users this changes nothing about running it. For anyone embedding the code in another product, the copyleft terms apply to distributed derivatives, and the repository ships COPYING.md alongside the LICENSE reference in the README badge. That is a description of the licence, not legal advice; read the licence text if your use is not ordinary desktop use.

On cadence, the recent releases are 67.2 on 2026-09-03, 67.3 on 2026-09-07, and 67.4 on 2026-09-07. The last push to the repository was on 2026-09-21. The version scheme is a single incrementing number rather than semantic versioning, so do not read compatibility guarantees into the jump from 67.3 to 67.4.

Upgrade cost is mostly the Flatpak update. The riskier part is the Wine and component layer underneath: a new DXVK or Proton build can change behaviour for an existing bottle. That is precisely why the per-bottle model exists, and why the README's advice to back up before experimental builds is worth taking literally rather than as boilerplate.

There is also a contribution-side cost worth noting. The README states that from 2026-09-10, AI-assisted commits must carry an `Assisted-by` trailer and an `AI-Scope` line, that trivial completions are exempt, and that not following the layout will lead to a closed pull request. That is a governance detail, not a runtime one, but it tells you how the project expects patches to arrive.

Editorial conclusion

Bottles is for Linux users who want per-application Wine prefixes without hand-editing WINEPREFIX directories, and who are willing to accept Flatpak as the supported distribution channel. It is not the right tool if you need a scriptable CLI wrapper around Wine, or if you refuse to run a sandboxed app that manages its own runtime. Before adopting it, verify that your distribution has a working Flatpak installation, that the Flathub remote is enabled, and that the Windows title you care about is not one you already run acceptably under plain Wine or Proton. The repository ships a development manifest at build-aux/com.usebottles.bottles.Devel.json, so if you intend to build rather than install, read that file first.

Frequently asked questions

Official sources

1. bottlesdevs/Bottles on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases