Batocera Download 2026: 43.1 in 12 Steps, 30 Min

There is a particular species of software that asks you for nothing. No account. No subscription. No telemetry dialog with a pre-ticked consent box that a Luxembourg court would later rule unlawful. Batocera.linux is one of those. You download a single compressed disk image, write it to a USB stick or an SD card, and you have turned a dead office PC or a Raspberry Pi into a console that boots straight into a grid of games. It never touches the operating system already on the machine. Pull the stick out and the computer is exactly as you left it, none the wiser.

This is a tutorial about the one step everyone fumbles before they get anything right: the download. As of August 23, 2026 the current stable release is Batocera 43.1, and the official site, updated that very day, points you at it with a button that reads, with characteristic bluntness, Get Batocera.linux 43.1. Fetching the correct image, verifying it, and writing it to media without vaporising the wrong drive is roughly ninety percent of the difficulty. The rest is menus. We will do all of it in twelve steps, and I will tell you where the bodies are buried.

Budget thirty minutes if your connection is quick and your USB stick is not a counterfeit. Budget an evening if you skip the verification steps, because you will be doing this twice.

Why Batocera, and What You're Downloading

Before you touch a download button, understand what the button does, because it does not do what the word 'download' implies on most consumer software. You are not fetching an installer. You are fetching an entire operating system, pre-assembled, that expects to become a disk rather than run on one.

A Read-Only OS on Removable Media

The Batocera homepage describes the project, without a single adjective it did not need, as an open-source, completely free retro-gaming distribution that you copy to a USB stick or SD card to turn a computer or nano computer into a gaming console. That sentence is doing a lot of quiet work. The critical design decision is that the system partition is read-only and self-contained. Batocera does not install alongside Windows. It does not dual-boot in the traditional sense. It lives entirely on the media you flash, and when you tell your machine to boot from that media, the machine becomes a Batocera console for exactly as long as the stick is plugged in. Your host drive, your files, your existing OS: untouched. This is the single most underappreciated feature of the whole project, and it is why handing a flashed USB stick to a nervous relative is a reasonable thing to do.

Under the hood it is a Buildroot-based Linux running EmulationStation as the front end and a stack of emulators, most of them libretro cores loaded through RetroArch, doing the actual work. If you want to understand what those cores are and how the same emulator can behave completely differently depending on which core you load, our companion walkthrough on loading 200-plus RetroArch cores in 12 steps is the prerequisite reading nobody tells you about.

43.1 'Glasswing': What Actually Shipped

The version you are downloading is 43.1. According to third-party release trackers, the 43 series carries the codename 'Glasswing', with the initial 43 build published on 2026-05-08 and the 43.1 point release following on 2026-05-30. Treat those human-readable dates as approximate; the authority you actually care about is the filename on the official upgrade index, which stamps every image with a build date. The official torrent index lists batocera-x86_64-43.1-20260529.img.gz for the 64-bit PC build, dating that specific artifact to 2026-05-29. If a guide tells you the x86_64 file is dated 20260530, it is quoting a different source than the project's own index. This is not pedantry; it is the difference between downloading the file the project actually publishes and downloading whatever a content farm typed from memory.

The Legal Part Nobody Reads

Batocera ships emulators. It does not ship games. This is deliberate and it is the law working as intended: the emulators are clean-room legal, the ROMs are your problem. The distribution arrives with an empty ROM directory and a shrug. The only unambiguously lawful way to obtain a ROM is to dump a cartridge or disc you physically own, which is a whole discipline of its own; if you are going down that road, our guide to dumping SNES and Genesis carts with a Retrode is where the honest people start. Console BIOS files carry the same asterisk, and we will get to why that ruins more first boots than any other single cause.

Prerequisites: Hardware, Media, Software

Three things stand between you and a working console: a machine capable of running the image, media large and honest enough to hold it, and a desktop tool to write the one to the other. Get all three right before you download and the rest of this is mechanical.

The Machine You'll Run It On

