Ventoy keeps every installer on the stick as a file, not a partition

The drive becomes a folder of images instead of one written image

Most tools that make a bootable USB take an ISO and write it across the whole device, which leaves exactly one thing bootable and nothing spare. Ventoy takes the opposite route. You install it to the drive once, and from then on the drive is a filesystem with a bootloader in front of it. Copy an ISO, a WIM, an IMG, a VHD or an EFI file onto it and it becomes a boot menu entry. Copy five and you get five entries. The feature list is explicit that the image is booted directly with no extraction step, and that the file does not need to occupy contiguous space on the device, so a split or fragmented file still resolves.

The practical effect is on the second install, not the first. Refreshing an installer becomes a file copy whose speed is bounded by the copy itself, and deleting an installer is a delete. Ventoy can also be installed to a USB stick, a local disk, an SSD, an NVMe device or an SD card. The project is written in C, and the repository root holds directories such as GRUB2, EDK2, BUSYBOX, wimboot, IPXE, FUSEISO, ZSTD, SQUASHFS, cryptsetup, ExFAT, vtoyfat and vtoygpt.

One build spans Legacy BIOS, four UEFI targets, MBR and GPT

The claim that shapes most of Ventoy's compatibility story is that the targets are supported in the same way. x86 Legacy BIOS, IA32 UEFI, x86_64 UEFI, ARM64 UEFI and MIPS64EL UEFI are all supported the same way, and both MBR and GPT partition styles are supported the same way, with the partition style support marked as arriving in 1.0.15.

The tested list is long enough to be useful as a lookup rather than as marketing. Windows runs from 7 through 11, Windows Server 2012 through 2025, and WinPE. The Unix column includes DragonFly, FreeBSD, pfSense, OPNsense, GhostBSD, FreeNAS, TrueNAS, XigmaNAS, FuryBSD, HardenedBSD, MidnightBSD, ClonOS, EmergencyBootKit and helloSystem. ChromeOS targets named are FydeOS, CloudReady, ChromeOS Flex and ThoriumOS, and the hypervisor entries are VMware ESXi, Citrix XenServer and Xen XCP-ng. The project also claims 1300+ tested ISO files and support for 90%+ of the distros listed on distrowatch.com. A list that specific is worth checking against your own image before you commit to the drive.

Ventoy Browser reaches installers the stick never held

The second half of the design removes the stick from the equation entirely. Ventoy Browser lets you browse ISO, WIM, IMG, VHD and EFI files that sit on the local disk and boot them, with its own notes page at ventoy.net under doc_browser.html. A machine with a spare internal drive full of installers can therefore boot them without anything being copied to removable media first.

This changes what the medium is for. The stick stops being a container and becomes a pointer, and the images themselves become the thing you manage. Linux vDisk boot and Linux Persistence (supported from 1.0.11) are listed separately in the feature list. If your workflow is a library of images on internal storage with occasional USB use, Browser is the part you will care about, and if your workflow is a single stick handed to someone else, it is the part that does nothing for you.

The main partition's filesystem is the first thing that will refuse your ISO

Ventoy accepts FAT32, exFAT, NTFS, UDF, XFS, Btrfs and Ext2, Ext3 or Ext4 for the main partition, and it supports ISO files larger than 4GB. Those two facts sit next to each other in the feature list and the second one is the reason the first one matters. The 4GB ceiling in FAT32 is a property of that filesystem's file size limit, so images larger than 4GB need one of the other listed filesystems.

Pick the partition format with your largest planned image in mind, format it before the first install rather than after, and treat the filesystem as the part of the setup that is expensive to change later. The project also states that MBR and GPT are both supported, so the partition table is not the variable to worry about here.

Booting an installer is not the same as installing unattended

Several features on the list sound like automation and are not. Windows auto installation and Linux auto installation are both marked as supported from 1.0.09, and variables expansion is supported for the Windows and Linux auto installation script. What is supported is the ability to run a script you supply. Anyone planning a kiosk build or a repeated deployment should treat the auto installation entries as an integration point that needs their own preparation, not as a switch to flip.

The same caution applies to password protection, which is listed as a supported feature alongside menu alias and menu tip message. Aliases and tip messages change what the menu looks like to whoever holds the stick. A password changes who gets past the menu. None of these alter what is readable on the filesystem underneath, so a stick that travels between machines should not be treated as protected storage for anything sensitive. The feature list also says 'Not only boot but also complete installation process'.

Secure Boot is listed for two of the five firmware targets

Secure Boot support is marked as available for IA32 and x86_64 UEFI from 1.0.07, and Secure Boot handling has its own file at the root of the repository. The narrowness is the point. The same feature list that puts ARM64 UEFI and MIPS64EL UEFI on a par with the x86 targets says nothing about Secure Boot on either of them, and the repository carries dedicated trees for the firmware and boot stacks involved. A reader on an ARM machine should assume the combination is unproven rather than assume it inherits from the x86_64 path.

Ventoy's documentation says its default policy bypasses Secure Boot checks for EFI files. If enforcement is required, configure the documented Secure Boot policy and follow the key-enrollment instructions for the target machine. Check whether the machine in front of you has Secure Boot on and what firmware it reports before the day you need the installer. Project activity is not the concern here: the last push to the repository was on 2026-10-22, and the most recent release listed is v1.1.18 from 2026-10-09.

Plugson and a privileged CentOS container are how the project extends itself

VentoyPlugson is a GUI configurator for Ventoy plugins, with its own page at ventoy.net under plugin_plugson.html. The rest of the extension story is the build itself, which lives in the repository as a container definition rather than as a shell script you would run on a workstation. The Dockerfile starts from centos:7 and installs the cross-compilation and filesystem toolchain the C sources need, then hands off to the build script in the INSTALL directory:

CMD cd /ventoy/INSTALL && ls -la && sh docker_ci_build.sh

The compose file that drives it asks for a privileged container and mounts the working tree into it:

version: '2'

services:
  ventoy:
    build: .
    privileged: true
    volumes:
     - .:/ventoy

Read those two files together and the intent is plain: this is a continuous integration image, not an end-user installer. It is privileged, it mounts the checkout, and it produces artefacts for the maintainers. The README lists https://www.ventoy.net as the official website. Building from source is a reasonable path for a fork that needs a different menu or an extra filesystem driver, and an unreasonable one for producing a stick to install a laptop. The project is licensed GPL-3.0, which governs redistribution of anything you build from these sources.

Editorial conclusion

Ventoy earns its place on the stick of anyone who reinstalls operating systems for a living, because the second image costs a file copy instead of a rewrite. It is the wrong choice for a single-install drive, where a plain image writer leaves nothing extra on the medium, and for firmware outside IA32 and x86_64 UEFI, where Secure Boot is not on the feature list. Before committing, format a scratch drive with the filesystem you intend to use and confirm your largest installer still lands on it, because that choice, not the bootloader, is what the stick will refuse later.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes