Batocera Download 2026: 43.1 in 12 Steps, 30 Min

There is a particular species of tutorial that treats “download Batocera” as a single verb, points you at a homepage, and wishes you luck. This is not that one. Downloading Batocera 43.1 — the current stable build, published 30 May 2026 — is genuinely a thirty-minute affair start to finish, but roughly half the people who get it wrong get it wrong before the download even begins: they grab an image built for the wrong CPU architecture, they trust a mirror that isn't the project's, or they skip the one checksum that would have told them their SD card was quietly lying about its capacity.

Batocera.linux is an open-source, completely free retro-gaming distribution. You copy it to a USB stick or an SD card, you boot a computer or a nano-computer from it, and that machine becomes a console that arrives with more than 200 game systems pre-configured out of the box. There is no installer wizard nagging you about a Microsoft account, no “free trial,” no analytics dashboard shipped in the boot partition. The catch — and there is always a catch — is that “free and simple” is not a synonym for “impossible to botch.” This guide is the botch-proofing.

We will do it in twelve numbered steps, each with the reason it exists, because a step you understand is a step you can debug at 1 a.m. when the screen stays black. Along the way: the only download URL you should type, the x86_64-versus-ARM distinction that eats newcomers alive, checksum verification the way the project actually publishes it (MD5, not the SHA-256 your instincts expect), and a complete, annotated batocera.conf at the end that you can paste and forget. If you only want the abridged version, our 12-step Batocera 43.1 quickstart is the same road at highway speed; this is the road with the potholes marked.

What Batocera 43.1 Actually Is

Before you download anything, know what the number on the box means, because the version you fetch is the difference between a clean afternoon and a reflash.

The version number that matters

As of this writing the official download page lists Current version: 43.1, and the page itself was last touched on 13 August 2026. The main site — which still headlines “Get Batocera.linux 43.1” — was last updated on 1 August 2026. The point release landed on 30 May 2026 per the project's own changelog, arriving barely three weeks after Batocera 43 “Glasswing” shipped on 8 May 2026. A hotfix that fast is a tell: 43.0 went out with a pair of collateral regressions — partition-recognition and database quirks — and rather than make everyone wait a season for version 44, the maintainers cut 43.1 to clean them up. That is precisely the point release you want on your card. Do not go spelunking for 43.0; it exists only as a footnote and a lesson.

“Free” is not a marketing euphemism

When a company says “free” in 2026 it usually means “free until we've onboarded your payment method.” Batocera means the other thing. It is open source and completely free — you can copy it to a USB stick or an SD card and turn a computer or a nano-computer into a game console without an account, a subscription, or a phone-home. The project itself maintains both the main site and the download page, which is why those two URLs are the only canonical sources worth citing for “how to download Batocera.” Everything else — the aggregator blogs, the SEO farms with the suspiciously round “12 steps” headlines — is downstream of what batocera.org and the public changelog already tell you for free. Read the primary source; it is shorter and it is correct.

The butterfly release train

Batocera names its major releases after butterflies, and once you notice the pattern the roadmap reads like a lepidopterist's field notebook. The recent lineage: 41 “Golden-rayed Blue” (6 January 2025), 42 “Papilio Ulysses” (12 October 2025), 43 “Glasswing” (8 May 2026), the 43.1 hotfix (30 May 2026), with 44 “Malachite” already stubbed in the changelog as the next stable. The naming isn't only whimsy — the project's rolling beta channel is literally called butterfly, which matters later when we set an update branch. For period colour: a widely-circulated community post from 9 January 2025 announced version 41 alongside the torrent filename batocera-x86_64-41-20250106.img.gz, which is worth reading only as a fossil of the exact filename grammar you'll decode in Step 3. The naming scheme is stable; the version you download should be the newest butterfly that has stopped moving, which today is 43.1.

Prerequisites: Hardware & Software

Gather these before you open the download page. Every item here prevents a specific failure mode further down, and skipping one is how a thirty-minute job becomes a Saturday.

