Batocera Download 2026: v43.1 in 12 Steps, 20 Min

'Batocera download' is one of those searches that looks like it needs a five-line answer and actually hides a dozen decisions: which image, which writing tool, which drive, live or installed, and how to get games in without breaking the law or the boot partition. This is the long version — the one that gets you from an empty USB stick to a working console running the current v43.1 build, with every step explained and every common way to fail flagged before you hit it. It is free, it is open-source, and if you follow the twelve steps in the middle of this guide you will be playing something in about twenty minutes.

Why Batocera, and What v43.1 Really Is

Batocera is a Linux distribution that exists for one reason: to turn a spare PC, a Raspberry Pi, or a handheld into a console that boots straight into a game menu and asks nothing of you afterwards. It is not an app you install on top of Windows. It is the whole operating system, built around EmulationStation as the front-end and a pile of libretro cores and standalone emulators as the back-end. You write it to a USB stick or an SD card, you boot it, and you are looking at a couch-ready grid of systems in under a minute. That is the entire pitch, and after a decade the project has gotten very good at delivering exactly that and nothing extraneous.

Glasswing, in one paragraph

The current line is v43, released on 8 May 2026 under the development credit Glasswing, with the 43.1 point release following on 30 May 2026 to mop up the usual first-week regressions. If a guide tells you v43 shipped in April, it is wrong — the changelog says May, and the changelog is the only source that matters. Glasswing is a genuinely large release: on x86_64 it moved the desktop stack to Wayland with the LabWC compositor, rebuilt the image against the x86-64-v3 microarchitecture baseline, added a new on-screen Batocera Control Center (hotkey + east button by default), and pruned dead weight — the closed-source DraStic DS emulator is gone, Azahar Plus folded back into upstream Azahar, and the legacy Nvidia 340.xx and 390.xx driver branches were dropped. You can read the whole list yourself in the project's Changelog.md; do not take mine or anyone else's summary as gospel when the primary document is public.

'Free' means two things here, and both are true

Batocera costs nothing — there is no license fee, no subscription, no 'pro' tier, no nag screen. It is also free in the sense that actually matters: the source is on GitHub under the batocera-linux organisation, the code is open, and you can build the image yourself if you distrust the binaries. The project's own content sits under a CC-BY-NC-SA license, the software underneath is a stack of GPL and permissively licensed emulators, and the copyright line reads 2016–2026. What Batocera does not ship is copyrighted games or BIOS files, and this is the part the law cares about. The distro is legal; what you copy into it is your problem, and 'I downloaded a No-Intro set' is not a defense anyone has successfully argued. Dump your own carts, or accept the risk knowingly. The Machine does not moralize, but it also does not pretend the line isn't there.

Batocera vs RetroPie vs Recalbox

The three big couch-emulation distros diverge on philosophy. Recalbox is the polished, opinionated, slightly locked-down cousin. RetroPie is the tinkerer's kit — powerful, but as of 2026 it is still frozen at v4.8 from March 2022 with no official x86 image and no first-party Raspberry Pi 5 build, which is a problem when the Pi 5 is the board everyone actually owns. Batocera sits in the middle and, crucially, ships current official images for the Pi 5, for x86_64, and for a long list of handhelds. If you want to boot something today on modern hardware without compiling anything, Batocera is the path of least resistance. If you want maximum control over every package, RetroPie still has an argument. For most people in 2026, that argument lost.

Prerequisites: Hardware and Software Versions

Emulation is the one workload where 'it'll probably run' is a lie you tell yourself right before a PS2 game chugs at 40 fps. Get the prerequisites right and the rest of this tutorial is mechanical. Get them wrong and you will spend an evening blaming Batocera for your CPU's missing instruction set.

Hardware: the real minimums

