Batocera Download 2026: 43.1 in 12 Steps, 30 Min

There is a specific disappointment reserved for anyone who types batocera download into a search bar expecting one button and a progress bar, and instead meets a version matrix, three architecture acronyms nobody explained, and a torrent link that looks abandoned. It is not abandoned. Batocera 43.1 shipped on 30 May 2026, the homepage was still headlining "Get Batocera.linux 43.1" into August, and the entire design goal of this distribution is that you stop thinking about the machinery underneath the moment the download finishes.

Batocera is not an app you install into Windows. It is a whole operating system you write to a USB stick or SD card and boot from, leaving whatever is on your actual disk untouched. That single decision is why the download step matters more here than in most tutorials: pick the wrong image for your hardware and nothing boots; write it to the wrong disk and you lose an afternoon and possibly your data. This guide walks the whole path — 12 numbered steps, about 30 minutes if you go in order — from choosing an image to a complete, working batocera.conf at the end. No marketing, no "just click next," and a running note of where the law leaves you on your own.

Batocera 43.1: What You're Actually Downloading

A live operating system, not an installer

Most "how to install X" tutorials end with an icon in your Start menu. Batocera does not work that way, and understanding why is the difference between a smooth afternoon and a forum post. Batocera is a self-contained Linux distribution — kernel 6.15.11, built on the same embedded toolchain that underpins a great deal of router and set-top firmware — with the EmulationStation frontend on top and a few hundred emulators underneath. You write the whole thing to removable storage and boot your machine from that. Your Windows or macOS install on the internal drive is never touched unless you explicitly tell Batocera to overwrite it. That is the headline feature: a portable console you can carry in a pocket and plug into any PC, with zero risk to the host.

The practical consequence for the download is that there is no setup.exe. There is a compressed disk image — a byte-for-byte picture of a formatted drive, roughly 3 GB compressed and about 8 GB once written — that you flash raw onto a card or stick. Get it right and the machine boots into EmulationStation in under a minute with 200+ systems available. Get it wrong and you get a black screen, because an image built for a Raspberry Pi's ARM chip is meaningless to an x86 PC and vice versa.

The version you want: 43.1, dated 30 May 2026

As of 13 August 2026 the official download page headlines version 43.1, and the changelog dates it to 30 May 2026. The lineage is worth memorizing because search results love stale pages. Version 42, "Papilio," was the previous major build, released 12 October 2025. Version 43, "Glasswing," followed on 8 May 2026. And 43.1 is not a new major release — it is the stability point release on the Glasswing line, three weeks later. If a guide tells you to grab version 40, or 5.27, or anything without a codename you recognize, it predates this cycle and its menus won't match yours.

Precision matters here because a lot of the low-quality guides floating around conflate the two dates and call 43.1 itself "Glasswing." It isn't. Glasswing is version 43 (8 May); 43.1 is the 30 May patch that sits on top of it. That patch is exactly why you want 43.1 over 43: it fixed a pile of real bugs — EmulationStation dropping systems and collections, broken Dolphin options, Steam and Flatpak breakage, and the genuinely maddening one where Microsoft controllers were being detected as keyboards. Same features as 43, fewer things broken.

Why the codenames tell you something

Batocera's major releases carry butterfly codenames — Papilio, Glasswing — and ship roughly twice a year, with point releases like 43.1 rolling accumulated fixes into a fresh image so new installers don't download 43 and immediately have to update. Version 43's actual headline feature was better AMD and Intel graphics through a dedicated x86-64-v3 image, a move to the Wayland/LabWC compositor, and experimental Nvidia support — the kind of plumbing work that never makes a splash but quietly widens the hardware net. The Glasswing, a butterfly with transparent wings, is a fitting mascot for a distribution whose whole pitch is that the operating system disappears and leaves you looking straight through to the games. The project's source and changelog live on GitHub if you want the commit-level truth rather than a blog's paraphrase.

Prerequisites: Hardware, Software, and Versions

Minimum and recommended hardware