Batocera runs on an enormous spread of hardware, but for this tutorial we assume the two overwhelmingly common cases: a 64-bit x86 PC or mini-PC, or a Raspberry Pi. For the PC path you need any 64-bit Intel or AMD processor from roughly the last fifteen years, which is to say almost anything that is not a museum piece. Two gigabytes of RAM is a workable floor; four is comfortable and stops you thinking about it. A GPU is not optional for the ambitious systems, but for the eight-bit and sixteen-bit era that most people actually play, integrated graphics from the last decade are fine. The dead Dell in the closet qualifies. So does a fanless N100 mini-PC, which is arguably the ideal Batocera host in 2026: silent, cheap, and more than fast enough for everything up to the PlayStation 2 comfort zone.

If you are chasing cycle-accurate behaviour rather than convenience, understand that software emulation is not the only religion. FPGA solutions such as the ones the MiSTer FPGA community obsesses over reproduce original hardware timing in ways emulation still argues about, and dedicated boxes like the Analogue 3D for the N64 take the same purist stance for a single console. Batocera is the pragmatist's answer, not the purist's.

The Media You'll Flash To

You need a USB 3.0 stick or an SD card of at least 8GB. Bigger is better, and the reason is not the operating system; it is that your ROMs, saves, screenshots, and scraped artwork all live on the same media by default, in a partition called userdata that Batocera grows to fill the card on first boot. A 32GB card is a sane minimum for a real collection; 128GB or 256GB is where most people end up. Two warnings that will save your weekend. First, buy from a vendor you trust, because counterfeit cards that report 256GB and actually hold 8GB are a plague, and Batocera will flash onto the fake capacity, boot, and then silently corrupt the moment you cross the real ceiling. Second, USB 2.0 sticks work but feel like wading through treacle; spend the extra dollar on USB 3.0.

The Software You'll Need on the Desktop

To turn the compressed image into a bootable device you need a flashing tool. The project itself recommends balenaEtcher, which runs on Windows, macOS, and Linux and is the least dangerous option because it will not let you accidentally select your system drive without a fight. On Windows, Rufus is the faster, more technical alternative. On Linux or macOS the command-line dd is available and included with the OS, and we will cover it for people who read man pages for pleasure. You do not need to decompress the .img.gz yourself; both balenaEtcher and modern Rufus read the gzip directly. Bookmark the official Batocera download page and the Batocera wiki now, because you will reference both before you are done.

Picking the Right Image

The single most common way to waste an hour is to download an image for the wrong architecture, flash it perfectly, and then stare at a machine that refuses to boot. The image is not broken. It is the wrong species. Batocera builds are architecture-specific and they are not interchangeable, so this section exists to make sure you download exactly one file, the correct one.

Architecture Is Not a Suggestion

An ARM image will not boot on a PC, and an x86 image will not boot on a Raspberry Pi. This is not a Batocera quirk; it is how CPUs work. The instruction sets are different languages. For a standard desktop, laptop, or mini-PC you want the x86_64 build, full stop. For a Raspberry Pi you must select the exact board-family image: a Raspberry Pi 5 uses the bcm2712 build, and the official index lists batocera-bcm2712-43.1-20260529.img.gz for exactly that. Snapdragon-class ARM devices get their own build entirely; the index carries batocera-sm8250-43.1-20260530.img.gz, dated one day later than the x86 and Pi 5 images, which is normal because the project builds platforms on their own schedules. If you are running Batocera on an ARM handheld rather than a Pi, the same rule applies with even less mercy: the board image must match the silicon, the way it does across the Retroid Pocket lineup, where each model expects firmware built for its exact chip.

The Naming Convention, Decoded

Every Batocera image follows one pattern, and once you can read it you can never download the wrong thing again:

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

Examples from the official upgrade index (version 43.1):
  batocera-x86_64-43.1-20260529.img.gz   <- 64-bit PC / mini-PC
  batocera-bcm2712-43.1-20260529.img.gz  <- Raspberry Pi 5
  batocera-sm8250-43.1-20260530.img.gz   <- Snapdragon SM8250 devices

