Batocera Download 2026: 43.1 in 12 Steps, 30 Min

Batocera.linux does not install. That is the first thing to understand and the thing most first-timers get wrong. You do not double-click a setup wizard, agree to a license, and watch a progress bar crawl across your Windows partition. You write an image to a card or a drive, you boot from it, and the operating system runs from that media as a self-contained appliance. Your PC's existing disk is never touched unless you explicitly tell it to be. This is the entire point, and it is also why a botched download costs you almost nothing to recover from: you re-flash the card and start over.

As of 13 August 2026 the official download page lists 43.1 as the current version, and the homepage tells new users to "Get Batocera.linux 43.1" in as many words. That is the build this guide targets, start to finish, on real 2026 hardware. The core loop is short — identify your CPU, pick the matching image, download it, verify it, flash it, boot it, feed it content — and it takes about thirty minutes if you do it in the right order. It takes considerably longer if you grab the wrong architecture, skip the checksum, and then spend an hour wondering why a Raspberry Pi image will not boot on a mini-PC. We will do it in the right order.

Why 43.1 Is the Entry Point

43 "Glasswing" and the point release

Batocera ships on a versioned cadence: a numbered major release, followed by point updates that fix what the major release broke. Version 43, carrying the name "Glasswing," was published on 8 May 2026. Three weeks later, on 30 May 2026, 43.1 arrived — the same base system with the sharp edges filed down. Do not let anyone tell you 43.1 is itself "Glasswing"; that name belongs to 43, and 43.1 is the stability patch on top of it. The official changelog records both dates, and the timeline page — last touched on 13 June 2026 and captioned "batocera 43 status (approximative dates)" — frames 43 as the current line with the project's usual disclaimer that the dates are soft.

When the project's own front door and its download index point at the same number, that number is your answer. Do not go hunting for a nightly, a beta, or someone's reupload on a file locker. The signed, dated, official 43.1 image is the one with the fewest surprises, and it is the one the project is actively pushing to newcomers in August 2026.

What "preconfigured" actually means

The headline feature is that Batocera arrives with more than 200 game systems configured out of the box. This is not marketing puffery; it is the reason the distro exists. A bare RetroArch install is a parts bin — you download cores, assign them to content, fight folder structures, edit config files. Batocera does that assignment for you. Every one of those 200-plus systems already has a default emulator, a default core, a controller-mapping scheme, and a folder waiting under /userdata/roms. You supply the ROMs; the plumbing is done.

The catch is that "preconfigured" is not "optimal." The defaults are chosen to boot on the widest possible range of hardware, which makes them conservative by design. Getting the best out of a given system still means overriding a core here and a shader there — which we will get to. But the starting point is genuinely 200-plus systems, live on first boot. That is why "download Batocera" is a reasonable sentence and "download a working PlayStation 2 emulator, then configure it" is a weekend. If you want the parallel story of hand-tuning the emulator layer Batocera hides from you, our companion walkthrough on installing and updating 200 RetroArch cores covers exactly that.

Who this guide is for

This assumes you have a PC, a Raspberry Pi, or a compatible x86 mini-console and a spare storage device you are willing to erase completely. It assumes you can reach a download page and plug in a USB drive. It does not assume you know what "x86-64-v3" means, why a Raspberry Pi 5 image refuses to boot on a Pi 4, or where BIOS files go. Batocera is free, open source, and developed entirely in the open — the whole distribution lives on GitHub if you want to read the source or the changelog yourself. By the end you will have a running 43.1 install, a working controller, and a folder structure ready for content.

Prerequisites: Hardware & Software

Hardware you actually need

Batocera is deliberately undemanding, and the official wiki is refreshingly honest about the floor. For storage, the number that matters is 16 GB minimum, 32 GB recommended for full functionality, and that is not padding. The compressed image is a few gigabytes and expands to roughly 8 GB the instant it is written, so a 16 GB device leaves almost no headroom — and Batocera's own automatic updates will refuse to run on one. Use 32 GB or more and that problem simply never appears.