The floor is 1 GB of RAM, but 2 GB is the realistic minimum and more is genuinely useful once you scrape artwork and run heavier cores. Storage is the number people get wrong: 16 GB is the absolute minimum and 32 GB is the recommended figure — and there is a trap here, because Batocera will refuse to auto-update on a 16 GB drive, since there isn't room to stage the new build. Buy the 32 GB stick; it costs less than the game you're about to emulate. For the actual silicon, an 8-bit and 16-bit library runs on anything; PS1, N64, and Dreamcast want a competent SBC or any modern x86 chip; and PS2, GameCube, Wii, PSP-heavy titles, and 3DS want a real x86_64 machine with a discrete or at least Vega-class integrated GPU. The project explicitly targets cheap mini PCs — the Beelink Mini S12 class of N100 box is the reference point for 'inexpensive but capable', and it will happily run everything short of the current-gen holdouts.

The x86-64-v3 catch nobody mentions

Because Glasswing builds the x86_64 image against the x86-64-v3 microarchitecture level, your CPU needs the instructions that level implies — most importantly AVX2. In practice that means Intel Haswell (2013) or AMD Zen / Excavator or newer. If you are trying to resurrect a Core 2 Duo or a first-gen i5 from 2010, the modern image may simply not boot, and that is not a bug — it is the price of a faster baseline. Check the CPU generation before you blame the flash. If your machine predates 2013, look for an older Batocera release or a legacy build on the download page rather than fighting the current one.

Software you'll need before you start

You need three things: the Batocera image, a writing tool, and a target drive. For the writer, the community standard is balenaEtcher — on Windows the installer is named along the lines of balenaEtcher-Setup-1.xx.xx.exe — because it reads Batocera's compressed .img.gz directly and validates the write afterwards. It is a bloated Electron app and I will not pretend otherwise, but 'it just works with .gz' is worth the 120 MB. Rufus is a leaner Windows alternative; Raspberry Pi Imager is what the Batocera wiki actually nudges you toward for SD cards, and it is the correct choice on a Pi. For the drive, a USB 3.0 stick or a decent A1/A2 microSD of 32 GB or more, plus a card reader if your machine lacks a slot. That's the whole shopping list.

Choosing the Right Image

The single most common way to waste ten minutes is downloading the wrong image and wondering why it won't boot. Batocera publishes a separate build per hardware family, and they are not interchangeable — an Odroid image will not boot a PC, and the PC image will not boot a Pi. The official download page sorts everything by device category, so the job is mostly reading carefully.

x86_64 for PCs, laptops, and mini PCs

If your target is any Intel or AMD desktop, laptop, NUC, or mini PC, you want the x86_64 image. On the download page this is the category that also covers Intel-based Apple machines. This is the build that gets the most testing, the widest emulator support, and the discrete-GPU acceleration you need for the demanding systems. It is roughly 2.5 GB compressed as an .img.gz, which is a couple of minutes on any real connection. Unless you specifically own an ARM board, this is your image, and it is the one the rest of this tutorial assumes.

Raspberry Pi, Odroid, and other SBCs

Single-board computers each get their own image because the bootloaders and GPU stacks differ. Batocera ships current builds for the Raspberry Pi line — including, importantly, a first-party Raspberry Pi 5 image, which is the thing RetroPie still doesn't have — as well as Odroid boards and a rotating cast of other SBCs. Match the image to the exact board revision; a Pi 4 image is not a Pi 5 image. On these, flash to a fast microSD or, better, boot from USB/NVMe where the board supports it, because SD cards are where SBC emulation setups go to die.

Handhelds and beta builds

Batocera has quietly become one of the better handheld options, with device-specific images and clearly labelled beta/experimental ISOs for hardware like the PiBoy DMG — community consensus rates several of these as stable and, on that hardware, preferable to RetroPie. That said, know your device class: the ultra-budget sticks are a different world. A sub-$100 Miyoo-class handheld runs its own firmware, and as we've covered, on those the OnionOS custom firmware still wins — Batocera is aimed at the more capable ARM handhelds and x86 devices, not the cheapest SoCs. Read the download page's handheld section and match the exact model; 'close enough' does not boot.

Downloading and Verifying the Image