Batocera runs on an enormous spread of hardware, and the image you download depends on which camp you're in. For a PC — any desktop or laptop with a 64-bit Intel or AMD processor from roughly the last decade, an Intel NUC, a Beelink-class mini-PC under the TV — you want the x86_64 image. Any GPU with working Linux drivers handles 2D and fifth-generation 3D; Dreamcast and up want a little more muscle. For single-board computers, a Raspberry Pi 4 (4 GB) or a Pi 5 is the sweet spot. RAM is genuinely not the bottleneck people assume — Batocera runs on a 512 MB Raspberry Pi Zero 2 W — so don't lose sleep over it; the constraint that actually bites is storage.

On storage the official wiki is unambiguous: 16 GB is the minimum, 32 GB is recommended for full functionality, and the in-place auto-updater will not run on a 16 GB card — it needs the headroom that 32 GB gives. More important than capacity is quality: a genuine, name-brand card rated A1 or A2, or a USB 3.0 flash drive or SSD. Counterfeit and worn-out cards are the single most common cause of "my Batocera keeps corrupting saves," and no configuration fixes bad silicon. If you plan to keep a real library on it, buy 64 GB or more of storage you trust.

The software you'll flash with

You need one tool to write the image, and there are three sane choices. The Batocera wiki's primary recommendations are Raspberry Pi Imager and USBImager — the former is the same official tool Pi users already have and can write a custom .img.gz, the latter is a tiny no-nonsense writer. balenaEtcher is the popular cross-platform alternative (the wiki points to it in troubleshooting), and it has the nice property of decompressing the .img.gz on the fly and verifying the write automatically. On any Linux box, the dd command that already ships with the OS is all you technically need, and we'll cover it because it's the most transparent about what's happening. Use current stable builds of whichever you pick; there's no reason to chase a specific version number for a tool whose whole job is to copy bytes.

What you must legally supply yourself

Here's the part the content farms skip. Batocera ships emulators; it does not ship games. There are no ROMs in the image, no copyrighted BIOS files for the systems that need them, and that is by design and by necessity. The emulators are legal software. The copyrighted game and firmware images they run are not the project's to distribute, and in most jurisdictions dumping cartridges and discs you physically own is the only defensible way to obtain them. A fresh install includes a little freely-licensed homebrew so it isn't literally empty, but the library of your childhood is your problem to source, legally, from hardware you own — the same "supply your own content" reality that governs every handheld with an inflated "28,000 games" sticker. The Machine will not tell you where to find a No-Intro set. The Machine will tell you the folder is called /userdata/roms/snes and leave the rest to your conscience and your local statute.

Step 1–2: Picking the Right Image for Your Architecture

x86_64 and x86-64-v3: PCs, mini-PCs, and the Steam Deck

If your target is a standard PC — a repurposed office desktop, a spare boot drive in a gaming rig, a NUC or mini-PC under the TV, even an Intel Mac — you want the file whose name contains x86_64. This is the most capable Batocera target there is, because a modern x86 chip and a real GPU emulate systems a Raspberry Pi can only dream about. There is a second PC image, x86-64-v3, introduced with version 43 and tuned for newer chips (roughly Zen 3 and later) and handheld PCs — the Steam Deck's natural target. If you're weighing a Deck against other handhelds for exactly this kind of duty, our Switch 2 versus Steam Deck breakdown covers where it lands. And yes, a 32-bit x86 legacy image still exists for genuinely ancient hardware, though if your machine needs it, it's old enough to retire.

bcm2711 and bcm2712: the Raspberry Pi line

Raspberry Pi images are named after the Broadcom system-on-chip, not the marketing model number, which trips people up constantly. The Raspberry Pi 5 uses bcm2712. The Pi 4, Pi 400, and Compute Module 4 use bcm2711. The Pi 3 uses bcm2837. Match the SoC, not your memory of what the box said, because flashing a Pi 4 image to a Pi 5 produces exactly the black screen described earlier. The Pi builds are genuinely excellent through PlayStation 1, Nintendo 64, and much of the arcade catalogue; a Pi 5 stretches into Dreamcast and PSP territory with the right cores.

Odroid, Anbernic, Retroid, and the long tail

Between the PC and the Pi is a long tail the download page enumerates: Odroid boards, Orange Pi, Rockchip devices (rk3588 and friends), the Ayn Odin 2, several Retroid Pocket models, and Anbernic RG handhelds. Some are first-class targets, some are community ports, and some are best left on their stock firmware. If you own a Linux-friendly ARM handheld and want to know whether Batocera is even the right move for it, our ranking of the 2026 Retroid Pocket line is a useful reality check before you flash anything. When in doubt, x86 handhelds with an AMD APU simply take the x86_64 (or x86-64-v3) image and behave like tiny PCs.