The wiki pointedly declines to publish a RAM floor, and for good reason: Batocera boots on hardware as slight as a Raspberry Pi Zero 2 W. RAM is almost never what stops you — ambition is. Booting the menu and playing 8- and 16-bit systems asks nothing of any machine built this century. Pushing into sixth-generation hardware — PlayStation 2, GameCube, Wii, the heavier PSP library — asks for a genuinely capable CPU and GPU, and no amount of distro tuning conjures that performance out of a netbook. Match your hardware to your ambitions, not to a spec-sheet minimum.

On the ARM side, the two builds most people want in 2026 are bcm2711 for the Raspberry Pi 4 family and bcm2712 for the Raspberry Pi 5. These are not interchangeable, and people get it wrong because both boards look identical from across the room. The Pi 5 is meaningfully faster and needs its own image; the Pi 4 image will not boot on it, and vice versa. Match the silicon, not the vibe. Dedicated handhelds are their own conversation — if that is your target, weigh the field in our 2026 Retroid Pocket ranking before you commit a card to anything.

The flashing tool

You need exactly one imaging tool. Batocera's wiki points first at Raspberry Pi Imager and USBImager; the widely-known cross-platform option is balenaEtcher; and on Windows, Rufus is the power user's pick. Any of them writes a Batocera image correctly — the difference is ergonomics and platform. Pin your version to something current — Raspberry Pi Imager 1.8.5 or newer, balenaEtcher 1.18 or newer, Rufus 4.x — because older builds occasionally choke on the compressed .img.gz format and will hand you a corrupt card without a word of warning.

• Raspberry Pi Imager — the wiki's first recommendation, the obvious choice for any Pi target, and a perfectly good general-purpose writer on Windows, macOS, and Linux. Decompresses .img.gz natively.
• USBImager — the wiki's other primary pick: tiny, cross-platform, and utterly no-nonsense. Select image, select device, write.
• balenaEtcher — cross-platform and near-impossible to misuse. It verifies the write by default, which makes it slower; that is a feature, not a bug.
• Rufus — Windows-only, fast, and the pick when you want control. Handles gzip images; accept DD Image mode if it asks.

Storage: the part everyone cheaps out on

This is where more installs die than anywhere else. Batocera runs from the media you flash and then stores your ROMs, saves, screenshots, and configuration on that same device. A slow or dishonest card turns a capable emulator into a slideshow, and counterfeit capacity — the ten-dollar "512 GB" card that is really 32 GB with a faked controller — corrupts your library the moment you cross its real limit.

Buy storage you can trust. For a Raspberry Pi, use a genuine A1- or A2-rated microSD card of at least 32 GB from a vendor you recognize; 128 GB or more if you intend to hoard. For an x86 machine, skip the SD card where you can and flash to a USB 3.0 SSD or an internal SATA/NVMe drive — the random-read difference is the single biggest quality-of-life upgrade in the whole process, and it costs nothing but the decision. Whatever you choose, understand that flashing erases it completely. There is no "install alongside." There is only "this device is Batocera's now."

Steps 1–3: Pick the Right Image

Step 1: Identify your architecture

Everything downstream depends on this, so do it first and do it properly. Batocera does not ship one universal image; it ships platform-specific images, each compiled for a particular class of CPU. Download the wrong one and it will either refuse to boot or hang on a black screen, and you will blame the card, the tool, and the distro in that order before you blame the download. The rationale is physical: an image built for a Raspberry Pi's ARM cores contains none of the code an x86 PC needs, and an image built for a modern AMD chip uses instructions an older CPU literally cannot execute.

If you already have a Batocera box, it will tell you its own board name. On any Linux machine, the CPU tells you what it is:

# On an existing Batocera install, ask the system directly:
$ cat /boot/boot/batocera.board
bcm2712

# On any Linux box, check the CPU architecture and features:
$ uname -m
x86_64

$ lscpu | grep -E "Model name|Flags" | head
Model name:  AMD Ryzen 5 5600G with Radeon Graphics
Flags:       ... avx avx2 bmi1 bmi2 fma ...

If uname -m returns x86_64, you are on a 64-bit PC. If the flags include avx2, bmi2, and fma, your CPU supports the x86-64-v3 feature level and can run the optimized build. If you are on a Raspberry Pi you already know the model — and if you do not, it is printed on the board.