There is exactly one place to get Batocera, and it is batocera.org/download. Every 'mirror' you find on a random search result is either the project's own infrastructure or something you should not trust with a block-level disk image. This section is about getting the file quickly and confirming it arrived intact before you overwrite a drive with it.

Direct download, torrent, or official mirror

The download page offers a direct HTTP link and — since v40 introduced official torrent support — a torrent for every image. If the direct link crawls, use the torrent; that is precisely what it is for, and it pulls from the same pool of official seeds. The project also runs mirrors: image and update files live on hosts like mirrors.o2switch.fr/batocera, and the stable update channel is served from updates.batocera.org. You may see Reddit threads bragging about a third-party mirror hitting ~40 MB/s against the official link's ~200 KB/s — tempting, and occasionally true, but a stranger's mirror is a supply-chain risk for a file that becomes your operating system. Use the torrent instead; it is fast and it is signed by arithmetic, not by trust.

Reading the filename

Batocera's filenames encode the architecture, version, and build date, which is useful when you have three downloads in your folder. The pattern looks like this, and you verify integrity in the same breath:

# The x86_64 file you grabbed from batocera.org/download
batocera-x86_64-43-20260530.img.gz      (~2.5 GB compressed)

# Verify integrity before flashing (Linux / macOS)
sha256sum batocera-x86_64-43-20260530.img.gz

# Expected output -- compare this hash against the one on the download page
9f2c8b41d7e0a3f5c6b2...a41b  batocera-x86_64-43-20260530.img.gz

The date on the end is the build stamp, so the 43.1 rebuild carries a later date than the original 43 image even though the marketing version is the same line. Keep the .img.gz as-is — do not decompress it by hand.

Verify before you flash

If the download page lists a checksum, check it, as shown above. A truncated download that still 'looks' complete is the classic cause of a boot that hangs at a black screen, and it costs thirty seconds to rule out. Compare the printed hash against the one published next to the download. If they differ, the file is corrupt or tampered — delete it and pull it again, ideally over the torrent, which verifies each piece as it downloads and cannot hand you a silently broken image.

Flashing Batocera in 12 Steps

This is the part everyone actually came for. Writing the image is a block-level operation — you are not copying a file onto a drive, you are replacing the drive's entire contents with a disk image — which is why the tooling asks for admin rights and why picking the wrong target is catastrophic. Follow the steps in order; the rationale after each one is there so you understand what you're doing rather than cargo-culting it.

The 12-step flash and install

1. Insert a 32 GB (or larger) USB 3.0 stick or A2 microSD. Batocera expands its data partition to fill the drive on first boot, and it won't auto-update on anything under 16 GB — 32 GB is the size that avoids every storage headache later.
2. Launch balenaEtcher (on Windows, the balenaEtcher-Setup-1.xx.xx.exe installer). Etcher reads the compressed .img.gz directly and re-verifies the write, which removes two of the most common ways to end up with a dead card.
3. Click 'Flash from file' and select the downloaded .img.gz. Point it at the compressed file, not an extracted .img — decompressing by hand just adds a step where an archiver can hand you a truncated file.
4. Click 'Select target' and choose the drive by size. Etcher will overwrite whatever you point it at, including your data disk; matching the reported capacity to your USB stick is the one check that stands between you and a wiped SSD.
5. Click 'Flash!' and approve the admin/root prompt. Raw block writes require elevated rights — the prompt is expected, not malware, and denying it just makes the write fail.
6. Wait for the write and the validation pass to finish. Etcher re-reads the card to confirm every byte landed; the couple of extra minutes is exactly the insurance that catches a bad flash before you're standing at a black screen wondering why.
7. Decline Windows' 'You need to format the disk' popup and eject. Windows can't read Batocera's Linux partitions and will offer to 'fix' the drive — accept, and you erase the flash you just made. Eject cleanly instead.
8. Move the drive to the target machine and enter firmware setup (usually F2, F12, DEL, or ESC at power-on). You have to explicitly tell the BIOS/UEFI to consider the USB device; nothing boots until you do.
9. Disable Secure Boot and put the USB/SD first in the boot order. Secure Boot rejects Batocera's bootloader outright, and without a boot-order change the machine walks straight past the stick back into whatever was already installed.
10. Boot Batocera live and let EmulationStation load. Running live first proves the hardware, video output, and controllers all work before you commit anything permanent — if it's going to fail, let it fail here where nothing is at stake.
11. (Optional) Install to an internal drive: open the main menu → SYSTEM SETTINGS → INSTALL BATOCERA ON A NEW DISK, pick the target and architecture, and confirm. Running from USB forever is legitimate, but an internal NVMe is faster, quieter, and frees the port — the installer copies the OS and builds the userdata partition for you.
12. Reboot, remove the USB if you installed internally, and finish the first-run wizard (language, timezone, controller). This first boot expands userdata and writes the initial batocera.conf; do it before you copy hundreds of gigabytes of ROMs so the partition table is settled first.