Hardware you actually need

• A target machine. Either a 64-bit x86_64 PC/mini-PC (anything that boots Windows 10/11 will boot Batocera), or a supported ARM single-board computer — Raspberry Pi 4/400, Pi 5, Odroid, RK3588-class boards, and a long tail of handhelds. The download page enumerates images from the Pi Zero 2 W up through the Pi 5B, Odroid, Orange Pi, Rockchip, Khadas, and the Steam Deck.
• Removable media. A USB stick or SD card, 16 GB minimum in practice, ideally 32 GB+ and genuinely rated Class 10 / A1 or better. Batocera's data partition auto-expands to fill the drive, so bigger is strictly better for a ROM library.
• RAM and storage on the target. 2 GB RAM is a functional floor; 4 GB+ makes the menus and heavier cores comfortable. You can run entirely from the USB/SD, or install to an internal SSD later.
• A card reader that you trust. A flaky USB reader will fail the flash verification and you'll blame the image.

If, reading this, you conclude you'd rather buy a device with the emulation already tuned than assemble one, that is a legitimate position — our 2026 Retroid Pocket ranking covers the ARM handhelds that ship ready to play, several of which can also run a Batocera ARM image if you insist on both worlds.

Software and versions

• A flashing tool. The project recommends balenaEtcher (latest 1.19.x line) or Rufus (4.x, Windows-only). Both write compressed .img.gz images directly — you do not decompress first.
• A modern browser to reach batocera.org/download, plus enough disk to hold a multi-gigabyte image.
• Optional but recommended: an SSH client. Built into macOS and Linux; on Windows use the built-in OpenSSH or a terminal of your choice. You'll want it for upgrades and pinning.

A controller and a reality check

Batocera will happily drive an Xbox pad, a DualSense, or an 8BitDo controller over USB or Bluetooth, and it maps them in a guided menu on first boot. Have one ready; a keyboard works for setup but is miserable for a launcher built around D-pads. The other reality check is legal, and the deadpan version is this: Batocera ships zero copyrighted games. The distribution is the console; the ROMs and BIOS files are your responsibility, and the lawful path is dumping media you own. The built-in Store distributes freely licensed content only. What you copy into /userdata/roms is between you and the relevant rightsholders, and “I found it on a torrent” has never once been a defense.

Steps 1–3: Pick the Right Architecture

The single most consequential decision happens before you download a byte. Get the architecture right and everything after it is mechanical; get it wrong and you'll flash a perfectly good image that produces a perfectly black screen.

Step 1 — Identify your target hardware

Rationale: Batocera is not one image with a compatibility layer; it is a family of architecture-specific builds, each compiled for a particular CPU. The image is welded to the silicon. So the first move is to name your target exactly: “a 2019 Intel NUC” resolves to x86_64; “a Raspberry Pi 5” resolves to the Pi 5 build; “a Steam Deck” resolves — perhaps counter-intuitively — back to x86_64, because the Deck is an AMD x86 machine. Write down the actual board or CPU. Guessing here is how ARM images end up on PCs.

Step 2 — Choose x86_64 or an ARM build

Rationale: For PCs and mini-PCs, you want x86_64. That build targets the overwhelming majority of desktops, laptops, and mini-PCs, and it is the one the install guides converge on for a reason. ARM images — the Raspberry Pi and RK3588-class builds — are a different instruction set entirely and are not interchangeable with PC builds. This is the rule that saves you: an x86_64 image will never boot a Pi, and a Pi image will never boot your PC, no matter how healthy the flash. If your machine runs Windows or a desktop Linux today, it is x86_64. If it is a Pi, a handheld, or a hobbyist SBC, it is ARM — pick the exact board's image from the list, not a generic “ARM” file.

Step 3 — Decode the image filename

