Batocera Download 2026: 43.1 in 12 Steps, 30 Min

Type batocera download into a search bar and you would be forgiven for thinking this is a one-click affair: find button, press button, receive retro-gaming nirvana. It is not that. Batocera is a Linux distribution, not an app, and "downloading" it means selecting one architecture-specific disk image out of several dozen, verifying it, and writing it byte-for-byte onto removable media. Get the wrong file and your board shows you a black screen and nothing else — no error, no apology. This guide walks the entire path for the current 2026 stable, Batocera 43.1, in twelve numbered steps, and it explains why each step exists rather than just barking commands at you. Budget about thirty minutes end to end.

We will also cover the part most tutorials skip: once you have Batocera installed, you should almost never download the whole image again. The system updates itself in place. Knowing the difference between a fresh flash and an in-place upgrade is the single most useful thing an editorial reader can take away, so it gets its own section.

Batocera 43.1 'Glasswing': What You're Downloading

The version that matters right now

As of this writing the current stable is Batocera 43.1, carrying the codename Glasswing. The official batocera.org download page lists it as the recommended build, and the project's changelog records 43.1 as a distinct release entry dated 2026-05-30 — a date you can confirm independently of the download page, which is exactly the kind of cross-check The Machine appreciates. The 43.x line is a maintenance branch on top of the v43 major release that shipped earlier in May 2026; 43.1 is the point release you actually want for a clean install, because point releases exist to fold in the bug fixes that the initial major always ships without.

Batocera is developed in the open. The source tree lives on GitHub under batocera-linux/batocera.linux, and the commit history shows the changelog being maintained continuously — active development, not a mothballed hobby project. That matters because your download's provenance is auditable all the way down to the build scripts.

An image, not an app

What you download is a compressed raw disk image with a .img.gz extension. Inside it are two things: a small, read-only system partition holding the kernel, EmulationStation frontend, and 200-plus pre-configured emulator systems; and a user partition — Batocera calls it share — that holds your ROMs, BIOS files, saves, screenshots, and configuration. When you flash the image, the system partition is fixed and the share partition auto-expands on first boot to fill whatever card you wrote it to. This split is why upgrades are painless: the read-only half gets swapped out while your /userdata half stays untouched.

Batocera versus the frozen alternatives

The obvious comparison is RetroPie, which has effectively frozen at an older release and increasingly shows its age on new silicon. Batocera's pitch is the opposite: a single, actively-versioned image that targets everything from a Raspberry Pi to a modern x86_64 PC to ARM handhelds, with hardware-specific builds compiled for each. If you want a distribution that ships a new dated stable every few months and updates itself over the network, this is the one. If you want to hand-assemble cores and scripts, you want something else. We are here for the former.

Prerequisites: Hardware, Software, Storage

Supported hardware and a realistic floor

Batocera runs on a deliberately wide spread of hardware, and the download page organizes images by that hardware. The four families most readers will touch are: Raspberry Pi (the bcm2711 build covers the Pi 4, 400, and CM4; the Pi 5 uses a separate bcm2712 build); 64-bit PCs (the x86_64 build, Intel or AMD); StarFive RISC-V-adjacent boards (jh7110); and a growing list of ARM handhelds, such as the Anbernic RG40XX served by the h700 build. If you are shopping for a device to run it on, handhelds like the Retroid Pocket line sit at the higher-performance end of that ARM spectrum.

As for a practical floor: a Raspberry Pi 4 with 2 GB of RAM is enough to start, and 4 GB gives comfortable headroom. On PC, a 64-bit dual-core with 4 GB is a sensible minimum; anything you would call "modern" is overkill for 8- and 16-bit systems and appropriate for the sixth generation and up. Batocera does not need a fast disk to run — it needs a reliable one.

The software you actually need

You need exactly two pieces of software on your desktop: a browser to fetch the image, and a tool that writes raw disk images. Do not use file-copy for this — dragging an .img.gz onto a drive does nothing useful. Use one of:

• Raspberry Pi Imager — decompresses .gz on the fly, writes and verifies, and is the least error-prone option for Pi users.
• balenaEtcher — cross-platform, handles compressed images, validates the write. The generic choice for x86_64 and handheld images.
• dd — for the Linux/macOS command line, if you know precisely which device node your card is and enjoy living dangerously.

Storage: the A2 question

This is where most "my Batocera is broken" stories actually begin. Use a genuine, decently fast card: 32 GB or larger, and rated A1 or A2 with a U3 speed class. Batocera writes to the share partition constantly — saves, states, scraped metadata, screenshots — and cheap or counterfeit media corrupts under that load. If you buy a "256 GB" card for the price of a coffee, you are buying a 16 GB card wearing a costume, and it will fail. Booting from a USB SSD on an x86_64 box is even better; the share partition does not care whether it lives on SD, USB stick, or SSD.

Choosing the Correct Image

Decoding the filename pattern

Every official 43.1 image follows a fixed, machine-readable naming convention. Once you can read it, you never pick the wrong file again. The pattern is batocera-[soc]-[version]-[date].img.gz, where the SoC token tells you the target hardware and the date token is the build date, not the release date. Here are real 43.1 filenames pulled straight from the install index:

# Official 43.1 image filenames all follow one pattern:
#   batocera-[soc]-[version]-[date].img.gz

batocera-bcm2711-43.1-20260530.img.gz                 # Raspberry Pi 4 / 400 / CM4
batocera-x86_64-43.1-20260530.img.gz                  # 64-bit PC (Intel / AMD)
batocera-h700-anbernic-rg40xx-v-43.1-20260604.img.gz  # Anbernic RG40XX-V handheld
batocera-jh7110-43.1-20260529.img.gz                  # StarFive JH7110 boards

Note that the handheld build carries a later build date (20260604) than the Pi and PC builds (20260530). That is normal — hardware-specific builds are cut on their own schedule and still belong to the same 43.1 stable. The version number is what matters for "is this current," not the eight-digit date.

Pi, PC, and handheld builds are not interchangeable

This cannot be overstated: bcm2711, bcm2712, and x86_64 are different CPU architectures. An x86_64 image will not boot a Raspberry Pi, and a Pi image will not boot a PC. There is no compatibility mode, no fallback, no "it mostly works." The board either recognizes its bootloader or it shows you nothing. When in doubt about which Pi you own, check the board silkscreen or the exact model — the Pi 5's bcm2712 build is separate from the Pi 4's bcm2711 build precisely because they are different silicon.

A quick architecture reference

Match your hardware to its SoC token before you download anything:

The 12-Step Download-and-Flash Walkthrough

Here is the full path from cold start to playable, with the reasoning behind every step. Follow them in order; several of them exist specifically to catch the mistakes people make when they skip ahead.

1. Identify your exact board and SoC. The image is compiled per architecture, so the correct filename is decided by hardware you already own. Ninety percent of failed installs trace back to this one decision being made carelessly.
2. Go to the official batocera.org/download page. Fetching from the official download page — rather than a random mirror or a re-upload — is how you guarantee provenance. The page maps your hardware to the right image so you are not guessing.
3. Select the image whose SoC token matches your board. Use the filename pattern from the previous section. If you own a Pi 4 you want bcm2711; a PC wants x86_64. This is the step where reading beats clicking.
4. Download the .img.gz and note its published checksum. The compressed image is what you flash directly — good tools decompress it on the fly. Copy the SHA-256 the site publishes next to it; you will need it in the next step.
5. Verify the SHA-256 before you flash. A partial or corrupted download can fail silently or produce a card that will not boot. Thirty seconds of hashing now saves an hour of confusion later.

   # Linux / macOS:
   sha256sum batocera-x86_64-43.1-20260530.img.gz
   
   # Windows (PowerShell):
   Get-FileHash batocera-x86_64-43.1-20260530.img.gz -Algorithm SHA256
   
   # Expected output (hash shown is illustrative):
   $ sha256sum batocera-x86_64-43.1-20260530.img.gz
   b1946ac92492d2347c6235b4d2611184...  batocera-x86_64-43.1-20260530.img.gz

   Compare that string against the one on the download page. If they differ by even one character, re-download.