Raspberry Pi Imager and Rufus

Etcher is the default recommendation, but it is not the only tool. On a Raspberry Pi, the wiki actually points you at Raspberry Pi Imager, which handles SD cards natively and is the more appropriate choice on that platform — select 'Use custom' and feed it the Batocera .img.gz. On Windows, Rufus is a leaner alternative to Etcher if you resent the Electron bloat; it writes the image just as well. What matters is not which tool you pick but that it writes a raw image and verifies it — any of the three does. Avoid 'copy the file to the SD card' file-manager approaches entirely; that is not how a bootable image works.

Why the wiki tells you to skip dd

Linux veterans will reach for dd out of habit. It works — Batocera boots fine from a dd-written card — but the project's documentation explicitly does not recommend it for a reason: dd has no guardrails. One transposed letter in the output device and you have overwritten the wrong disk with no confirmation and no undo. If you use it anyway, identify the target with lsblk first and write to the whole device, not a partition:

# Identify the target device FIRST -- never guess (Linux)
lsblk -o NAME,SIZE,MODEL,TRAN

# Expected output: the 28.9G SanDisk on /dev/sdb is the USB stick
NAME     SIZE MODEL             TRAN
sda    931.5G Samsung SSD 870   sata
sdb     28.9G SanDisk Ultra     usb

# Only if you insist on dd (the wiki explicitly does not recommend it):
zcat batocera-x86_64-43-20260530.img.gz | sudo dd of=/dev/sdb bs=4M status=progress conv=fsync

Notice there is no validation pass — dd writes and exits. Etcher's read-back verification is precisely the safety dd omits, which is why the wiki steers newcomers away from it. The full procedure, tool by tool, is on the install_batocera wiki page.

First Boot: Live vs Internal Install

You have a flashed drive. The next decisions — how to boot it, and whether to run from the stick or commit to an internal disk — determine whether this is a five-minute win or an evening of firmware roulette. None of it is hard; all of it is easy to get subtly wrong.

Booting from USB (UEFI and Legacy)

Power on and hammer the firmware key — F2, F12, DEL, or ESC depending on the vendor — to reach the boot menu or setup. Two settings decide your fate. First, Secure Boot must be off; Batocera's bootloader is not signed for Microsoft's chain and Secure Boot will silently refuse it. Second, the USB or SD device must be first in the boot order, or at minimum selected from the one-time boot menu. Modern machines will boot Batocera in UEFI mode without complaint; if you get nothing, toggle to Legacy/CSM and try again, because a handful of older boards only enumerate USB boot devices that way. Once the firmware cooperates you will see Batocera's boot splash, and from there it is hands-off.

Running live vs installing to an internal SSD

Batocera runs perfectly well straight from the USB stick, indefinitely, and for a lot of people that is the correct answer — it keeps the host machine's existing OS untouched and makes the whole thing portable between computers. The trade-offs are speed and an occupied port. If the target is a dedicated emulation box, install to an internal drive: open the main menu, go to SYSTEM SETTINGS, choose INSTALL BATOCERA ON A NEW DISK, select the destination disk and the architecture, and confirm. The installer lays down the OS and creates the large userdata partition for your games. Do not install onto the same stick you booted from, and be aware the target disk is wiped — this is a clean install, not a dual-boot.