1. Identify your hardware's architecture. Decide whether you're flashing for an x86_64 PC, an x86-64-v3 handheld like the Steam Deck, a specific Raspberry Pi (by SoC), or a supported single-board computer. This one choice determines every file you touch afterward, and getting it wrong is the number-one avoidable failure.
2. Open the official download page and select your device. Go to batocera.org/download, choose your exact hardware, and you'll be offered a direct download and a torrent. Prefer the source the project itself links — mirror roulette from a random blog is how people end up flashing a two-year-old image.

Step 3–5: Downloading and Verifying 43.1

Direct download versus the torrent

The download page offers two routes: a direct HTTP download and a torrent. For most people the direct link is fine. If your connection is flaky or the mirror is slow, the torrent is not a piracy flag — it's the project distributing its own legal, multi-gigabyte file the efficient way, and it verifies every chunk as it arrives. Either way you're fetching a single file of the form batocera-x86_64-43.1-20260530.img.gz, around 3 GB. It's a full operating system, not an app; give it a minute.

Reading the filename like a serial number

The naming scheme is batocera-[architecture]-[version]-[date].img.gz, and it's the fastest sanity check you have:

batocera-x86_64-43.1-20260530.img.gz
         |        |    |        |  |
         |        |    |        |  └─ gzip compression
         |        |    |        └──── raw disk image
         |        |    └───────────── build date (30 May 2026)
         |        └────────────────── version (43.1)
         └─────────────────────────── architecture (64-bit PC)

If the architecture segment doesn't match your hardware, stop — you have the wrong file. If the date isn't 20260530 and the version isn't 43.1, you're looking at a different build than this guide assumes, and the menus may not line up.

Verifying integrity before you flash

Before you write gigabytes to a drive, confirm the gigabytes you downloaded aren't corrupt. The image is a gzip archive, and gzip has integrity checking built in. On Linux or macOS:

$ gunzip -t batocera-x86_64-43.1-20260530.img.gz
$ echo $?
0

A 0 with no error output means the archive is intact. If the download page publishes a checksum, verify that too — it catches truncation and tampering that a gzip test can miss:

$ sha256sum batocera-x86_64-43.1-20260530.img.gz
<64-character hex hash>  batocera-x86_64-43.1-20260530.img.gz

Compare the 64-character hash against the one published next to the download. If they differ by a single character, delete the file and pull it again. Do not flash a mismatched image — a bad download that boots once and then corrupts is indistinguishable from a hardware fault, and you'll waste an hour chasing the wrong ghost.

3. Choose the direct download or the torrent. Both are legal and both land the same file; the torrent simply self-verifies as it goes and is kinder to a shaky connection.
4. Confirm the filename matches your architecture and version. The [arch]-[version]-[date] pattern is a free pre-flight check — a ten-second read here prevents the most common failure downstream.
5. Verify the image's integrity. Run gunzip -t and, if a checksum is published, sha256sum. Flashing a corrupt file wastes the next twenty minutes and then masquerades as a bad SD card.

Step 6–8: Flashing to USB or SD

Raspberry Pi Imager, USBImager, and Etcher

For a graphical flash, pick one of the three. Raspberry Pi Imager is the wiki's first suggestion and handles a custom .img.gz via "Use custom"; USBImager is a lightweight no-frills writer; and balenaEtcher is the cross-platform favourite that decompresses on the fly and verifies afterward. Etcher's flow is three fields: "Flash from file" (select the .img.gz — no need to unzip first), "Select target" (your USB stick or SD card), and "Flash." It greys out system drives to make it hard to nuke your own machine, writes the image, then re-reads the drive to verify byte-for-byte. On typical hardware the write-and-verify runs 5 to 15 minutes depending on the speed of the storage. When it says "Flash Complete," it means it.

The command-line path: lsblk and dd

If you'd rather see exactly what's happening, or you're on a headless Linux box, dd is the honest tool — and the sharpest. First, identify the target unambiguously. Plug the drive in and run:

$ lsblk
NAME    SIZE TYPE MOUNTPOINT
sda     931G disk
├─sda1  512M part /boot/efi
└─sda2  930G part /
sdb      29G disk            <- the 29G USB stick you just inserted
└─sdb1   29G part

Here sda is the 931 GB internal disk — leave it alone — and sdb is the 29 GB USB target. Identify yours by size, because getting this wrong overwrites the wrong disk and there is no undo. Then decompress and write in one pipe:

$ gunzip -c batocera-x86_64-43.1-20260530.img.gz | \
    sudo dd of=/dev/sdb bs=4M status=progress conv=fsync
$ sync

Note the target is /dev/sdb, the whole disk, not /dev/sdb1, a partition — you're writing an entire drive layout, not a file into a filesystem. The conv=fsync and the trailing sync make sure the data is physically on the flash before you touch the drive.

Verify the write, and don't pull the drive early

Whichever tool you used, the write is not done when the progress bar hits 100%. Cheap flash drives lie: they buffer writes and report completion before the data has committed. Etcher's verify pass covers this; with dd, the sync is what covers it. Wait for the tool to explicitly release the drive, then eject it through your OS before physically removing it. Yanking a card mid-commit is the fastest way to produce an image that boots once, corrupts on first write, and sends you back to the download page convinced the file was bad. It wasn't. You were impatient.

6. Load the image into your flashing tool. Raspberry Pi Imager, USBImager, or Etcher — all read the .img.gz directly, so there's no need to decompress it by hand first.
7. Select the correct target drive — and check it twice. Confirm the device by capacity with lsblk or the tool's own drive picker. This is the one irreversible step in the whole process; a wrong target with dd overwrites your system disk silently.
8. Flash, verify, and wait for the tool to finish. Let the verify pass complete and eject cleanly. The extra thirty seconds here is cheaper than re-flashing after a corrupted first boot.

Step 9–12: First Boot and Initial Configuration

Boot order and letting userdata expand