Step 2: Map hardware to build name

Batocera's build names are not marketing. They are the actual chip family or microarchitecture level the image was compiled against. Here is the mapping for the targets that matter in 2026:

The two x86 choices deserve a word. Plain x86_64 is the universal donor: it assumes little and runs anywhere with a 64-bit CPU. The x86-64-v3 image — the one the download page flags for the Steam Deck and handheld PCs — is compiled for the newer instruction set on AMD's Zen 3 and later parts and comparable Intel chips, and it can be quicker. Feed it to a CPU that lacks those instructions and it will not run at all. When in doubt, take x86_64. Nobody was ever fired for choosing the compatible image.

Step 3: Read the filename

Batocera encodes everything you need in the filename, and learning to read it is the single most useful skill in this guide. The 2026 pattern is:

batocera-[architecture]-[version]-[date].img.gz

# Real 43.1 images from the official index:
batocera-x86_64-43.1-20260530.img.gz
batocera-zen3-x86-64-v3-43.1-20260529.img.gz
batocera-bcm2711-43.1-20260530.img.gz     # Raspberry Pi 4
batocera-bcm2712-43.1-20260529.img.gz     # Raspberry Pi 5

Four fields, left to right: project name, architecture, version, and build-date stamp. The architecture is the field you verify against Step 2. The version must read 43.1. The date — 20260529 or 20260530 — is simply when that particular image was compiled, and it is normal for different architectures to carry slightly different stamps because they finish building at different times. Do not read anything sinister into a 29 versus a 30. Confirm the architecture, confirm the version, and move on.

Steps 4–5: Download & Verify

Step 4: Direct download vs torrent

Point your browser at the official page — batocera.org/download — select your architecture, and you will be offered two ways to pull the image: a direct HTTP download and a torrent. Both deliver the identical file. The choice is about how your connection behaves, not about what you get.

Take the direct download when your connection is fast and stable and you just want the file now. Take the torrent when the direct mirror is crawling, when your connection drops and you need resumable transfers, or when you would rather spread the load off the project's servers — the official upgrades-and-torrents index publishes a .torrent for exactly this. That index exposes entries like batocera-x86_64-43.1-20260529.img.gz.torrent and batocera-bcm2712-43.1-20260529.img.gz.torrent, one per architecture, each pointing at the same image the HTTP mirror serves. A torrent client that verifies pieces as it downloads also hands you integrity checking for free — a convenient segue into the step nobody should skip.

Step 5: Verify the checksum

Download corruption is silent. A truncated or bit-rotted image does not announce itself; it flashes cleanly, boots halfway, and then hangs on a black screen or a kernel panic — at which point you will burn an hour re-flashing a file that was broken before it ever touched the card. Verifying the checksum takes fifteen seconds and eliminates that entire failure class. Do it every time. Compute the hash of your download and compare it, character for character, to the value the project publishes beside the image.

$ sha256sum batocera-x86_64-43.1-20260530.img.gz
3f2a9c...  batocera-x86_64-43.1-20260530.img.gz

# macOS uses a slightly different command name:
$ shasum -a 256 batocera-x86_64-43.1-20260530.img.gz

On Windows, PowerShell has it built in — no extra software:

PS> Get-FileHash -Algorithm SHA256 .\batocera-x86_64-43.1-20260530.img.gz

Algorithm  Hash                        Path
---------  ----                        ----
SHA256     3F2A9C...                   ...batocera-x86_64-43.1-20260530.img.gz

Expected output: what a clean verify looks like

The expected output is boring, and boring is the goal: the string your machine prints matches the string the project published, exactly. If they match, you have a byte-perfect image and every downstream failure is now someone else's fault, not the download's. If they do not match, delete the file and pull it again — do not flash it, do not "try it anyway," do not file a bug report. A mismatched hash is a corrupt file, full stop. This one habit prevents more wasted evenings than any other step in this guide.

Steps 6–7: Flash the Image

Step 6: Prepare the target media