What the first boot actually looks like

The first boot does real work before you see the menu: it grows the data partition to fill the drive, builds the /userdata directory tree, starts the SSH and Samba services, and hands off to EmulationStation. On a fresh flash this takes a little longer than subsequent boots — that is expected, not a hang. Roughly, the sequence looks like this:

# Expected first-boot sequence (abridged, on-screen)
[  OK  ] Started Batocera boot
[  OK  ] Resizing userdata partition to fill /dev/sdb ...
[  OK  ] Building /userdata tree: roms bios saves system music
[  OK  ] Starting SSH and Samba (share -> /userdata)
[  OK  ] Launching EmulationStation

# Confirm the running version over SSH (login: root / linux)
cat /usr/share/batocera/batocera.version
43

When EmulationStation appears, a first-run wizard collects your language, timezone, and a controller mapping. Complete it before you copy anything, because that is the moment Batocera writes the initial batocera.conf and finalises the partition. After that you are looking at the systems grid, which will be nearly empty until you add games — the next section.

Adding ROMs and BIOS Files

An empty Batocera is a very fast way to look at a menu with nothing in it. The distro ships zero games and zero BIOS files — deliberately, because both are copyrighted and shipping them would end the project. Getting content in is straightforward once you understand two rules: ROMs go in per-system folders by exact shortname, and some systems refuse to run without the correct BIOS in the correct place.

The network share method

The path of least resistance is the built-in network share. Batocera exposes its entire /userdata directory as a Samba share named share, reachable from any machine on the same network. On Windows or macOS you browse to the machine over SMB; on Linux you point your file manager at the same host. Drag files straight into the folders. If you prefer a shell, SSH is enabled too — the default login is root / linux — so scp works fine:

# Copy a ROM over SSH from another machine (default login root / linux)
scp SuperMarioWorld.sfc root@BATOCERA.local:/userdata/roms/snes/

# Or browse the network share in your file manager:
#   Windows / macOS : \\BATOCERA\share
#   Linux           : smb://BATOCERA.local/share

Change that SSH password immediately if the box is on a network you do not fully control; 'root / linux' is convenient and also exactly what an attacker tries first.

ROM folders and shortnames

Every system has a short folder name — snes, nes, psx, n64, megadrive, and so on — and a ROM only appears if it sits in the matching folder. Put a SNES game in roms/snes, not in roms, and not in a subfolder you invented. Here is the layout you are aiming for:

# The Samba share 'share' maps to /userdata. Target layout:
/userdata
+-- roms
|   +-- snes/   Super Mario World.sfc
|   +-- nes/    Metroid.nes
|   +-- psx/    Final Fantasy VII (Disc 1).chd
|   +-- n64/    Ocarina of Time.z64
+-- bios
|   +-- scph5501.bin      (PS1 US)
|   +-- gba_bios.bin      (GBA)
+-- system
    +-- batocera.conf

After copying, refresh the library: main menu → GAME SETTINGS → UPDATE GAMELISTS. Batocera's emulators are, under the hood, mostly the same libretro cores you would otherwise wrangle by hand — if you ever want to understand what is actually running each system, our breakdown of RetroArch cores and the 200+ emulators behind them maps the same core names Batocera assigns automatically. The full folder-name reference lives on the wiki's add-games page.

BIOS files and hashes

Some systems — PlayStation, Sega CD, PSP, the DS cores — need a BIOS. These go in /userdata/bios, and the filename and checksum have to be exact; a BIOS that is the wrong region or a bad dump will either be rejected or, worse, cause subtle glitches. Batocera's own MISSING BIOS check (in the main menu) tells you what is absent, but it will not tell you the hash. For that, the canonical reference is the libretro BIOS list, which pairs every required file with its MD5 so you can confirm you have the right one. Match the hash, not just the filename — two files called scph5501.bin can be entirely different dumps.

Common Pitfalls (and Fixes)