Rationale: Batocera's filenames are self-documenting once you can read them, and reading them is your last checkpoint before download. The grammar is batocera-[architecture]-[version]-[date].img.gz. Parse each field and you can confirm at a glance that you're about to fetch the right thing:

batocera-x86_64-43.1-20260530.img.gz    # PCs, mini-PCs, most laptops, Steam Deck
batocera-bcm2712-43.1-20260530.img.gz   # Raspberry Pi 5
batocera-bcm2711-43.1-20260530.img.gz   # Raspberry Pi 4 / 400
batocera-rk3588-43.1-20260530.img.gz    # RK3588-class ARM SBCs and handhelds

# Pattern, straight from the download page:
#   batocera-[architecture]-[version]-[date].img.gz
#   architecture -> x86_64 (PC) is NOT the same as any bcm/rk (ARM)

The confirmed PC filename for this release is batocera-x86_64-43.1-20260530.img.gz — architecture x86_64, version 43.1, build date 20260530, which matches the changelog to the day. The ARM examples above are illustrative of the naming; always take the exact architecture string from the download page's own list rather than typing one from memory. If the field after batocera- doesn't match the machine you wrote down in Step 1, stop. You found the wrong file.

Steps 4–6: Download, Torrent, or Mirror

Now, and only now, do you fetch bytes. Three steps: go to the one correct place, choose your transport, and grab the checksum in the same breath so you don't have to hunt for it later.

Step 4 — Open batocera.org/download

Rationale: There is exactly one canonical URL — batocera.org/download — and it is maintained by the Batocera.linux project itself. Type it; do not arrive via a search result that might be an ad or an SEO clone. The page presents the current 43.1 images per architecture, each with a direct download, a torrent, and a checksum. Treat any site that offers you a “Batocera installer .exe,” a “setup bundle,” or a login wall as hostile — the real distribution is a raw disk image and nothing else. This is the whole reason the project's own site and download page are the primary sources to cite: everything you need is there, first-party, unbundled.

Step 5 — Pick direct download or torrent

Rationale: The image is multiple gigabytes, and the page gives you two honest ways to move it. The direct download is the path of least resistance and the right default. The torrent exists precisely because large images distribute better peer-to-peer when seeds are healthy — it is an official option on the download page, not a shady alternative, and it's genuinely faster on a congested connection or a distant continent. Both land you at an identical file; the transport is a preference, not a compromise. If a torrent stalls near completion for lack of seeds, fall back to the direct link on the same page and move on.

Step 6 — Copy the MD5 checksum now

Rationale: The download page publishes an MD5 checksum next to each image. Copy it now, while you're already looking at it, into a scratch note. The counter-intuitive detail worth internalising: Batocera publishes MD5, not the SHA-256 that modern muscle-memory reaches for. Ask your verification tool for the wrong algorithm and you'll get a hash that “doesn't match” a perfectly good download and waste an hour chasing a ghost. Grab the MD5 string verbatim. Step 7 is where it earns its keep.

Steps 7–9: Verify the Checksum & Flash

This is the section people skip and then regret. Verification takes ninety seconds and catches the failure mode — silent corruption or a fake-capacity card — that otherwise surfaces as an inexplicable black screen you'll debug for an hour.

Step 7 — Verify the checksum locally

Rationale: A download can truncate, a card reader can flip bits, and a counterfeit “64 GB” card can be a real 8 GB card wearing a costume. Computing the image's MD5 and comparing it to the published value proves the bytes on your disk are the bytes the project shipped. Run the command for your OS:

# Linux
md5sum batocera-x86_64-43.1-20260530.img.gz

# macOS
md5 batocera-x86_64-43.1-20260530.img.gz

# Windows (PowerShell) - Batocera publishes MD5, so ask for MD5
Get-FileHash -Algorithm MD5 .\batocera-x86_64-43.1-20260530.img.gz

Expected output looks like this — one hex string, then the filename:

d41d8cd98f00b204e9800998ecf8427e  batocera-x86_64-43.1-20260530.img.gz
#        ^ illustrative only - your hash will differ.
#          It MUST match the MD5 shown next to the file on
#          batocera.org/download, character for character.

If the two strings match, the image is intact — proceed. If they differ by even one character, re-download (ideally via the other transport from Step 5) and verify again before you flash anything. Never flash a mismatched image “just to see”; you're only teaching yourself to distrust a step that was telling the truth.

Step 8 — Flash with balenaEtcher or Rufus

Rationale: These two tools write compressed .img.gz images to removable media correctly, including the partition table, and they refuse to target your system disk by default — which is the guardrail that stops the classic “I flashed my C: drive” catastrophe. In balenaEtcher: select the .img.gz directly (no manual decompression), select the USB/SD, hit Flash, and let it verify. In Rufus on Windows: select the device, select the image, keep the defaults, Start. Either tool will re-read the card afterward to confirm the write. If Etcher reports “Validation failed” or Rufus errors in the final stretch, that is almost always the card, not the image — you already proved the image is good in Step 7. Swap the card or the reader and try again.

Step 9 — The dd path for Linux users

Rationale: If you live in a terminal, dd is the same operation without the GUI — faster for some, and scriptable. The danger is that dd has no guardrails: it writes wherever you point it, cheerfully, including your root disk. So you identify the target first, twice, and only then write to the whole disk (e.g. /dev/sdX), never a partition (/dev/sdX1):

# 1) Find the target disk. Note its SIZE so you do not nuke the wrong one.
lsblk

# 2) Write it. Replace /dev/sdX with the WHOLE disk (sdX), never a partition (sdX1).
gunzip -c batocera-x86_64-43.1-20260530.img.gz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync

# 3) Flush caches before you pull the stick.
sync

The gunzip -c ... | dd pipe decompresses on the fly, so you never store the raw .img. status=progress gives you a live byte count; conv=fsync and the trailing sync guarantee the write is actually on the card before you remove it. If you're not certain which device is your target, stop and re-run lsblk — this is the one command in the entire guide that can ruin your day, and it deserves the paranoia.

Steps 10–12: First Boot, ROMs & Config

The card is flashed. The last three steps turn a disk image into a console: boot it, teach it your controller and network, and feed it games. This is also where Batocera's design — a self-expanding data partition and a single config file — starts paying you back.

Step 10 — First boot and partition auto-expand

Rationale: Insert the media into the target machine and boot from it. On a PC that means entering the boot menu (commonly F12, F11, or Esc, depending on the board) and selecting the USB/SD; you may need to disable Secure Boot or toggle UEFI/Legacy in firmware. On first boot Batocera automatically expands its userdata partition to fill the remaining space on the drive, which is why a 128 GB card gives you 128 GB of ROM room without any manual partitioning. Let this finish — the first boot is a little slower than subsequent ones for exactly this reason. When EmulationStation's menu appears, the install is live and running entirely from your card.

Step 11 — Configure controller, Wi-Fi, and the share