Before you write anything, be certain which device you are about to erase. This is the step where people flash their external backup drive instead of the SD card and learn a permanent lesson about the word "irreversible." Unplug every storage device you are not writing to. Then plug in the target and note its size and label so you can pick it out of the flasher's device list without ambiguity. A 32 GB card that shows up as 32 GB is your card; the 2 TB drive that shows up as 2 TB is not, and if the flasher is offering you a 2 TB target you have made a mistake — stop and re-check.

You do not need to format or partition the media first. Flashing overwrites the entire device — partition table, boot sector, everything — so any existing filesystem is irrelevant; it is about to cease to exist. Batocera writes its own layout (a read-only boot/system partition and a userdata partition) during the write and expands the userdata partition to fill the device on first boot. Pre-formatting is wasted effort at best and confusion at worst.

Step 7: Write the image

The mechanics are the same across every tool: select the .img.gz, select the target device, write. You do not need to decompress the gzip first — every current version of these writers reads .img.gz directly and expands it on the fly.

1. Raspberry Pi Imager: Choose OS → Use custom → select the .img.gz. Choose Storage → select your card. Write. Ignore the prompt about OS customization settings; those are for Raspberry Pi OS and do nothing here.
2. balenaEtcher: Flash from file → select the image. Select target. Flash. Let the verification pass run to the end; that pass is the entire reason to use Etcher.
3. Rufus: Select device → SELECT the .img.gz → leave the partition scheme at whatever the image dictates → START. If Rufus asks about DD Image mode, accept it.

After the write: sanity checks

A write to a decent USB 3.0 SSD finishes in a minute or two; a mid-range microSD card takes several, plus verification time. When the tool reports success — and, if you used Etcher, when verification passes — you have a bootable Batocera device. If your writer offered to set a hostname or credentials at flash time, ignore those fields; they are Raspberry Pi OS features, and Batocera manages its own identity. We will set hostname, Wi-Fi, and the rest properly from inside the running system in the configuration section. Do not eject by yanking the cable mid-write; wait for the tool to say it is safe.

Steps 8–10: First Boot & Setup

Step 8: Boot order and firmware settings

A flashed device does nothing until the machine agrees to boot from it. On a Raspberry Pi this is automatic — insert the card, apply power, and it boots. On an x86 PC you must tell the firmware to boot from your USB SSD or card reader ahead of the internal disk, and this is where a surprising number of first attempts quietly stall.

Enter firmware setup — usually Del, F2, F10, or Esc during POST, depending on the board — and either move the Batocera device to the top of the boot order or invoke the one-time boot menu (often F12 or F8) and pick it directly. Two settings save grief: disable Secure Boot, because Batocera's bootloader is not signed for Microsoft's chain of trust, and prefer a UEFI boot entry over a legacy/CSM one on modern hardware. Get those right and the machine hands control to Batocera; get them wrong and it silently falls through to Windows as if nothing happened.

Step 9: Expand and configure

The first boot is slower than every subsequent one, by design. On its maiden run Batocera expands the userdata partition to fill your entire device, generates its configuration, and builds its game-list databases. Let it finish. Do not pull the power because the screen sat still for twenty seconds — interrupting the expansion is a reliable way to corrupt the filesystem you just wrote, and then you are back at Step 6. Patience here is not optional; it is the difference between a working install and a re-flash.

When EmulationStation — the menu you are looking at — settles onto its main carousel, the userdata partition is the full size of your device, every default system folder exists under /userdata/roms, and the system is idling, waiting for input. It is, technically, finished. It just has no games yet and possibly no working controller.

Step 10: Map your controller

Press a button on your gamepad. If Batocera recognizes it — and it recognizes most Xbox, PlayStation, and 8BitDo pads out of the box — you are already driving the menu. If it does not, hold any button for a few seconds and the controller-configuration wizard appears, walking you through each input in turn. The reason to do this now, before you add a single ROM, is that Batocera maps once and translates that mapping into every core's expected layout automatically: a controller that works in the menu works in the emulators. Configure the pad, confirm you can navigate, and only then move on to content. A menu you cannot steer is a museum exhibit.

Step 11: Add ROMs & BIOS

Where ROMs live