The architecture token tells you the hardware. The version token tells you the release. The date token, in YYYYMMDD form, tells you which build of that release you are holding, which matters when you are diffing against what the project actually published. A guide floating around the search results cites batocera-x86_64-43.1-20260530.img.gz as the canonical PC filename. The official torrent index says 20260529 for x86_64. When the project and the aggregator disagree, the project wins.

43.1 vs 42: Why You Take the Point Release

You might see references to version 42, with artifacts such as batocera-x86_64-42-20251006.img.gz dating that release to October 2025. Do not download it. A point release like 43.1 exists precisely because 43.0 shipped with something that needed fixing, and 43.1 is the version the download page and the homepage both push you toward with the Get Batocera.linux 43.1 button. There is no prize for running an older build, and there is no compatibility reason to prefer 42 unless you are pinning a specific device that regressed, which you are not, because you are reading a download tutorial.

Download in 12 Steps

Here is the whole procedure, from cold machine to written media, with the reasoning attached to each step because a step without a rationale is a step you will skip under pressure. Steps 1 through 8 are the download proper; 9 through 12 verify and stage the file so that the flashing section is trivial.

1. Open the official download page. Navigate to batocera.org/download directly. Rationale: search results are riddled with mirrors, torrents of dubious provenance, and 'setup helper' sites. The project's own page was last updated on 2026-08-23 and links the current 43.1 build. Start from the source of truth.
2. Confirm the version reads 43.1. The page and the homepage both advertise Get Batocera.linux 43.1. Rationale: if a cached page shows 43.0 or 42, you have stale content; hard-refresh until the current version appears.
3. Select your hardware from the device picker. Choose 'PC / x86_64' for a desktop, laptop, or mini-PC, or the exact Raspberry Pi model for a Pi. Rationale: the picker maps your plain-English hardware to the correct architecture token so you do not have to memorise 'bcm2712'.
4. Verify the filename before you click. The link should resolve to a name matching batocera-[architecture]-43.1-[date].img.gz. For a PC that is batocera-x86_64-43.1-20260529.img.gz. Rationale: this is your last checkpoint to catch a wrong-architecture download before you spend bandwidth on it.
5. Choose direct download or torrent. The direct HTTP link is simplest; the torrent, served through the project's upgrade index, is kinder to the project's bandwidth and often faster. Rationale: for a roughly two-gigabyte file, a torrent client with a healthy swarm frequently beats a single mirror, and it self-verifies chunks as it goes.
6. Save the .img.gz without extracting it. Let it land in your Downloads folder as a compressed archive. Rationale: balenaEtcher and Rufus both consume the gzip directly, and extracting first only wastes disk space and time.
7. Wait for the full download and note the size. A truncated download is the second most common cause of a failed flash after wrong architecture. Rationale: a file that is suspiciously small, say a few megabytes, is an HTML error page your browser saved with a .gz extension, not an image.
8. Insert your USB stick or SD card now. Do it before verification so the operating system settles on a device node. Rationale: identifying the target device is a step people rush, and rushing it is how data drives die.
9. List the file and confirm the size looks right. On Linux or macOS:

   ls -lh ~/Downloads/batocera-x86_64-43.1-20260529.img.gz

   Expected output resembles:

   -rw-r--r-- 1 user user 2.1G May 29 08:14 batocera-x86_64-43.1-20260529.img.gz

   Rationale: a couple of gigabytes is sane; a few kilobytes is a saved error page.
10. Test the archive integrity. A gzip archive knows whether it is intact. Run:

    gunzip -t ~/Downloads/batocera-x86_64-43.1-20260529.img.gz
    echo $?

    Expected output:

    0

    Rationale: an exit code of 0 means the compressed stream is not corrupt end to end. Any non-zero value means the download is damaged and you re-download now, not after you have flashed garbage to a card.
