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

> Ventoy installs a bootloader once and then boots whatever ISO, WIM, IMG, VHD or EFI file you drop onto the drive. That removes the rewrite step every other image writer imposes, and it moves the friction to the filesystem you format and the scripts you supply yourself.

**ventoy/Ventoy** — A new bootable USB solution. Most type of OS supported(Windows/WinPE/Linux/Unix/ChromeOS/Vmware/Xen...) 1300+ ISO files are tested ( List ).

- Repository: https://github.com/ventoy/Ventoy
- Website: https://www.ventoy.net
- Stars: 79,610 · Forks: 4,955
- Language: C
- License: GPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/ventoy-ventoy

## 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. The same applies to the drive's role after the fact: Ventoy can be installed to a USB stick, a local disk, an SSD, an NVMe device or an SD card, which means the drive you keep in a drawer and the drive you clone from can be the same object. That is the whole design in one line, and it is why the project is written in C around vendored trees you can see in the repository root: GRUB2, EDK2, BUSYBOX, wimboot, IPXE, FUSEISO, ZSTD, SQUASHFS, cryptsetup, ExFAT, vtoyfat and vtoygpt all sit side by side at the top level rather than behind a package manager.

## 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 handled identically rather than one per build. 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. When a single image writer needs a different build or a different partition table per machine, that difference is where stick swapping usually goes wrong. Ventoy's answer is to absorb the variation into the bootloader once.

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, the latter marked as supported from 1.0.11, belong to the same category of feature: they extend what happens after the kernel starts rather than adding another menu entry. 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 a modern Windows or Linux image lands on a FAT32-formatted drive only if Ventoy's larger-file support covers the case.

What the documentation does not do is name a default. There is no recommended filesystem, no table mapping image size to partition format, and no note about which choice to revisit when an image set grows. The consequence lands on the reader at the worst moment: the stick boots, the menu lists some installers and not others, and the missing one is the one you needed. 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. Ventoy does not generate the answer file, choose the disk, set the locale or wait for the machine to reboot, and the documentation does not document where those script files are expected to sit on the drive. 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, and the feature list makes no encryption claim, so a stick that travels between machines should not be treated as protected storage for anything sensitive. For the same reason, the project states that it is not only boot but also complete installation process: the installer runs, and from there the work belongs to the operating system's own setup.

## 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, whether a Chromebook in ChromeOS Flex or ChromeOS-derived hardware, should assume the combination is unproven rather than assume it inherits from the x86_64 path.

The older firmware targets have the opposite problem, which is quieter. Ventoy offers a native boot menu style for Legacy and UEFI, but a machine with no Secure Boot and an out-of-date firmware may still reject the stick, and nothing in the documentation enumerates the BIOS settings a reader has to change first. 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-09-29, and the most recent release listed is v1.1.17 from 2026-07-24.

## 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, and it is the supported route for changing behaviour without recompiling. 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:

```dockerfile
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:

```yaml
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. A reader looking for a command to run on a laptop will not find one in the repository; the project points to https://www.ventoy.net as the official website for the release builds. 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.

## 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.

## FAQ

### Which is better, Rufus or Ventoy?

They solve the same problem with different models. Rufus and similar tools write one image across the device, so the stick holds a single installer. Ventoy installs a bootloader once and then treats the drive as a folder: you copy ISO, WIM, IMG, VHD or EFI files onto it and choose one from the boot menu, with no extraction step.

### How to use Ventoy to create bootable USB?

Install Ventoy to the drive once, then copy image files onto it. You can copy many at a time and the boot menu lists them. Ventoy can also be installed to a local disk, SSD, NVMe device or SD card rather than only to removable media.

### What is Ventoy used for?

Creating a bootable USB drive for ISO, WIM, IMG, VHD and EFI files, and browsing and booting those same formats from the local disk with Ventoy Browser. ISO files larger than 4GB are supported, and files do not need to be continuous on the device.

### Can I put Windows ISO on Ventoy?

The tested operating system list covers Windows 7, 8, 8.1, 10, 11, Windows Server 2012 through 2025, and WinPE. Windows auto installation is marked as supported from version 1.0.09, with variables expansion available for the auto installation script you supply.

### How do I install Ventoy on a USB drive?

The README gives no command-line install step. It points to https://www.ventoy.net as the official website for release builds. Building from source happens in a container whose Dockerfile starts from centos:7 and runs docker_ci_build.sh from the INSTALL directory, with a privileged compose service that mounts the checkout into /ventoy.

## Sources

- [Official documentation](https://www.ventoy.net)
- [Official README](https://github.com/ventoy/Ventoy#readme)
- [Project repository](https://github.com/ventoy/Ventoy)
- [Release notes](https://github.com/ventoy/Ventoy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ventoy-ventoy