Every one of Batocera's 200-plus systems has a folder, and the folders live under one predictable path. A ROM is "installed" simply by being the right file in the right folder — there is no import step and no library you must register with. Drop the file, refresh the gamelist, and it appears.

/userdata/roms/snes/          # Super Nintendo
/userdata/roms/megadrive/     # Sega Genesis / Mega Drive
/userdata/roms/psx/           # Sony PlayStation
/userdata/roms/n64/           # Nintendo 64
/userdata/roms/gba/           # Game Boy Advance
/userdata/bios/               # BIOS/firmware go HERE, never in a roms folder

The folder names are the system's short code, not its marketing name — megadrive, not "Sega Genesis"; psx, not "PlayStation." If you are unsure which formats a system accepts, every /userdata/roms/<system> folder contains a _info.txt that lists the extensions that emulator will load, and the wiki documents every folder name besides. When in doubt, read the _info.txt in the folder itself.

The network share method

You do not need to shuttle the card back to your PC every time you add a game. Batocera exposes its userdata over the network as a standard Windows/SMB share the moment it boots, and copying files over the wire is the sane way to manage a growing library:

# Windows Explorer / macOS Finder:
\\BATOCERA\share

# Linux (or macOS "Connect to Server"):
smb://BATOCERA.local/share

# By IP if name resolution is being difficult:
\\192.168.1.50\share

Inside that share you will find roms, bios, saves, and the rest of the userdata tree, editable in place. Copy ROMs into the matching roms subfolder, then refresh: from the frontend, open START → GAME SETTINGS and run UPDATE GAMELISTS (or simply restart EmulationStation), and the new titles populate. The same share is how you will handle the next, thornier topic. If your real interest is a curated handheld library rather than a warehouse, the discipline of separating a real game list from a bloated dump applies here just as much as it does on a Miyoo.

BIOS files and the legality question

Some systems will not run without a BIOS or firmware dump — the original PlayStation, the PSP, many arcade platforms — because the emulator needs the actual copyrighted boot ROM the hardware shipped with. Batocera does not and legally cannot include these. They go in /userdata/bios, and the built-in BIOS checker will tell you precisely which files are missing and what their checksums should be. The libretro BIOS reference lists the exact filenames and hashes the cores expect. That is the plumbing.

The law is the part the distro leaves to you — deadpan and unhelpful, because it has to be. Batocera ships with zero games and zero BIOS files; it is an empty appliance, and that emptiness is not an oversight. Dumping the BIOS and cartridges from hardware you own is one legal conversation; downloading either from a stranger is a different and considerably worse one. The Machine's position is the boring, correct one: the distro is legal, the emulators are legal, and what you feed them is entirely, exclusively, your jurisdiction's problem. Own the hardware, own the copies, keep the receipts.

Step 12: Update Batocera

The GUI path

Once 43.1 is running you may never need the command line, because the frontend updates itself. Open the main menu and navigate to UPDATES & DOWNLOADS → START UPDATE. Batocera checks the official mirrors, tells you whether a newer build in your line is available, and — with your consent — downloads and applies it, preserving your userdata across the upgrade. Reboot when it finishes and you are current.

The reason to prefer the GUI is that it cannot pick the wrong architecture. It already knows what hardware it is running on, so it only ever offers images built for that platform. And remember the storage math from the prerequisites: the auto-updater needs meaningfully more than 16 GB of space to stage a new build, which is the practical reason the wiki recommends 32 GB. The manual method, by contrast, trusts you to get the URL right — more power, and correspondingly more rope.

The SSH path: batocera-upgrade

For anyone who prefers a terminal, Batocera runs an SSH server, and upgrades reduce to a single command. Connect with the default credentials (user root, password linux, assuming you have not changed them) and run:

# Update to the latest build in your current line:
batocera-upgrade

# Pull the latest x86_64 build straight from a mirror:
batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/last

# Pin a specific/older version (example: roll back to v36):
batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/36/