Rationale: Batocera can't read your mind about input or network, and both are guided. Plug a controller in over USB and Batocera prompts you to map it button by button; Bluetooth pads pair from the Controllers menu. For networking, Ethernet needs nothing, but Wi-Fi wants an SSID and key entered in Network settings — do this now, because the Store and updates need connectivity. Setting the network up also lights up Batocera's SMB share: from another machine on the LAN you can browse to \\BATOCERA (or the box's IP) and drop files straight into the ROM folders over the wire, which beats shuttling the card back and forth. Default SSH login, for later: user root, password linux — change it once you're in.

Step 12 — Add ROMs and BIOS to /userdata

Rationale: Batocera keeps your data — ROMs, BIOS, saves, and config — on the userdata partition, cleanly separated from the OS, so that upgrades never touch your library. The layout is predictable: one folder per system under /userdata/roms, BIOS files under /userdata/bios, and the single config file under /userdata/system. Copy games into the folder that matches the platform, then refresh the game lists (or reboot) and they appear:

/userdata
├── roms
│   ├── snes         # Super Nintendo ROMs go here
│   ├── nes
│   ├── megadrive
│   ├── psx
│   └── ...          # 200+ system folders, one per platform
├── bios             # BIOS files (psx, saturn, dc, ...)
├── saves            # save files and save states
├── music            # background music for the menu
└── system
    └── batocera.conf # the single file that controls the whole install

That's the twelve steps. From a correctly-identified architecture to a booted, playable console, the whole path is mechanical once you refuse to skip verification. Everything below is about doing it well rather than merely doing it.

The Store & 200+ Systems

Two features do most of the work of making Batocera feel finished out of the box: the enormous roster of pre-configured systems, and the built-in Store that fills in the cosmetic and legal-content gaps.

200+ systems, pre-configured

Batocera v43 ships with more than 200 game systems pre-configured out of the box. That number is the product differentiator and it is not marketing rounding — it spans the obvious (NES, SNES, Genesis, PlayStation) through the obscure (pinball engines, fantasy consoles, home computers with tape-loading quirks) with sane default emulators already selected for each. You are not assembling a system from cores; you're pruning one that already boots everything. In practice this means the folder tree you saw in Step 12 already has a home for almost any platform you own media for — you drop files in, and Batocera has an opinion about how to run them before you do.

The Store, since Batocera 5.27

Since Batocera 5.27, the distribution has included an online “store” — a content downloader for freely distributed ROMs, bezels, music themes, and other enhancements, built on the pacman package manager for clean installs and removals. It's where you pull decorative bezels (including the community's Bezel Project presets), swap the EmulationStation theme, or add legally-free game content without leaving the couch. Downloads run in the background, so you can keep playing while a theme installs. The official content-downloader documentation is the reference here, and it's worth skimming before you go decorating — the Store is the sanctioned way to get bezels and themes, as opposed to hand-copying files and hoping the paths line up.

Cores versus standalone emulators

Under the menu, Batocera runs a mix of RetroArch/libretro cores and standalone emulators, choosing per system. That's why the same launcher can offer rewind and shaders on a SNES core and then hand a demanding platform off to a purpose-built standalone emulator — different tools, one consistent front-end. If you want to understand what's actually executing when you hit a game, the libretro documentation is the canonical reference, and our own breakdown of how RetroArch cores work in 2026 maps the core-selection logic Batocera hides behind its menus. If you're chasing cycle-accurate behaviour rather than convenience, note that software emulation has a ceiling FPGA hardware doesn't — the trade-offs we cover in the MiSTer Multisystem 2 piece are the other end of this spectrum, and Batocera's job is to be the flexible, free 90% rather than the hardware-perfect 100%.

Five Pitfalls That Waste Your Afternoon

These are the mistakes that don't announce themselves. Each one produces a symptom that looks like something else, which is why people burn hours on them. Read this section before you flash, not after.

Pitfalls 1 and 2: the wrong image, quietly

Pitfall 1 — ARM image on a PC (or vice versa). This is the number-one cause of “I flashed it and the screen is black.” The flash succeeds, the checksum even matches, and nothing boots, because the CPU can't execute the instructions. Fix: re-read the architecture field in the filename (Step 3) and confirm it against your hardware. x86_64 for PCs; the exact board image for ARM. Pitfall 2 — chasing 43.0 or an old build. Some guides and cached pages still point at 43.0, which shipped the very regressions 43.1 fixed. Fix: take the version from batocera.org/download, which shows 43.1 as current, and ignore any link that predates 30 May 2026.

Pitfalls 3 and 4: the media and the checksum

