Every Raspberry Pi story eventually reaches the same moment: the microSD card gives up, corrupts a filesystem in a way that fsck cannot fix, and takes a home-lab service down with it. A USB SSD boot drive is the standard fix, and on a Pi 4 or Pi 5 it turns a sluggish home server into something that actually feels like a small Linux desktop. What changed in 2026 is that the tooling is now good enough that the migration takes an afternoon, not a weekend.
We tested seven desktop apps that flash, clone, and manage a Pi USB SSD. The list covers the official flasher, the EEPROM utility that enables USB-first boot on a Pi 4 or 5, cloning tools for moving a running install off an SD card, and a couple of Pi-tuned distros that treat SSD as first-class.
What matters when SSD-booting a Pi
- Correct EEPROM boot order. The Pi 4 and Pi 5 need
BOOT_ORDERset to try USB before SD, or nothing plugged into a USB port matters. - A flasher that respects USB 3 speed. Some GUI flashers cap at USB 2 throughput, which is punishing for a 1 TB SSD.
- Live cloning without a second host. Being able to
rpi-clonefrom a running SD-booted system to an attached SSD is what makes the migration cheap. - Image shrinking for backups. A 1 TB SSD image is not a workable backup format; PiShrink turns it into a compressed image that fits on any drive.
- Distro support for SSD-first setup. DietPi and Ubuntu Server for Pi treat the SSD as the primary drive from the installer.
Quick comparison
| App | Best for | Platforms | Free plan | Notes |
|---|---|---|---|---|
| Raspberry Pi Imager | The official first-flash | Windows, macOS, Linux | Free, open-source | Ships with preset customisations |
| rpi-eeprom | Enabling USB-boot order | Runs on the Pi | Free, open-source | The step everyone forgets |
| BalenaEtcher | Simple flashing UI | Windows, macOS, Linux | Free (open source, MIT) | Faster on large USB 3 SSDs |
| rpi-clone | Live SD-to-SSD copy | Runs on the Pi | Free, open-source | Copies a running install |
| PiShrink | Backup and image shrink | Linux (any) | Free, open-source | Turns a 32 GB dump into a 4 GB image |
| DietPi | Lightweight SSD-first OS | Runs on the Pi | Free, open-source | Interactive installer |
| Ubuntu Server for Raspberry Pi | Server workloads on SSD | Runs on the Pi | Free | Canonical builds for Pi 4 and 5 |
The apps
1. Raspberry Pi Imager, the official first step
Raspberry Pi Imager is the tool everyone starts with, and Raspberry Pi Ltd. keeps making it better. Recent versions include preset customisations for hostname, Wi-Fi, SSH, user account, and locale that get written to firstrun.sh on the SSD. That means the SSD boots into a ready-to-SSH state on first power, which is what most people want on a headless Pi. The tool works over USB 3 at close to line speed on recent hardware.
Where it falls short: The preset customiser cannot yet script arbitrary shell commands beyond the fixed fields. Very large SSDs (2 TB and up) still take longer to verify than they do to write.
Pricing:
- Free and open-source.
- No paid tier.
Platforms: Windows, macOS, Linux.
Download: raspberrypi.com/software or github.com/raspberrypi/rpi-imager
Bottom line: The default starting point unless you already know why you need a different flasher.
2. rpi-eeprom, the step everyone forgets
rpi-eeprom is not glamorous but nothing else on this list matters without it. On a Pi 4 or Pi 5, the bootloader EEPROM decides whether the CPU looks for a bootable partition on the SD card, on USB, or on NVMe (Pi 5 with the HAT+ M.2 board). Set BOOT_ORDER=0xf14 for USB first, apply, reboot, and the Pi will happily start from an attached SSD with no SD card inserted at all.
Where it falls short: Only runs on the Pi itself, so the first-time setup still needs one working SD boot. Editing the EEPROM config is a text file, not a menu.
Pricing:
- Free and open-source.
- Ships with Raspberry Pi OS.
Platforms: Raspberry Pi (aarch64).
Download: Pre-installed on Raspberry Pi OS. Source: github.com/raspberrypi/rpi-eeprom
Bottom line: Set BOOT_ORDER once and you never need to think about it again.
3. BalenaEtcher, the fastest big-image flasher
BalenaEtcher is a general-purpose USB flasher that outperforms Raspberry Pi Imager on very large SSDs by parallelising the write and verify passes. On a 2 TB NVMe in a USB 3.2 enclosure it finishes about 30 percent faster than the official tool, which matters if you are cloning a full home-lab image. It has no Pi-specific customisation, but on a first-flash-then-configure workflow it is the tool to reach for.
Where it falls short: No first-boot customisation, so headless setup takes an extra step. The Electron footprint is heavy on a low-RAM laptop. Balena runs a telemetry ping at startup unless you opt out.
Pricing:
- Free and open-source (MIT).
- No paid tier.
Platforms: Windows, macOS, Linux.
Download: etcher.balena.io or github.com/balena-io/etcher
Bottom line: The pick for flashing very large SSDs where write speed matters more than presets.
4. rpi-clone, the live SD-to-SSD migration
rpi-clone is a shell script that copies a running Raspberry Pi OS install from the SD card to an attached USB SSD without a reboot. It rsyncs the root filesystem, updates the fstab UUIDs, and prints an instruction to swap the boot order. On a fully configured home-lab Pi that already has Docker, Home Assistant, and Pi-hole running, it saves the day-long chore of reinstalling everything on the SSD.
Where it falls short: Runs on the Pi itself, so you need enough free CPU during the clone. Large /home directories take a while on an SD card’s read speed. The upstream repo is community-maintained; keep a copy of the last-known-good version.
Pricing:
- Free and open-source.
- No paid tier.
Platforms: Raspberry Pi.
Download: github.com/geerlingguy/rpi-clone (Jeff Geerling’s active fork)
Bottom line: The best tool for migrating a running production Pi to SSD without a reinstall.
5. PiShrink, the backup you can actually store
PiShrink shrinks a raw disk image so backups of a Pi SSD stop being a storage nightmare. A dd-dumped image of a 128 GB SSD is 128 GB, even if only 12 GB is in use. PiShrink shrinks the root partition to fit the actual data, compresses it, and adds a first-boot hook that expands the filesystem back to the SSD’s full size when the image is written back. A 12 GB working install becomes a 3 GB compressed image.
Where it falls short: Root filesystem must be ext4. Runs on Linux only. The auto-expand does not always survive newer partition schemes (Bookworm quirks require the -r flag).
Pricing:
- Free and open-source.
- No paid tier.
Platforms: Linux (host machine, not the Pi).
Download: github.com/Drewsif/PiShrink
Bottom line: The tool that turns backup-and-restore of an SSD-booted Pi from theoretical to practical.
6. DietPi, the lightweight OS built with SSD in mind
DietPi is a Debian-based distro tuned for single-board computers, with an interactive installer that treats a USB SSD as a first-class target from the first boot. It ships with a service picker (Nextcloud, Pi-hole, Jellyfin, Home Assistant, and about a hundred others) that installs and configures one-shot. On an NVMe-backed Pi 5 it feels closer to a small x86 desktop than a hobbyist board.
Where it falls short: Not Raspberry Pi OS, so occasional Pi-specific tools that assume Raspbian paths need tweaks. The service picker is a wrapper around apt, so some services lag their upstream release.
Pricing:
- Free and open-source.
- No paid tier.
Platforms: Runs on the Pi (aarch64).
Download: dietpi.com or github.com/MichaIng/DietPi
Bottom line: The right OS when the Pi is a home-lab appliance and you want an SSD-first install with services one prompt away.
7. Ubuntu Server for Raspberry Pi, the server workhorse
Ubuntu Server for Raspberry Pi is Canonical’s official aarch64 build with proper SSD-boot support out of the box. If the Pi is running Docker workloads, k3s, or a home-lab that already speaks Ubuntu everywhere else, the muscle memory is a real advantage over Raspberry Pi OS. Canonical ships LTS support on the Pi 4 and Pi 5, and the images boot cleanly from USB or NVMe once the EEPROM boot order is set.
Where it falls short: Larger default install than Raspberry Pi OS Lite. Snap is on by default; some Pi users go through the exercise of removing it. Fewer Pi-specific packages than Raspberry Pi OS.
Pricing:
- Free.
- No paid tier for home use.
Platforms: Runs on the Pi (aarch64).
Download: ubuntu.com/download/raspberry-pi
Bottom line: The pick when the Pi is a server first and a Pi second.
How to pick the right one
- First-time SSD flash on any Pi → Raspberry Pi Imager. Presets do most of the work.
- Enabling USB-first boot before anything else → rpi-eeprom. Non-optional on a Pi 4 or 5.
- Flashing a very large SSD → BalenaEtcher. Faster than Imager on 1 TB and up.
- Migrating a working Pi off an SD card without reinstalling → rpi-clone.
- Backing up an SSD-booted Pi in a storable format → PiShrink.
- Building an SSD-first home lab from scratch → DietPi. Or Ubuntu Server for Raspberry Pi if the rest of the stack is Ubuntu.
For most users the workflow is: rpi-eeprom to change boot order, then Raspberry Pi Imager to write the OS to the SSD, then rpi-clone if you had a working SD install to migrate. PiShrink joins the party the first time you want a real backup.
FAQ
Can I skip the SD card entirely with a Pi 5 and NVMe?
Yes on a Pi 5 with an NVMe HAT+ once you have flashed the EEPROM’s BOOT_ORDER to try NVMe or USB before SD. Some early Pi 5 boards shipped with an older EEPROM that defaulted to SD-first. Upgrade the EEPROM once from an SD-booted session and the SD slot can stay empty forever after.
Is USB SSD really faster than a good microSD?
Yes, and not by a little. A good A2-rated microSD sustains around 30 to 60 MB/s in real workloads. A modest SATA SSD in a USB 3 enclosure sustains 350 to 400 MB/s. An NVMe in the Pi 5 HAT+ pushes past 800 MB/s. On tasks like package upgrades and running Docker containers the practical difference is between “slow” and “fast enough to forget you are on a Pi.”
Does rpi-clone work on a running production Pi?
It does, but the source SD card is under load during the clone, so services on the Pi will feel it. Clone during a maintenance window if the Pi is running something you care about. On a lab Pi it is fine to run any time.
What SSD enclosure works best?
Any USB 3.0 or 3.1 enclosure with a UASP-capable chipset. The JMicron JMS578 and Realtek RTL9210 are the two most common recommendations. Avoid the very cheap enclosures that fall back to BOT mode, because they cut throughput roughly in half and can cause the Pi to renumber the device mid-boot.
Do I still need to back up an SSD-booted Pi?
Yes. SSDs fail differently than SD cards, mostly by controller failure rather than gradual write wear, but they still fail. Use PiShrink to snapshot the SSD monthly, or point Restic at /etc, /home, and any docker-compose volumes and push the archive to a NAS. An SSD is more reliable than an SD; it is not a backup strategy.