Bare batocera-upgrade updates within your current line. Supplying a build-folder URL — the wiki uses mirrors.o2switch.fr as its worked example — pins the operation to exactly the version living at that path, which is how you jump lines deliberately, roll back, or point at a mirror closer to you. The full command syntax lives on the wiki's upgrade documentation; when the exact form matters, that page is the source of truth.

Point releases vs full version jumps

Mind the difference in what you are updating to. Going from 43 to 43.1 is a point release: same base, incremental fixes, low risk, apply it without ceremony. Jumping a whole major version — 42 to 43, say — is a larger change, and while Batocera's userdata is designed to survive it, a full-version jump is the one moment where backing up your saves and configuration first is not paranoia but hygiene. The read-only-root design (more on that shortly) is what makes both operations as safe as they are: your data lives on a separate partition that the upgrade does not touch.

Five Pitfalls to Avoid

Image and hardware mismatches

Pitfall 1 — the wrong architecture. The most common failure by far is an image that does not match the CPU: a bcm2712 Pi 5 image on a Pi 4, an x86-64-v3 image on an older Intel chip that lacks the instruction set, an ARM image on a PC. The symptom is a device that flashes perfectly and then does nothing — no boot, or a black screen. The fix is upstream: re-read Step 2, confirm your architecture (or run cat /boot/boot/batocera.board on a working install), and re-download. No configuration rescues a wrong-architecture image; only the right image does.

Pitfall 2 — the unverified download. Skipping the checksum in Step 5 is a bet you will occasionally lose, and when you lose it the corruption disguises itself as every other problem. A truncated .img.gz flashes without error and dies at boot, sending you off to blame your card and your flasher. The fix is never to skip the hash. Fifteen seconds up front saves an hour of misdirected debugging.

Storage and filesystem mistakes

Pitfall 3 — undersized or dishonest storage. Two failures share one fix. The 16 GB card that fills up and breaks auto-updates, and the fake-capacity card that silently corrupts your library, are both solved by buying genuine, appropriately sized storage — 32 GB or more, A1/A2-rated, from a vendor you trust. If a library starts corrupting itself for no reason, suspect the card before the software. Batocera cannot outrun a lying flash controller.

Pitfall 4 — pulling the plug during first-boot expansion. The first boot expands the userdata partition, and interrupting it corrupts the filesystem. Impatience here costs you the entire flash. The fix is discipline: on first boot, wait. If the screen is still, it is working — give it a full minute before you even entertain the idea that something is wrong.

Configuration and content traps

Pitfall 5 — the missing BIOS. A system that lists games which then refuse to launch, or that greets you with an error about a missing file, is almost always a BIOS problem, not an emulator bug. The fix is the built-in BIOS checker: it names the exact files and checksums required, and you place them in /userdata/bios. And the bonus sixth trap that rides along with it: putting BIOS files in the ROM folders instead of the BIOS folder. They go in /userdata/bios, every time, regardless of which system needs them — never in /userdata/roms.

Notice that two of these five — wrong architecture and unverified download — happen before the system ever boots. That is precisely why the first half of this guide spends so long getting the image right. An ounce of prevention at the download page is worth an evening of forum-trawling later.

Troubleshooting Table

How to read this table

The failures below cover the overwhelming majority of first-install support threads. Read the symptom, apply the fix, and resist the urge to re-flash before you have ruled out the cheap causes — most of these are configuration or hardware, not a bad image. Re-flashing is the last resort, not the first.

When to reach for the console

Ninety percent of that table is solved from inside EmulationStation without ever seeing a shell. The exceptions — a stalled update, a share that will not resolve, a BIOS checksum you need to inspect — are where SSH earns its keep. Connect as root, and the full Linux userland sits right there underneath the friendly menu. That is the quiet advantage of Batocera being an actual Linux distribution rather than a locked appliance: when the GUI runs out of answers, the operating system does not.

Advanced Tips

Overlays and why the root is read-only

Batocera's root filesystem is read-only by design — it is what makes the system nearly impossible to brick and trivial to reset. Everything you change persists in the userdata partition as an overlay rather than by mutating the base image. The practical upshot is that your entire configuration is portable: back up the userdata partition and you have backed up your whole install, settings and saves and all, independent of the base version. It also means the way to make a system-level change stick is almost never to edit a file on the read-only root; it is to set the corresponding key in batocera.conf, which lives in userdata and survives every upgrade.