11. Cross-check the published checksum if one is offered. Where the download page lists a SHA-256, compute yours with sha256sum (Linux) or shasum -a 256 (macOS) and compare, character for character. Rationale: gunzip -t proves the archive is internally consistent; the published checksum proves it is the exact file the project released and nobody tampered with it in transit.
12. Confirm you have a flashing tool installed. Have balenaEtcher, Rufus, or dd ready before you proceed. Rationale: the file is staged and verified; the only thing left is to write it, which is the next section. Do not celebrate yet, because writing to the wrong device is where the real damage happens.

Flashing the Image

Flashing is the step that can destroy data, so it is the step where you slow down. The compressed image becomes a raw disk on your media, overwriting everything already there. Choose the wrong target and you overwrite the wrong disk. There is no undo. Pick your tool by temperament.

balenaEtcher: The Path of Least Resistance

balenaEtcher is the project's recommended tool because it is deliberately hard to misuse. Launch it, click 'Flash from file' and select the .img.gz (it reads the gzip natively, no extraction), click 'Select target' and pick your USB stick or card, then click 'Flash'. Etcher hides system drives by default and shows capacities, so a 256GB card is obvious and your 2TB system disk does not appear in the casual list. It writes, then re-reads and validates automatically, which is worth the extra ninety seconds because a card that fails validation here is a card that would have failed to boot later, and you want to learn that now. When it reports success, you are done and you can skip to First Boot.

Rufus on Windows: For the Impatient

Rufus is Windows-only, faster than Etcher, and trusts you more, which is both its virtue and its hazard. Select your device at the top, and read that dropdown twice, because Rufus will happily list every removable and, if you tick the option, fixed drive on the system. Select the Batocera .img.gz under 'Boot selection', leave the partition scheme on the default it detects, and click 'Start'. If Rufus asks about writing in DD Image mode versus ISO mode, choose DD Image mode; Batocera is a raw disk image, not an ISO. Rufus does not validate after writing the way Etcher does, so if you have any doubt about your media, prefer Etcher.

dd on Linux and macOS: For People Who Read man Pages

The command line is the fastest and the most dangerous route, because dd does exactly what you tell it with no confirmation and no mercy. First, identify the target device without ambiguity:

lsblk

Expected output, with a 32GB stick showing up as sdb:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 465.8G  0 disk
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 465.3G  0 part /
sdb      8:16   1  28.9G  0 disk
└─sdb1   8:17   1  28.9G  0 part

Here sda is the system disk (465GB, mounted at /) and sdb is the target (28.9G, removable, RM=1). Confirm by size and by the RM flag before you continue. Then decompress-and-write in one pipe, so you never store the expanded image:

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

Expected output while it runs and on completion:

2147483648 bytes (2.1 GB, 2.0 GiB) copied, 214 s, 10.0 MB/s
512+0 records in
512+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 215.6 s, 9.96 MB/s

Write to the whole device (/dev/sdb), never a partition (/dev/sdb1). The conv=fsync flag forces the kernel to flush its write cache before dd returns, so the command finishing actually means the data is on the card and not still sitting in RAM. On macOS the device is /dev/rdiskN (the raw node is faster), you unmount first with diskutil unmountDisk, and you replace lsblk with diskutil list.

First Boot & EmulationStation

The media is written. Now you convince the machine to boot from it, which on modern hardware means negotiating with a firmware that would very much prefer to boot Windows. This is menus, but they are unfamiliar menus, so here is the map.

Booting from the Right Device

Plug the flashed media into the target machine and power on while tapping the boot-menu key: usually F12, F11, F9, or Esc on a PC, printed for half a second on the splash screen. Select the USB stick or SD card from the one-time boot menu. If it is not listed, enter the firmware setup (Del or F2) and check two things. First, Secure Boot: disable it, because Batocera's bootloader is not signed with the keys your firmware trusts, and Secure Boot exists precisely to refuse unsigned bootloaders. Second, boot mode: Batocera's x86_64 image is UEFI, so ensure UEFI boot is enabled rather than legacy-only CSM. On a Raspberry Pi there is no BIOS to fight; the Pi boots removable media automatically, and your only job was flashing the correct board image.