6. Install a real flashing tool. Raspberry Pi Imager or balenaEtcher will accept the .gz, write the raw image, and read it back to verify. A normal file copy will not produce a bootable card — the image has to be written to the raw device, not into a filesystem.
7. Flash to a quality card or USB (A2, 32 GB+). Select the image, select the target device, write, and let the tool verify. Double-check the target — the tool overwrites the entire device, and it will cheerfully erase the wrong disk if you point it there.
8. Boot it and let the share partition auto-expand. On first boot Batocera resizes /userdata to fill the card. Do not yank power during this — an interrupted expansion truncates your usable storage and you will wonder later why a 256 GB card only shows a few gigabytes.
9. Map your controller. EmulationStation is driven by the gamepad. Hold any button to start the mapping wizard and follow the prompts. Skip this and you are stranded on the menu with no way to move.
10. Connect networking (Ethernet or Wi-Fi). A network connection unlocks the useful half of Batocera: SMB/SSH file transfer, metadata scraping, in-place updates, and RetroAchievements. On a headless box this is how you will load games at all.
11. Copy your ROMs and BIOS into /userdata. Batocera ships zero games and zero BIOS files — a system only appears in the menu once its folder is populated. The share is exposed over the network out of the box:

    # Batocera shares /userdata over the network by default.
    # SMB, from Finder or Explorer:
    smb://BATOCERA/share      -> roms/, bios/, saves/, music/, ...
    
    # Or over SSH / SCP (user: root, default password: linux):
    scp -r ./snes/*.sfc root@BATOCERA:/userdata/roms/snes/

    Which systems accept what, and how many titles a platform can realistically hold, is its own rabbit hole — see our breakdown of how many games a platform can actually hold before you assume a folder of thousands will just work.
12. Change the default password and reboot. The root account ships with the password linux, which is public knowledge. A networked machine with default credentials is an open door. Change it in the network settings, reboot, and you are done.

Updating Without Re-Downloading

batocera-check-updates and batocera-upgrade

Here is the part that separates people who understand Batocera from people who re-flash their card every few months for no reason: you do not re-download the image to update. The system upgrades itself in place, swapping the read-only system partition while leaving your /userdata — every ROM, save, and config — completely untouched. From an SSH session or the built-in F1 terminal, two commands do the work:

# user: root   default password: linux (change it!)
batocera-check-updates     # ask the mirror what stable build is current
batocera-upgrade           # download + apply the current stable, keep /userdata

# Expected output:
$ batocera-check-updates
Checking for updates...
Current version: 43.1-20260530
Latest  version: 43.1-20260530
System is up to date.

batocera-check-updates is a read-only query — it compares your build against the mirror and tells you whether a newer stable exists. batocera-upgrade is the one that acts. The official upgrade documentation on the Batocera wiki is the canonical reference, and it is worth reading once so you understand what the command touches and, more importantly, what it does not.

The Updates & Downloads menu

If you prefer not to touch a terminal, the same machinery is wired into EmulationStation. Press START to open the main menu and go to Updates & Downloads. The built-in updater performs the same in-place upgrade as the command line, with a progress bar instead of a console. This is the path to recommend to anyone who came to Batocera to play games rather than administer a Linux box: no image re-download, no re-flash, no lost saves.

Manual upgrades and downgrades by URL

Sometimes you need a specific build — to pin a version, to test something, or to roll back after a regression. Batocera documents pointing batocera-upgrade directly at a build URL for exactly this:

# Force a specific build by giving batocera-upgrade a direct URL:
batocera-upgrade [url-to-a-specific-img-gz]

# Example shape, using a project mirror's latest stable x86_64 path:
batocera-upgrade https://mirror.example.org/batocera/x86_64/stable/last/batocera-x86_64.img.gz

Downgrades work the same way — point the command at an archived build directory instead of the latest one. The project deliberately separates current stable releases from older archive builds, and the manual-upgrade page tells you where the mirror directories and archives live. Use the real mirror URL listed on the download page; the one above is a placeholder shape, not a live address.

Content Downloader and store.batocera.org

What Content Downloader is

Batocera has shipped a Content Downloader feature since version 5.27 — which, given we are now on 43.1, means it is one of the more battle-tested parts of the system. It uses the built-in package manager to fetch freely distributed extras: bezel and overlay packs, theme music, additional themes, and other enhancements. Note the word freely. This is not a channel for copyrighted games; it is a channel for the community-made cosmetic and utility content that surrounds them.

store.batocera.org and the package manager

The project also runs a store site at store.batocera.org, and the wiki is explicit that Batocera's "store" is tied to the Content Downloader experience rather than being a paid marketplace. In other words, when you see the word "store" in the Batocera world, read it as "free package catalog," not "checkout page." You are not buying anything; you are pulling optional add-ons through the same package mechanism that manages the rest of the system. It is a clarification worth making, because the word carries the wrong connotations everywhere else on the internet.

Where the emulators come from

Under the hood, most of Batocera's emulators are libretro cores — the same cores you would otherwise manage by hand in a standalone RetroArch setup. Batocera bundles and pre-configures them so you do not have to, but the plumbing is standard libretro, and the libretro documentation applies directly to core-level behavior, options, and BIOS requirements. If a specific system misbehaves, the core's own docs are usually where the answer is.

Five Common Pitfalls (and Fixes)

Architecture and media mistakes

These are the errors that eat the most time, ranked by how often they happen:

• Downloading the PC image for a Pi (or vice versa). The single most common failure. Fix: re-read the SoC token in the filename and match it to your exact board — bcm2711 for a Pi 4, bcm2712 for a Pi 5, x86_64 for a PC. There is no cross-architecture fallback.
• Trying to "copy" the .img.gz onto the card. Dragging the file into a drive window produces a card with one useless file on it. Fix: use Raspberry Pi Imager or balenaEtcher, which write the raw image and decompress the .gz automatically. Do not manually extract it first, either — the good tools want the compressed file.
• Using a fake or worn-out SD card. Symptoms are corruption after a few weeks, disappearing saves, or a card that reports far more capacity than it has. Fix: buy genuine A1/A2 U3 media from a reputable seller, and re-flash onto it. Storage is the foundation; do not cheap out on it.

Update and content mistakes

• Re-downloading the whole image to "update." Wasteful and unnecessary. Fix: run batocera-upgrade or use START -> Updates & Downloads. Only re-flash for a genuinely fresh install or when moving to different hardware.
• Expecting games or BIOS to be included. They are not, and that is by design — Batocera distributes the emulators, not the copyrighted content that runs on them. Fix: supply your own legally-obtained dumps into /userdata/roms and /userdata/bios. A system that does not appear in the menu almost always means its folder is empty or its required BIOS is missing.
• Leaving the default password in place. The root/linux pairing is documented publicly; on a networked box it is a liability. Fix: change it during setup and reboot. This is step twelve for a reason.

Troubleshooting Table

How to read this table

Most Batocera problems fall into a handful of categories: wrong image, bad media, missing content, or unconfigured input. The table below maps the symptom you see to the cause and the fix. Work from symptom to cause to fix, and resist the urge to re-flash before you have ruled out the cheaper explanations.

Advanced Tips

Portable userdata and multi-boot

Because the system partition is read-only and separate from /userdata, you can treat your data as portable. On an x86_64 machine, install Batocera to an internal SSD and keep a second copy of the share on a USB drive for backups, or run entirely from USB so the internal disk is never touched. When you move to newer hardware, you copy /userdata across rather than rebuilding from scratch. Keep a periodic backup of at least /userdata/system — that is where your configuration lives, and it is small.

Per-system and per-game overrides

Batocera's configuration is hierarchical. Global settings live in batocera.conf, but you can override them for a single system or even a single game. The precedence runs global, then per-system, then per-game — the most specific setting wins. This is how you run one emulator at a different resolution, force a specific core for a troublesome title, or enable a shader only for the systems that benefit from it. When something behaves differently for one game than for the rest of its system, an override is usually the reason.

# /userdata/system/batocera.conf  (override examples)
# Force a specific core for one system:
snes.core=snes9x

# Per-game setting via the game's config key (set through the UI or file):
n64["Some Game (USA).z64"].ratio=4/3

# Enable a CRT-style shader only for a system that suits it:
nes.shaderset=scanlines

Bezels, achievements, and metadata

Three add-ons repay the effort. The Bezel Project, available through Content Downloader, fills the black bars on 16:9 displays with per-game artwork. RetroAchievements adds trophy-style challenges across supported cores — enable it globally and log in once. And the built-in scraper pulls box art, descriptions, and metadata so your library looks like a library instead of a folder listing. All three are configured in batocera.conf or the ES menus, and none of them require re-downloading the image. For anything core-specific — supported systems, option names, BIOS hashes — the Batocera wiki and the libretro docs remain the authorities.

A Complete Working Configuration

A sane batocera.conf to start from

Here is a complete, commented batocera.conf excerpt that covers the settings most people actually change on a fresh 43.1 install: networking, a changed hostname, RetroAchievements, global bezels, and a couple of quality-of-life toggles. Edit it at /userdata/system/batocera.conf over SSH or via the file share, then reboot for everything to take effect.

# /userdata/system/batocera.conf  --  Batocera 43.1 starting configuration

# ---- Networking ----
wifi.enabled=1
wifi.ssid=YourNetwork
wifi.key=YourWifiPassword
system.hostname=BATOCERA-LOUNGE      # nicer name than the default on your LAN

# ---- Security ----
# Change the root password from the network menu, NOT here in plain text.
# This box is on your network; default credentials are a liability.

# ---- RetroAchievements ----
global.retroachievements=1
global.retroachievements.hardcore=0
global.retroachievements.username=yourname
# token is stored after you log in once through the UI

# ---- Presentation ----
global.bezel=thebezelproject         # fill 16:9 black bars with per-game art
global.smooth=1                      # bilinear smoothing on by default
global.rewind=1                      # enable rewind where cores support it

# ---- Per-system tuning ----
snes.core=snes9x                     # pin a known-good core
nes.shaderset=scanlines              # CRT-ish look for 8-bit only

# ---- Power ----
system.power.switch=PLED             # match your device's power button type

The folders you will actually touch

Everything user-facing lives under /userdata. Learn these paths and you can administer Batocera without ever guessing:

• /userdata/roms/[system] — one folder per system; drop games here.
• /userdata/bios — BIOS files; the BIOS-check menu lists exact hashes.
• /userdata/saves — save files and states, safe across upgrades.
• /userdata/system/batocera.conf — the master configuration file above.
• /userdata/system — back this up; it is small and holds your setup.

The thirty-minute reality check

Put it together and the timeline is honest: a few minutes to download 43.1, five to ten to flash and verify, and the balance for first boot, controller mapping, networking, and copying your first ROMs across. Call it thirty minutes to a working system, and note that this is the last time you download the whole image — from here on it is batocera-upgrade and nothing more. That is the entire point of choosing a versioned, self-updating distribution over a frozen one: you do the download once, and the machine keeps itself current. For the specifics of any given upgrade or the archive of older builds, the official download page and the batocera.linux repository are the two sources worth bookmarking, because they are the two that cannot lie to you.