Running from an internal SSD

If you have committed a machine to Batocera, stop running it off a USB stick. The clean way is the built-in installer: boot from your flashed drive, then go to SYSTEM SETTINGS → INSTALL BATOCERA ON A NEW DISK and let it copy itself onto an internal SATA or NVMe drive. The payoff is dramatically faster load times, quicker gamelist parsing, and headroom for the emulators that stream assets from disk. Because the root is read-only, an SSD install is no more fragile than a card install — it is simply faster. For a machine that lives under the TV, it is the correct choice, and it frees the USB port you were sacrificing.

Per-system overrides, shaders, and decorations

The 200-plus preconfigured systems use conservative, boot-everywhere defaults, and the point of the advanced menus is to override them where your hardware allows better. You can pin a specific emulator or core per system — or per individual game — from the in-menu options: a heavier, more accurate core for the titles that need it, a lighter one for the systems that do not. Shaders (CRT emulation, scanlines, LCD grids) and bezel "decorations" toggle the same way. The discipline is to change one thing at a time: override, test, keep or revert. Batocera makes overrides cheap precisely so you can afford to experiment, and the layering rules — per-game beats per-system, which beats global — mean nothing you set locally ever contaminates the global configuration.

Complete Working Config

A sane batocera.conf

Everything the GUI toggles ultimately writes keys to a single file, /userdata/system/batocera.conf. You can edit it directly over SSH or through the network share, and once you know the keys it is often faster than clicking through menus. Here is a complete, conservative starting configuration for an x86_64 install — sensible audio, Wi-Fi, SSH left reachable, and a few quality-of-life defaults. Adjust the obvious values to your setup:

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

## --- System / network ---
system.hostname=BATOCERA
wifi.enabled=1
wifi.ssid=YOUR_NETWORK_NAME
wifi.key=YOUR_WIFI_PASSWORD
system.ssh.enabled=1

## --- Language / region ---
system.language=en_US
system.kblayout=us
system.timezone=America/New_York

## --- Video / global emulator defaults ---
global.videomode=default
global.bezel=default
global.ratio=auto
global.smooth=1
global.rewind=1
global.autosave=0
global.shaderset=none
global.integerscale=0
global.showFPS=0

## --- Audio ---
audio.volume=90
audio.device=auto

## --- Per-system override example ---
## Force the accurate hardware PS1 core only where you want it:
psx.core=mednafen_psx_hw
psx.videomode=default

What each line does

The system keys set identity and access: hostname (what you type into \\BATOCERA), Wi-Fi credentials, and the SSH toggle that keeps the terminal reachable. The global keys are defaults inherited by every system unless a per-system key overrides them — global.smooth controls bilinear filtering, global.rewind enables the rewind buffer, global.autosave governs automatic save states. The block at the bottom shows the override pattern: prefix a key with a system's short name (psx.core, snes.ratio, and so on) and it applies to that system alone, beating the global default. That single mechanism — global keys, overridden by system keys, overridden in turn by per-game settings from the menu — is the entire configuration model. The wiki's batocera.conf syntax page documents every available key if you want to go deeper.

Backing it up

Before you change anything substantial, copy this file. It is the highest-value, lowest-effort insurance in the whole setup: batocera.conf plus your saves and bios folders is, functionally, your entire install. Pull them over the network share to your PC, or snapshot them over SSH to a USB drive:

# Snapshot config + saves + bios to a mounted USB drive:
cp /userdata/system/batocera.conf /userdata/system/batocera.conf.bak
tar czf /media/usb/batocera-backup.tar.gz \
    /userdata/system/batocera.conf \
    /userdata/saves \
    /userdata/bios

That is the whole loop: pick the image that matches your silicon, verify it, flash it, boot it, feed it content you are entitled to, and keep a copy of the small handful of files that make it yours. Thirty minutes done in the right order buys you a machine that plays 200-plus systems and asks nothing further. Done in the wrong order, you will meet every pitfall above personally. The instructions are the same either way; only the outcome differs.