The Batocera Partition Layout

On that first boot Batocera does something clever: it resizes its userdata partition to fill the entire card. This is why an 8GB image happily consumes a 256GB card. The layout after first boot is a small read-only system partition and a large writable userdata partition where every ROM, save, configuration file, and scraped image will live. You will interact with userdata constantly and the system partition almost never. If you are curious about the build that produced this layout, the whole thing is open on the batocera-linux GitHub repository, which is also where you file bugs like a functioning member of society rather than shouting into a subreddit.

Controllers, Bluetooth, and the Language Menu

Batocera boots into EmulationStation. A wired USB controller (an Xbox pad is the frictionless default) is detected instantly; press a button and it prompts you to map it. For a Bluetooth controller, the pairing menu lives in the main menu under Controllers Settings. Press START to open the main menu, and while you are there set your language and time zone, because the defaults may not be yours. This START-driven main menu is the same one you will use to update the system later, so learning it now is not a detour. The full menu reference lives in the Batocera wiki, which is more accurate than any video because it is versioned alongside the software.

Adding ROMs and BIOS

Batocera has emulators and no games, by design and by law. Getting your legally-obtained ROMs onto the userdata partition and satisfying the BIOS requirements of the fussier emulators is where most first-day frustration actually lives. There are two routes onto the card, and one legal reality you cannot menu your way around.

The Network Share Route

The moment Batocera is on your network it advertises a share. From another computer, browse to \\BATOCERA on Windows or smb://batocera on macOS and Linux, and you will find the folder tree exposed for you to drop files into. This is the sane way to move a large collection: no re-flashing, no card shuffling, just copy over the network. The share is open on the local network by default, which is convenient and also a reason not to run Batocera on a network you do not control.

The Directory Structure That Matters

ROMs go under /userdata/roms, in a subfolder named for the system, and the folder names are not negotiable because EmulationStation scans for exactly those names:

/userdata/roms/
├── snes/          # Super Nintendo:  .sfc .smc
├── nes/           # Nintendo:        .nes
├── megadrive/     # Genesis/MD:      .md .bin
├── gba/           # Game Boy Advance:.gba
├── psx/           # PlayStation:     .chd .cue/.bin .pbp
└── n64/           # Nintendo 64:     .z64 .n64 .v64

Drop a .sfc into the snes folder, then back in EmulationStation open the main menu with START, choose Game Settings or the Updates and Games menu, and refresh the gamelist (or simply reboot). The system appears on the carousel only when it contains at least one recognised ROM, which is by design: empty systems stay hidden so the interface is not a wall of consoles you own nothing for. If a system refuses to appear, the folder name or the file extension is wrong ninety percent of the time.

BIOS: The Legal and Technical Minefield

Some emulators require the original console's BIOS to function: the PlayStation, the Sega CD, and the Neo Geo are the usual suspects. Batocera cannot ship these, because a console BIOS is copyrighted firmware and distributing it is precisely the kind of thing that gets projects sued. You supply your own, from hardware you own, and you place the files in /userdata/bios. The catch that ruins evenings is that Batocera checks BIOS files by MD5 hash, so a BIOS that is the right console but the wrong revision, or subtly corrupt, will be rejected with a 'missing BIOS' message even though a file is sitting right there. The main menu has a BIOS Checker (under System Settings) that lists exactly which files are needed, their expected MD5, and whether yours match. Use it. It is the single fastest way to diagnose why a PlayStation game boots to a black screen while a Super Nintendo game runs fine.

Updating Batocera

You downloaded 43.1 today, but Batocera does not stand still, and the good news is that you never have to repeat this entire download-and-flash ordeal to move forward. Updates are an in-place operation, and the workflow is documented and stable.

The In-Place Upgrade Path