Pitfall 3 — the counterfeit card. A fake-capacity SD card flashes fine until it's asked to store more than its real size, at which point the flash fails validation or the boot hangs mysteriously. Fix: buy genuine, name-brand media, and treat a validation failure as a hardware verdict, not an image problem. Pitfall 4 — verifying with the wrong hash algorithm. Batocera publishes MD5. Reach for SHA-256 out of habit and you'll compute a hash that can't possibly match the published one, then conclude your good download is “corrupt.” Fix: ask your tool for MD5 specifically, as shown in Step 7. The mismatch was in your command, not the file.

Pitfalls 5 and 6: boot firmware and false economy

Pitfall 5 — Secure Boot and boot order. A PC that drops to “No bootable device” after a clean flash usually has Secure Boot enabled or the USB/SD below the internal disk in boot priority. Fix: disable Secure Boot, promote the removable device in the boot menu, and try both UEFI and Legacy/CSM if the first doesn't take. Pitfall 6 — a card too small or too slow. An 8 GB card technically boots but leaves you no room after the userdata partition expands, and a slow card makes menus and loads feel broken when they're merely starved. Fix: 16 GB is the floor, 32 GB+ and A1/Class 10 is the sane target. The card is the cheapest part of this build; do not economise on the one component that touches every operation.

Troubleshooting: Symptoms & Fixes

When something misbehaves, match the symptom, then apply the fix. The table is deliberately symptom-first, because you'll be reading it in the state where you know what you're seeing but not why.

The table

Boot and BIOS problems, explained

The first two rows account for most “it just won't start” reports, and they're firmware problems, not Batocera problems. Modern PCs ship with Secure Boot on, which refuses to hand control to an unsigned OS loader; Batocera isn't Microsoft-signed, so you disable it. The boot-order trap is subtler — the machine sees your USB stick, lists it, but still tries the internal disk first because that's the saved priority. One trip into the boot menu (F12/F11/Esc, board-dependent) fixes both. If a machine straddles the UEFI/Legacy line, try each mode once before concluding the image is bad; the image already proved itself at the checksum step.

Network and controller gremlins

Input and network failures feel dramatic and are usually trivial. A controller that “doesn't work” almost always just hasn't been mapped — Batocera won't assume your button layout. Wi-Fi that “doesn't exist” is frequently a driver-firmware gap on an obscure adapter; the pragmatic move is to run Ethernet for the initial setup, get the Store and updates working, and revisit wireless afterward. And the perennial “my ROMs vanished” is, nine times out of ten, files in the wrong folder or a stale game list — put them under the exact system directory and refresh. None of these are reasons to reflash.

Advanced: Upgrades, Mirrors & Pinning

Once you're running, you rarely download the full image again. Batocera's upgrade machinery lets you move between builds in place, preserving everything you care about, and gives you an escape hatch for pinning specific versions when a new release regresses something you rely on.

Upgrading in place with batocera-upgrade

Since Batocera 5.23, the sanctioned way to move builds is batocera-upgrade over SSH (or the equivalent updater in the menu). Because your ROMs, saves, BIOS, and batocera.conf all live on the untouched userdata partition, an upgrade only rewrites the boot/system partition — which is why it's safe and why a bad upgrade is recoverable by re-imaging without losing a single save:

# Default login is user 'root', password 'linux'. Change it once you are in.
ssh root@BATOCERA          # or: ssh root@192.168.1.50

# What am I running right now?
batocera-info

# Upgrade in place to the latest stable. /userdata is preserved entirely.
batocera-upgrade

The official updates and downloads wiki documents both the in-menu updater and the command line, including how to switch update channels between stable and the rolling butterfly beta. Stay on stable unless you specifically want to test unreleased emulator builds and are comfortable filing bug reports rather than receiving support.

Pinning a version via the o2switch mirror

Sometimes “latest” is not what you want — a new release changes a core's behaviour, or you need every machine in a lab on an identical build. Batocera's previous-releases documentation exposes a mirror-based path, and batocera-upgrade accepts an explicit URL, so you can roll to a precise, pinned build rather than whatever the stable pointer resolves to today:

# Roll to a specific/pinned build from the official o2switch mirror (advanced):
batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/last