Most Batocera 'bugs' are one of a dozen self-inflicted wounds. Here are the ones that fill support forums, grouped by where in the process they bite, with the fix attached.

Download and flash gotchas

• Decompressing the image by hand. Etcher, Rufus, and Raspberry Pi Imager all read .img.gz directly. Extracting it first just introduces a step where an archiver can hand you a truncated .img that flashes fine and boots to a black screen. Leave the .gz alone.
• Flashing the wrong drive. The single most expensive mistake. Etcher shows the target's capacity for a reason — match it to your stick before you click Flash, and unplug other external drives so there is nothing else to pick by accident.
• Letting Windows 'repair' the card. After flashing, Windows sees Linux partitions it cannot read and offers to format them. Every time you accept, you destroy the flash. Decline, and eject the drive cleanly.

Boot and display gotchas

• A pre-2013 CPU meets the v3 image. Glasswing's x86_64 build targets the x86-64-v3 level and needs AVX2 — Haswell or Zen and newer. A 2010 machine may not boot it at all. Use an older Batocera release on genuinely ancient hardware.
• Secure Boot left enabled. If the machine ignores the stick and boots Windows, this is almost always why. Disable Secure Boot in firmware, then fix the boot order.
• Legacy Nvidia GPU, black screen. v43 dropped the 340.xx and 390.xx driver branches. A Fermi- or Kepler-era card that worked on an old Batocera may now need the 470 legacy driver boot option — or an older release.

Games, BIOS, and save gotchas

• ROMs in the wrong folder. Files dropped in roms instead of roms/<system> never appear. Put them in the exact shortname folder and run UPDATE GAMELISTS.
• Missing or mis-hashed BIOS. A system that boots to a black screen or refuses to launch is usually a BIOS problem. Check MISSING BIOS, then verify the file's MD5 against the libretro list.
• Expecting DraStic saves to survive. v43 removed the closed-source DraStic DS emulator; DS now runs on melonDS, and DraStic's save states do not transfer. Back up old saves before upgrading and keep in-game (battery) saves, which are portable.

Troubleshooting Table

When something breaks after setup, it is almost always one of the following. Work top to bottom; the causes are ordered roughly by how often they are the real culprit.

Boot and video

The overwhelming majority of 'it won't boot' reports are Secure Boot or boot order, and the majority of 'it boots to a black screen' reports are GPU drivers. Rule those out first — enter firmware, kill Secure Boot, and if the screen stays black, try the alternate GPU boot option before you assume the flash failed. A genuinely corrupt image announces itself by hanging EmulationStation at the loading screen, which is why the checksum step earlier exists.

Input, audio, and network

Controllers that worked on an older Batocera and died on v43 are collateral from the switch to the mainline Nintendo driver — reconfigure the pad and, if wireless, re-pair it. Silent audio is nearly always the wrong output device: HDMI versus analog is a one-line fix in SOUND SETTINGS or in batocera.conf. Wi-Fi that won't connect is occasionally a missing firmware blob for an exotic chipset, but usually it is a typo in the SSID or key.

Updates and storage

If the updater refuses to run, check the drive size before anything else — the 16 GB floor exists because updates need room to stage, and a 16 GB card simply cannot. The manual upgrade path via boot.tar is the escape hatch, covered next. Slow downloads are a server-load problem, not a you problem: switch to the torrent or a mirror and move on.

Advanced Tips

Once Batocera boots and plays, the interesting work is keeping it current, making it look right, and reaching into it when the menus aren't enough. This is also where the 'knows the lore' part earns its keep.

Manual and offline upgrades

The normal update path is trivial — main menu, UPDATES & DOWNLOADS, START UPDATE — but it depends on a network and enough free space. When you're offline, or when an in-place update fails, the manual boot.tar procedure is the fallback: you fetch the boot archive from a mirror and drop it in place. The stable channel is served from updates.batocera.org; the o2switch host mirrors the same files.

# In-place update from the UI: MAIN MENU -> UPDATES & DOWNLOADS -> START UPDATE

# Or from a shell (login root / linux):
batocera-upgrade