Move the drive to the target machine and boot from it. On a PC that means interrupting startup with the one-time boot-menu key — usually F12, F11, F8, or Esc, depending on the manufacturer — and choosing the USB device. If the machine boots straight into Windows, enter the firmware (BIOS/UEFI) setup, disable Secure Boot (Batocera isn't Secure Boot signed), and move USB above the internal drive in the boot order. On a Raspberry Pi there's nothing to configure; it boots from the card automatically.

The first boot does two things worth understanding. EmulationStation starts and shows the systems carousel — and, silently, Batocera resizes its userdata partition to fill the entire drive. That partition holds your ROMs, saves, screenshots, and configuration. On a 64 GB card, roughly 63 GB becomes usable after the small boot partition. This is exactly why you flash to the final drive you intend to use rather than a small card you plan to clone later: the layout adapts to the medium on that first boot.

Controllers, language, and WiFi

Plug in a controller and Batocera will most likely recognize it immediately — Xbox, PlayStation, and 8BitDo pads are detected out of the box (and 43.1 specifically fixed the regression where some Microsoft controllers were misread as keyboards). If a pad isn't mapped, hold any button for a few seconds and EmulationStation launches its input wizard. Press Start for the main menu, set language and time zone under System Settings, and connect under Network Settings. If you'd rather configure WiFi before first boot — handy for a headless Pi — edit the config file directly on the boot partition from another computer:

# /userdata/system/batocera.conf
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourWiFiPassword

Ethernet needs none of this — plug it in and Batocera is online.

Confirming you're on 43.1

Before going further, confirm the running build. The version is shown in the main menu under System Settings → System Information, and over SSH or a terminal you can read the board string directly:

$ cat /boot/boot/batocera.board
x86_64
$ batocera-check-updates

If System Information reads "43 (Glasswing)" rather than 43.1, you flashed the major release instead of the point update — not a disaster, since you can update in place (next section), but not what this guide assumed. If it reads 42 or "Papilio," you downloaded a stale image; go back to step 2.

9. Set the machine to boot from your Batocera drive. Use the one-time boot menu or reorder boot devices in UEFI, and disable Secure Boot on a PC. Without this the machine simply ignores the drive and loads its usual OS.
10. Let the first boot expand userdata to fill the drive. Don't interrupt it. This silent resize is what turns a 64 GB card into 63 GB of usable library space, and it only happens cleanly once.
11. Configure your controller, language, and network. A mapped pad and a working network turn a bare boot into a usable machine and unlock the scraper and updater you'll want next.
12. Confirm the running version reads 43.1. Check System Information. Catching a stale or major-only image now saves you from debugging menu differences later.

Adding ROMs and BIOS the Right Way

The network-share method (the easy one)

With Batocera on the network, the least painful way to move games onto it is the built-in file share. Batocera advertises itself as BATOCERA, and you can reach it from any computer on the same LAN. On Windows or macOS, open \\BATOCERA\share (or \\192.168.1.X\share with its IP); on Linux, point your file manager at smb://BATOCERA.local/share. That share folder is /userdata — the same place, seen over the network — and inside it is roms. Drop your legally-obtained files into the correct system subfolder and they'll appear in EmulationStation after a refresh.

The folder structure that matters

The folder names are not suggestions. Each system has a specific directory under /userdata/roms/ (a.k.a. share/roms/), and a Super Nintendo ROM dropped into the nes folder will either not appear or refuse to launch. Helpfully, every system folder contains an _info.txt that lists the file formats that system accepts, so you're never guessing. The common ones:

/userdata/roms/
├── snes/        Super Nintendo
├── nes/         Nintendo Entertainment System
├── megadrive/   Sega Genesis / Mega Drive
├── gba/         Game Boy Advance
├── n64/         Nintendo 64
├── psx/         Sony PlayStation
├── dreamcast/   Sega Dreamcast
├── mame/        Arcade (MAME)
└── ...          one folder per supported system

After copying files in, refresh the library from the main menu with START → Game Settings → Update Gamelists (or restart EmulationStation). Batocera's scraper can then pull box art, descriptions, and metadata for the games it recognizes, turning a wall of filenames into a browsable shelf.

BIOS files and the Missing BIOS menu

Some systems refuse to run without their original firmware. PlayStation, Sega CD, Neo Geo, and others need specific BIOS files placed in /userdata/bios/ with exact filenames and, often, exact checksums. Batocera hands you a map: from the main menu, open Game Settings → Missing BIOS, and it lists precisely which files each installed system wants, the filename it expects, and the checksum it must match. Match those and the red warnings turn green. The authoritative reference for which core needs which file is the libretro BIOS documentation, and the broader Batocera add-games-and-BIOS wiki page covers the edge cases. Where those files come from is, once again, between you and the hardware you own — the emulators are legal; the firmware images are copyrighted.

Updating: batocera-upgrade, the Store, and Channels

Updating from EmulationStation

Once Batocera is running, staying current does not mean downloading a fresh image and starting over. The updater is built in. From EmulationStation, press Start and open Updates & Downloads — the same menu that houses the content store. Batocera checks the mirror for a newer build on your chosen channel and, if one exists, downloads and applies it in place, preserving your ROMs, saves, and configuration under userdata. This is the officially documented path and the one to use if you're not comfortable in a terminal. (Remember the storage caveat from the prerequisites: the auto-updater needs the headroom of a 32 GB card and won't run on a full 16 GB one.)

batocera-upgrade from the command line

If you are comfortable in a terminal, the same operation is a command. Available since Batocera 5.23, batocera-upgrade takes an optional mirror URL; point it at the current stable build for your architecture:

$ batocera-check-updates
$ batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/last
Checking latest version ...
Current version: 43.1
System is up to date.

Note the shape of that mirror path — .../x86_64/stable/last. Swap the architecture segment for your hardware, and swap last for a specific version number if you ever need to pin or roll back a build rather than track the latest. The manual-upgrade wiki page documents the full syntax, including the offline batocera-upgrade manual flow for machines that can't reach the internet.

Stable, butterfly, and the pacman store

Batocera has two update channels, set in the config file. stable is the default and the one you want — it tracks point releases like 43.1 as they're blessed. butterfly is the bleeding-edge nightly channel: newer cores and fixes, but also newer bugs, and not something to run on a setup you rely on. Switch only deliberately:

# /userdata/system/batocera.conf
updates.enabled=1
updates.type=stable      # or 'butterfly' for nightlies

