Conty, an unprivileged Linux container packed into one executable

One file, no root, no install

Conty is described as an easy to use compressed unprivileged Linux container packed into a single portable executable that works on most Linux distros. The first feature on the list is the shape of the thing, a single executable that you download or create and run, with nothing else required, portable enough to put anywhere including a USB stick. The second is reach, since it works on most distributions, even very old ones, and even without glibc, with Alpine, Void and musl based Gentoo named as examples. The third is that root rights are not required, which is what separates it from the usual container tooling and makes it usable on a locked down corporate machine or a Steam Deck. Underneath, it is based on Arch Linux, so the userland inside is modern and includes fresh video drivers, and the stated intent is that it can run almost anything, including 32-bit applications on a pure 64-bit system.

Compression, and one honest caveat about memory

The container image is compressed with squashfs or dwarfs, which the README says takes a lot less disk space than uncompressed containers and can provide faster filesystem access in some cases. The performance claim is stated carefully, that since it is just a container there is virtually no performance overhead and applications run at full speed, and then the caveat is given immediately. Conty uses a bit more memory, due to the compression and because applications from the container cannot share libraries with the system applications. That is the real trade of this design, and it is worth internalising before you run a memory hungry game inside it. The other transparency promise is about configuration. The README says the experience is almost completely seamless, that all applications you run with Conty read and store their configs in your $HOME directory as if you were not using the container at all, which means a game or a Windows application keeps its settings and its saves outside the container, where the user can see them and where they survive the container being replaced.

Sandboxing, display servers and the package repositories

Three capabilities make the container usable as a desktop environment rather than a command line tool. The first is display server support, since Conty supports Xorg, Wayland and XWayland, so the same container works on a traditional X session, on a modern Wayland session and through the compatibility layer. The second is sandboxing, and the README names the two projects responsible, bubblewrap for the filesystem sandbox and xephyr for the X11 sandbox. The third is the package side. Conty supports the Chaotic-AUR and ALHP repositories, and the AUR as well, so the container can install additional applications beyond the ones it ships with, or the user can run external binaries from their home directory. The combination is the point of the project. A container that only had a fixed application list would be a demo, whereas a container with its own package manager and a display server is a portable environment that can be updated and extended.

What the default release actually contains

The default build is not minimal, and the list is the best description of what Conty is for. It ships Wine-Proton-GE, Steam, Lutris, PlayOnLinux, Minigalaxy, Bottles, the Faugus Launcher, the UMU Launcher and ProtonPlus, so the Windows compatibility stack is fully covered. On the client side there is PrismLauncher and RetroArch, and the graphics and streaming side includes MangoHud, LSFG-VK and Gamescope, which is the trio a Linux gamer needs for frame pacing and overlay. Emulation and remote access are covered by DuckStation, PCSX2, Sunshine and Genymotion, and the everyday applications by OBS Studio, OpenJDK and Firefox. The full list is published in the latest release's pkg_list.txt, so the exact contents of a version are checkable before you download it. The README is clear that this is a starting set rather than a limit, and that you can install more applications or point the container at binaries outside it.

Using it is a prefix and a chmod

Running a program inside Conty means putting the path to the script in front of it, and the documentation is explicit that the script is a prefix rather than a subcommand.

$ chmod +x conty.sh

The chmod is needed once per file, and after that the CLI form takes a command and its arguments.

$ ./conty.sh [command] [command_arguments]

The examples show the range, from a simple application name to an absolute path inside the container and a program invoked with a tool in front of it, and one that shows the environment variable pattern, where WINEPREFIX points at a directory in $HOME and gamescope runs Wine against a game executable. That last example is the shape most Windows game workflows will take, and the fact that WINEPREFIX lives in the home directory is what keeps the prefix outside the container. The README also documents a GUI path, so the same container is reachable without a terminal emulator.

The host requirements are where the setup work is

The requirements section is the most useful part of the documentation, because it is where the failures come from. The stated dependencies are fuse3 or fuse2 and coreutils or other POSIX compliant basic utilities, plus a /tmp directory that allows file execution, which most distributions do by default. The kernel must be at least version 4.4, with 6.0 or newer highly recommended because of the known issues, and it must support unprivileged user namespaces, which some distributions disable by default and which can be enabled through sysfs.

# sysctl kernel.unprivileged_userns_clone=1

On Ubuntu 24.04 and later, and on some other distributions with AppArmor enabled, the kernel.apparmor_restrict_unprivileged_userns sysctl option has to be disabled as well.

# sysctl kernel.apparmor_restrict_unprivileged_userns=0

The Ubuntu 25.04 case is the harshest, where a fusermount3 mount failed with a permission denied error means disabling AppArmor and rebooting. There is one escape hatch for kernels without unprivileged user namespaces, since a system with bubblewrap installed with the SUID bit can still run Conty, in that case by telling it to use the system wide utilities rather than its own built-in ones.

$ export USE_SYS_UTILS=1
$ ./conty.sh command command_arguments

The build scripts, the release rhythm and the licence

The repository is a set of shell scripts and a small amount of C, and the file names describe the pipeline. create-conty.sh is the top level build, create-arch-bootstrap.sh builds the Arch based userland that goes inside, and create-utils.sh produces the utility bundles, with utils.tar.gz and utils_dwarfs.tar.gz checked in as the squashfs and dwarfs variants. At run time conty-start.sh brings the environment up, and the two enter scripts are the two ways in, enter-bwrap.sh for the bubblewrap sandbox and enter-chroot.sh for the chroot route, with init.c and settings.sh providing the C side and the configuration. The README documents both a manual creation path and an automated one through GitHub Actions, which is what makes the project usable as a base for your own distribution rather than only as a consumer of the published builds. The releases move steadily, with 1.29.2 on 2026-06-03, 1.29.3 on 2026-07-28 and 1.29.4 on 2026-09-27, and the last push was on 2026-09-27, so the project is actively maintained with two continuous integration workflows, one for Conty itself and one for the utilities. The licence is MIT, and there is a codespell configuration in the tree, which suggests the project cares about the small things.

Editorial conclusion

Conty fits a Linux user who needs a Windows application or a game to run with the right libraries without polluting the host, and who values being able to carry the whole environment on a USB stick, since the container is a single file that needs no installation and no root. It does not fit a machine whose kernel has unprivileged user namespaces turned off and no bubblewrap with the SUID bit, and it does not fit an Ubuntu 25.04 system where the AppArmor profile has to be disabled and the machine rebooted before the container will mount. Verify three things before you rely on it: that unprivileged user namespaces are enabled on your kernel, that FUSE is available and that /tmp allows file execution, and that the AppArmor restriction on your distribution is not going to block the mount, because on recent Ubuntu that check is the difference between running and not running.

Frequently asked questions

Official sources

1. Issues
2. Kron4ek/Conty on GitHub
3. License: MIT
4. README
5. Releases