# Manual / offline upgrade: fetch boot.tar.xz from the mirror, then follow
# wiki.batocera.org/upgrade_manually. Stable channel host:
#   https://updates.batocera.org/

The full, version-specific manual procedure is documented on the wiki's manual-upgrade page — follow it rather than improvising, because the boot partition layout changes between major versions. If you would rather skip the theory and just want the fastest possible path from download to playing, our condensed 15-minute Batocera 4.31 install walkthrough covers the same ground in a tighter format.

Overclocks, shaders, and bezels

Batocera exposes per-system overrides for almost everything. Shaders — CRT masks, scanlines, LCD grids — are set globally with global.shaderset or per system, and on a capable GPU a good CRT shader is the difference between 'emulator' and 'looks like the machine it's pretending to be'. Bezels (the artwork framing 4:3 content on a 16:9 screen) are toggled with global.bezel. On SBCs, conservative overclocks are configurable from the menus, but temper expectations: a Raspberry Pi is not going to brute-force PS2 no matter how much voltage you feed it, and if frame-perfect accuracy is the goal, dedicated FPGA hardware like the MiSTer Multisystem is a fundamentally different and more faithful approach than software emulation on any of this.

SSH, scraping, and backups

SSH (root / linux) is your service door for everything the menus don't surface — editing configs, checking logs, running the built-in tools. The wiki's SSH page covers enabling it and connecting from each OS. The built-in scraper pulls box art, metadata, and video snaps into your gamelists and is worth running once your library is in place — it turns the systems grid from a list of filenames into something that looks like a storefront. And back up /userdata, or at least /userdata/system and your saves, before every major upgrade; it is the one directory that holds everything you cannot re-download.

The Complete Working Configuration

Here is the payoff: a representative, working configuration and the layout it assumes. Batocera writes most of these keys for you as you click through the menus, so you rarely edit the file by hand — but seeing the whole thing in one place demystifies what the UI is actually doing, and it is the fastest way to replicate a known-good setup on a second machine.

A working /userdata/system/batocera.conf

Drop this in /userdata/system/batocera.conf and reboot, or use it as a reference for the keys the menus toggle. The authoritative, exhaustive key list is on the Batocera wiki; treat this as a sane starting point, not scripture.

# /userdata/system/batocera.conf -- representative working config (v43.1)
# The menus write these keys for you; the authoritative list lives on the wiki.

## System
system.language=en_US
system.kblayout=us
system.timezone=America/New_York
system.hostname=BATOCERA

## Network / services
wifi.enabled=0
wifi.ssid=
wifi.key=
system.samba.enabled=1
system.ssh.enabled=1

## Audio / video
audio.volume=90
audio.device=
global.videomode=default
global.refresh=auto

## Global emulator defaults
global.smooth=1
global.shaderset=none
global.bezel=none
global.ratio=auto
global.integerscale=0
global.rewind=0
global.autosave=0
global.retroachievements=0

## Per-system overrides
snes.core=snes9x
nes.core=fceumm
n64.core=mupen64plus_next
psx.core=swanstation
nds.core=melonds

## Updates
updates.enabled=1
updates.type=stable

The folder layout you should end up with

After adding games and BIOS, your /userdata tree should mirror the layout from the ROMs section — per-system folders under roms, flat BIOS files under bios, and your configuration and per-system tweaks under system. If a system is missing from EmulationStation, the folder is empty or misnamed; if a game is missing, it is in the wrong folder or the gamelist is stale. Those two rules explain 90% of 'where did my games go' questions.

What to back up, and the last word

Back up /userdata/system (your config), /userdata/saves (your progress), and any scraped media before every major version jump — everything else is re-downloadable, those are not. Beyond that, the maintenance loop is simple: update when a new point release lands, re-scrape when you add a batch of games, and keep the changelog bookmarked so you know what changed before you upgrade. Batocera in 2026 is the rare piece of software that respects your time — it costs nothing, it hides nothing behind an account, and it boots into a game instead of a login screen. Flash it, feed it your own dumps, and get back to the part where you actually play something.