Separately, since Batocera 5.27 the distribution has shipped a content store — reachable from that same Updates & Downloads menu — offering freely distributable add-ons, themes, and homebrew, managed under the hood by the pacman package manager that Arch users will recognize. It's the sanctioned way to extend a fresh install without touching a ROM you don't own. If you swap cores or emulators from here, our guide to which RetroArch cores are actually worth running in 2026 will save you some trial and error.

Five Pitfalls That Ruin a Batocera Install

Wrong architecture, wrong disk

Five mistakes account for the overwhelming majority of failed installs. None are subtle once you know them; all of them look like a hardware fault when you don't.

Pitfall 1 — flashing the wrong architecture. An x86_64 image won't boot a Raspberry Pi, and a bcm2712 image won't boot a PC. The symptom is a black screen or an apparently dead device. The fix is upstream: re-read the filename before you flash, per step 4.

Pitfall 2 — writing to the wrong disk. This is the expensive one. Etcher greys out system drives; dd does not, and of=/dev/sda instead of /dev/sdb will cheerfully overwrite your main drive with no confirmation and no undo. Identify the target by size with lsblk every single time, even when you're certain.

Counterfeit and worn-out storage

Pitfall 3 — cheap or counterfeit storage. A card that claims 128 GB but physically holds 16, or a genuine card that's simply worn out, produces intermittent corruption: saves that vanish, a system that boots fine and then bricks on the third power cycle. It reads as a Batocera bug. It's a storage bug. Buy name-brand A2 cards or use a USB 3.0 SSD, and if you suspect a fake, test its true capacity before trusting it.

Pitfall 4 — yanking the drive early. Covered in step 8 and worth repeating because it's so common: the progress bar is not the finish line. Let the tool verify and release the drive before you remove it, or you'll flash a perfectly good image into a corrupt state and blame the file.

Expecting the games to be in the box

Pitfall 5 — expecting games and BIOS included. Newcomers flash Batocera, boot it, see the systems menu populated, open Super Nintendo, find nothing, and conclude the install failed. It didn't. Batocera ships zero commercial ROMs and zero copyrighted BIOS files, by design and by law. An empty system list is the correct, expected state of a fresh install. It is, by a wide margin, the number-one "bug report" the community fields, and it is not a bug — it's the law doing its job. If you read the prerequisites, none of this surprises you.

Troubleshooting Table: Symptoms and Fixes

When something misbehaves, the cause is almost always one of a short list. Match the symptom, apply the fix, and resist the urge to re-flash before you've ruled out configuration.

Boot and display problems

The black-screen family is almost always the wrong image or Secure Boot. Because Batocera isn't signed for Secure Boot, a modern PC with it enabled silently refuses to hand off. Enter UEFI, turn Secure Boot off, confirm USB is ahead of the internal disk, and retry. If the machine still won't touch the drive, you're not using the one-time boot menu — the key flashes on the splash screen for a fraction of a second, and it varies by vendor.

Input, audio, and network

These are configuration, not corruption. A pad that isn't recognized just needs the input wizard (hold any button); if it's being read as a keyboard, you're on a pre-43.1 build and the update fixes it. Silent HDMI is nearly always the wrong output device — Batocera may have picked DisplayPort audio or an analogue jack; point it at HDMI in Sound Settings. WiFi failures split between hidden networks, mistyped keys, and the odd adapter whose firmware isn't bundled; plug in Ethernet to prove the rest of the setup works, then come back to wireless.

Updates and storage

These get misattributed most. If the updater fails, confirm updates.type is stable, that you're on at least a 32 GB card, and that the machine can actually reach the internet before blaming the tool. And if saves keep evaporating or the card bricks after a few boots, stop reconfiguring — that's the signature of bad flash storage, and the only fix is better storage. No config edit repairs a counterfeit card.

Advanced Tips: Internal Install, SSH, and Tuning

Installing to internal storage

Running from a USB stick is the portable, zero-risk default, but once you're sure Batocera is your setup, installing it to an internal SSD is faster and tidier. Batocera includes an installer for exactly this: from the main menu, System Settings → Install Batocera On A New Disk. It lists detected internal disks and — with appropriately grave warnings — writes Batocera to one, wiping whatever was there. This is the one operation in this entire guide that deliberately touches a host disk, so read the target selection twice. On a dedicated box with a small SATA or NVMe SSD, an internal install boots faster, loads big games quicker, and outlives any flash drive.