The Batocera wiki's Updates and Downloads page spells it out: you reach the update options from within EmulationStation by pressing START to open the main menu and navigating to the updates entry. From there Batocera checks its mirrors, tells you whether a newer build exists on your release branch, and downloads and applies it to the system partition without touching your userdata. Your ROMs, saves, and configuration survive the upgrade because they live on a different partition than the one being replaced. This is the recommended path for almost everyone: it is a few button presses and a reboot.

The Command Line, If You Must

Under the graphical menu is a command-line tool. A Batocera wiki page dated 2025-03-13 documents the stable update mechanism through batocera-upgrade against a mirror URL structure, and that workflow remained in active use through 2025 into 2026. If you have an SSH session open (Batocera runs an SSH server; the default login is root with password linux, which you should change), you can run it directly:

batocera-upgrade

Expected output when you are already current looks approximately like:

Checking your version...
Your version: 43.1
Available:    43.1
You are already up to date. Nothing to do.

And when an update exists, it reports the target version, downloads the delta, and instructs you to reboot to apply it. The tool is doing exactly what the menu does; it is simply honest about it.

When Not to Upgrade

The oldest rule in system administration applies: if it works, think before you change it. If your current build runs every system you care about flawlessly, a point release brings you fixes for problems you do not have and, occasionally, a regression for a device that worked yesterday. Read the release notes on the official site before jumping. And always keep your original 43.1 .img.gz somewhere safe, because rolling back means re-flashing, and re-flashing means you want the file you already verified rather than a fresh download and a fresh chance to grab the wrong architecture.

Five Common Pitfalls

Every one of these has cost someone an evening, usually someone who skipped the verification steps because they were in a hurry. Read them now and you will recognise the symptom before it becomes a diagnosis.

Wrong Architecture and Wrong Device

Pitfall 1: The ARM image on a PC (or vice versa). You download beautifully, flash flawlessly, and the machine says 'no bootable device'. The image is fine; it is the wrong species for the CPU. Fix: re-download the x86_64 build for a PC, or the exact board build (bcm2712 for a Pi 5) for a Pi, and confirm the architecture token in the filename before flashing. Pitfall 2: Flashing to the wrong /dev/sdX. With dd especially, selecting your system disk instead of the card overwrites your operating system with a Batocera image and there is no recovery. Fix: run lsblk first, confirm the target by size and the removable (RM=1) flag, and prefer balenaEtcher, which hides system drives, if you are not certain.

Bad Media and Bad Downloads

Pitfall 3: The counterfeit or dying card. A card that reports 256GB but holds 8GB will flash, boot, and then corrupt the instant your data crosses the real capacity, presenting as random save loss and games that vanish. Fix: buy from a reputable vendor, and if a card behaves strangely, test its true capacity with a tool like F3 or h2testw before trusting it. Pitfall 4: The truncated or tampered download. A half-downloaded image or a saved error page flashes into an unbootable card. Fix: this is exactly what gunzip -t (expect exit code 0) and the published SHA-256 catch; run them before flashing, every time, not as a ritual but because they are the cheapest insurance you will ever buy.

Expecting Games, and Fighting Secure Boot

Pitfall 5: Expecting the download to include games. It does not, it will not, and this is the law functioning correctly rather than an oversight; the emulators are legal because they ship without ROMs. Fix: supply your own legally-obtained ROMs to /userdata/roms and the required BIOS files to /userdata/bios, then use the BIOS Checker to confirm MD5 matches. Bonus pitfall: Secure Boot refusing to let Batocera load. Modern PCs ship with Secure Boot on, and it exists to block unsigned bootloaders, which Batocera's is. Fix: disable Secure Boot in firmware setup; it costs you nothing on a machine that boots a game console off a USB stick.

Troubleshooting Table

Symptom-to-fix, for the failures that actually recur. Work top to bottom; the common causes are near the top because the common causes are common.

Advanced Tips

Once the basics boot, Batocera rewards the person who reads its configuration files. These are the moves that separate a working install from a good one.