# The updater only ever preserves /userdata. It rewrites the boot/system
# partition, so a bad flash here is recoverable by re-imaging - your games are safe.

The mirrors.o2switch.fr path is the archived/mirror route referenced in the project's previous-releases wiki; swap the trailing segment to target the version you actually want. This is also how you'd downgrade after a regression — point the command at the older build and let userdata carry your library across unharmed.

Running from a dedicated mini-PC

If Batocera graduates from “USB stick I boot occasionally” to “the living-room console,” installing to an internal SSD on a small x86_64 mini-PC is the natural end state — faster loads, silent operation, and a machine that does exactly one job well. On that kind of dedicated, always-on box, it's worth tuning the hardware underneath the emulator: shaving thermals and power draw keeps a fanless mini-PC quiet and stable under long sessions, and the same discipline we apply in our 2026 CPU undervolting walkthrough translates directly to a Batocera appliance you never want to hear. Batocera itself doesn't care how you tuned the silicon; it just benefits from a cooler, steadier host.

A Complete Working batocera.conf

Everything on a Batocera box is ultimately controlled by one file — /userdata/system/batocera.conf. The menus write to it, but you can edit it directly for reproducible, scriptable setups. Here's a complete, annotated configuration you can adapt: identity, updates, network, global emulator behaviour, and a per-system override, all documented inline.

The annotated configuration

# /userdata/system/batocera.conf  -  Batocera 43.1 working configuration
# A leading ';' disables a line and falls back to the built-in default.

# ---- Identity & locale ----
system.hostname=BATOCERA
system.language=en_US
system.kblayout=us
system.timezone=Europe/Paris

# ---- Updates ----
updates.enabled=1
updates.type=stable        # 'stable' = the 43.1 line; 'butterfly' = rolling beta

# ---- Network / Wi-Fi (Ethernet needs nothing here) ----
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourNetworkPassword

# ---- Global emulator behaviour ----
global.smooth=1            # bilinear smoothing
global.rewind=1            # rewind buffer for supported cores
global.autosave=0          # auto save-state on exit
global.retroachievements=0
;global.retroachievements.username=
;global.retroachievements.password=
global.bezel=thebezelproject   # decorative bezels pulled from the Store
global.ratio=auto

# ---- Audio / Video ----
audio.device=auto
audio.volume=90
global.videomode=default

# ---- Per-system override example (SNES pinned to a snappy core) ----
snes.core=snes9x
snes.videomode=default

# ---- Power / behaviour ----
system.power.switch=       # set only for specific power HATs; blank for PCs
system.splash.length=-1    # -1 = default splash duration

The final directory layout

With the config in place, your userdata partition should mirror the tree from Step 12 — roms populated per system, bios holding whatever firmware your platforms require, saves accumulating as you play, and system/batocera.conf as the single source of truth above. Because upgrades never touch this partition, this layout is durable across every future butterfly release: flash once, upgrade forever, and the only thing that ever changes underneath your library is the emulator code itself.

A one-command sanity check

After any change — a config edit, an upgrade, a new card — one command confirms what you're actually running and whether the box sees the network it needs for the Store and updates:

# SSH in, then confirm build, then confirm connectivity.
batocera-info
ping -c 3 batocera.org

# Expected: batocera-info reports version 43.1 and your architecture (x86_64),
# and the ping resolves and returns replies. If ping fails, revisit Wi-Fi/Ethernet
# in Step 11 before blaming the Store or the updater.

That's the whole loop: pick the right architecture, download from the one canonical page, verify the MD5, flash, boot, and feed it games — then upgrade in place for as long as you own the hardware. Batocera asks for a card, twenty minutes, and the discipline to not skip verification. In return it hands you 200+ systems and never once asks for your email. For the condensed field version of this same route, keep our 12-step, 30-minute quickstart open in the other tab. The Machine has flashed enough cards to tell you: the people who verify never post in the help forums.