SSH, backups, and editing config the safe way

Batocera runs a real Linux underneath and exposes SSH for people who want it. The default credentials are user root, password linux — change them immediately if the box lives on a shared network. Connect and you can edit configuration, script backups, and read logs directly:

$ ssh root@batocera            # default password: linux — CHANGE IT
$ nano /userdata/system/batocera.conf
# Back up your whole config and saves before a major update:
$ tar czf /userdata/saves/backup-config.tar.gz \
    /userdata/system /userdata/saves

Everything that makes your install yours lives under /userdata — roms/, bios/, saves/, and system/. Back that directory up and you can re-flash, re-image, or migrate to new hardware and restore in minutes. The wiki's installation and configuration pages document the full layout; they're the pages to bookmark after the download link.

Performance tuning, cores, and thermals

Two levers matter most. The first is core selection: Batocera bundles multiple emulators per system (43.1 ships, among others, a September 2025 Fceumm build and a December 2025 Genesis Plus GX build), and the default isn't always the fastest or most accurate for your hardware. Nintendo 64 is the classic example — the default mupen64plus-next core saw regressions through 2025, and many users get steadier results from a Parallel-based core on weaker machines. The second lever is the hardware: if you're running Batocera on an x86 mini-PC, a careful undervolt can drop temperatures and fan noise under an emulation load without costing performance — worth it on a fanless box that thermal-throttles during a PS2 session. Tune the cores, tune the silicon, and leave everything else at Batocera's sensible defaults.

A Complete, Working batocera.conf

The full file

Here is a complete batocera.conf that takes a fresh 43.1 install to a sane, usable state: on the network, controllers smoothed, sensible emulation defaults, and an explicit core per system. Drop it in at /userdata/system/batocera.conf, edit the WiFi and timezone lines for your situation, and restart EmulationStation.

## ---- System ----
system.hostname=BATOCERA
system.language=en_US
system.timezone=Europe/Lisbon
system.kblayout=us

## ---- Network ----
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourWiFiPassword

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

## ---- Video / Audio ----
global.videomode=default
global.smooth=1
global.bezel=default
global.shaderset=none
audio.volume=90

## ---- Emulation defaults ----
global.rewind=0
global.autosave=0
global.retroachievements=0
global.retroachievements.hardcore=0

## ---- Per-system core choices ----
snes.core=snes9x
nes.core=fceumm
megadrive.core=genesisplusgx
gba.core=mgba
n64.core=mupen64plus-next
psx.core=swanstation

What each block does

The System block sets identity and locale — the hostname is what the machine advertises on the network, and the language and keyboard lines save you a trip through the menus. Network brings WiFi up at boot; delete it and use Ethernet if you prefer. Updates pins you to the stable channel so you track point releases like 43.1 rather than nightlies. Video/Audio turns on bilinear smoothing (global.smooth=1), keeps decorative bezels on, and leaves shaders off for performance — flip global.shaderset to a CRT preset if you want scanlines and can spare the GPU. Emulation defaults disable rewind and autosave (both cost performance and disk) and leave RetroAchievements off until you add credentials. The Per-system block names an explicit core for each system so you're not at the mercy of a shifting default — these are solid, widely-used choices as of 43.1. The full key reference lives on the Batocera wiki.

Applying it without a reboot loop

Two cautions when editing this file by hand. First, it's key=value, one per line, no spaces around the equals sign, and # starts a comment — a stray space or a smart-quote pasted from a web page silently disables the line. Second, apply changes gently: restart EmulationStation from the menu, or run reboot over SSH, rather than pulling power. And if a bad edit ever leaves the system misbehaving, you can delete batocera.conf entirely — Batocera regenerates a default on next boot, and your ROMs and saves, which live elsewhere under userdata, are untouched. That safety net, more than any single emulator, is why this distribution is worth the download: the worst case is a config you throw away, not a machine you rebuild.

That's the whole path — architecture to image, download to verified flash, first boot to a configuration you can live with, in about half an hour of mostly waiting. Batocera's genius isn't any one emulator; it's that the operating system disappears and leaves you with the games, and the law, between you and them. Get the download right and everything after it is just deciding what to play.