Split Your Storage: System on Fast Media, ROMs on Slow

The default puts everything on one card, which is simple and slightly wasteful, because your operating system wants speed and your 200GB of ROMs do not. Batocera supports pointing userdata, or specific ROM directories, at a second, larger drive: flash the system to a fast, small USB 3.0 stick, then store the bulk collection on a big external SSD or hard drive that Batocera mounts and reads. This keeps the boot device cheap and replaceable while the collection lives somewhere with room to grow. The wiki documents the share and storage options; the mechanism is a setting, not a hack.

Scraping Metadata Without Losing Your Mind

A wall of filenames is not a game library; a wall of box art with descriptions is. Batocera's built-in scraper (main menu, Scraper) pulls artwork, descriptions, and metadata from online databases and builds the gamelists that make EmulationStation look like the front end it wants to be. Scrape in batches, overnight for a large collection, and pick a single scraping source for consistency so half your library is not one art style and half another. The scraped data lives in userdata and survives upgrades, so you do this once.

Per-Game Overrides and the RetroArch Layer

Batocera exposes per-system and per-game settings on top of the RetroArch cores underneath. You can force a specific core for one troublesome title, change the video shader for a single system, or set a per-game aspect ratio, all from the game's options menu in EmulationStation, without editing a config file. When you do want to go deeper, the core-level behaviour is standard RetroArch, and the authoritative reference is the libretro documentation. Understanding which core does what is genuinely the highest-leverage knowledge in this whole hobby, which is why we keep pointing at the cores walkthrough as required reading rather than optional.

A Complete Working Config

Batocera stores its global settings in a single flat file at /userdata/system/batocera.conf. Almost everything you set in the graphical menus writes here, and you can edit it directly over SSH or the network share for a repeatable, documented setup. Below is a complete, sane starting configuration for an x86_64 machine on a wired network, with an Xbox-style controller, HDMI audio, and a couple of quality-of-life defaults. Comment lines begin with a semicolon; keys not present fall back to Batocera's own defaults.

############################################
# /userdata/system/batocera.conf
# Batocera 43.1 - x86_64 - working baseline
############################################

; ---- System / locale ----
system.language=en_US
system.timezone=Europe/London
system.hostname=BATOCERA
system.power.switch=PC

; ---- Networking (wired preferred) ----
wifi.enabled=0
system.samba.enabled=1
ssh.enabled=1

; ---- Audio: force HDMI out ----
audio.device=auto
audio.volume=90
audio.bgmusic=0

; ---- Video / display ----
system.video.screens.mode=default
global.videomode=default
global.bezel=default
global.integerscale=1
global.smooth=0

; ---- Global emulator defaults ----
global.retroachievements=0
global.rewind=1
global.autosave=0
global.ai_service_enabled=0

; ---- Per-system overrides ----
; PlayStation: use the HW core, needs a matching BIOS in /userdata/bios
psx.core=swanstation
psx.videomode=default

; N64: prefer the accurate path over the fast one
n64.core=parallel_n64
n64.video_threaded=1

; SNES: default core is fine, force integer scale
snes.integerscale=1

; ---- Scraper defaults ----
scraper.source=ScreenScraper
scraper.language=en

; ---- Updates: stay on the stable branch ----
updates.enabled=1
updates.type=stable

Drop that in, reboot, and you have a machine that comes up on the right language, shares its ROM folders over the network, keeps SSH available for maintenance, and pins itself to the stable update channel so your next upgrade brings you the successor to 43.1 rather than a nightly experiment. Change the timezone and hostname to taste. The one line worth defending is updates.type=stable: you did the work to download and verify a stable release today, and there is no reason to let the machine wander off that path on its own.

That is the whole procedure, from an empty USB stick to a configured console, using the exact 43.1 image the project publishes as of 2026-08-23. The download was always the hard part. Everything after it is just a machine doing what free software, asking nothing of you, was quietly built to do.