Checkpoint for 3DS and Switch: save backup, restore and scripting

What Checkpoint solves on a 3DS or Switch

Consoles do not expose save data as ordinary files. A save belongs to a title, sometimes to an extdata archive, sometimes to a cartridge, and the console's own menus give you no way to copy it out. Checkpoint exists to close that gap: it backs up and restores save data for 3DS cartridges and digital titles (including demos), extdata, DS cartridges, DSiWare and GBA Virtual Console titles, and on Switch for the titles you have played, with title information loaded automatically.

The audience is narrow and specific. You need a console running homebrew, launched through the Homebrew Launcher or an equivalent entry point, and you need to care about save data rather than game files. The README states that Checkpoint does not rely on external title lists or filters: titles are detected and filtered automatically, so it does not need constant user maintenance to retain full functionality. That is a real design decision, not marketing. Tools that ship a static title database break when a new game appears or a title ID changes; Checkpoint's approach avoids that class of breakage entirely.

The mechanism: native save access plus an on-console C interpreter

Checkpoint is a C++ application built for two targets. The top-level Makefile defines two subdirectories, 3ds and switch, and delegates to a Makefile in each, passing version numbers down. A shared common/ directory and a 3rd-party/ directory hold code used by both builds.

On the console side, the app opens a title's save (or 3DS extdata, or console-wide shared extdata), then reads, writes, deletes, lists and commits files inside it, and creates, renames or removes folders. Backups and restores run on a worker thread, and the README notes that backups can be cancelled while in progress. On Switch the rendering backend is built on deko3d, which the README says makes the application about 70% smaller than before, and the app supports 1080p docked mode alongside 720p in handheld.

The unusual part is the scripting engine. Scripts are C files interpreted on the console by picoc, with no compiler, no rebuild and no reflash. A script is a single .c file placed in the right folder on the SD card; it appears in the Scripts menu (SELECT on 3DS, Minus on Switch) the next time the app launches. Scripts include checkpoint.h and reach the same machinery the app uses: the title catalog, save data access, SD card listings and mkdir -p, zip packing and unpacking, HTTP GET and full requests with streamed file uploads, JSON parsing, and UI primitives such as messages, confirmations, pickers, keyboard and numeric keypad, a status line and nested progress bars. A running script owns the screen, output streams into a scrollable log pane, and holding B aborts any script, including one stuck in an infinite loop, without rebooting the console. That abort guarantee matters when you are running third-party scripts you did not write.

Installing Checkpoint and taking a first backup

The README's Usage section begins with "You can use Checkpoint for 3DS" and is truncated in the repository text, so the exact installation walkthrough is not reproduced in full. What the repository does establish is that releases are published on the GitHub releases page, that the latest release is v5.2.0 (dated 2026-08-26), and that the project builds from source through the top-level Makefile. There is no package manager install and no documented standalone installer.

If you build from source, the top-level Makefile is the entry point. It defines version 5.3.0 and forwards version numbers to each platform build:

make 3ds
make switch

Those targets call the Makefile in each subdirectory with VERSION_MAJOR, VERSION_MINOR, VERSION_MICRO and GIT_REV. If git is unavailable, GIT_REV falls back to the literal string unknown. The Makefile also defines cli, which builds the chlink companion from tools/chlink:

make cli

There is a host-side test target as well. The Makefile comment states these tests run on the build machine, not on hardware, and points to tests/Makefile for coverage details:

make test

The README does not list the toolchain, libraries or devkit versions a from-source build requires, so treat the build as the least documented path. For most users the release binary is the intended route.

Once Checkpoint is running, the first real use is a backup. Pick a title from the list, choose the backup action, and the operation runs on a worker thread; the README states a backup can be cancelled while it is in progress. Backups land in a per-title folder on the SD card. Before writing your own script, the README recommends parse-checking it on your PC with tools/scriptlint.sh, which catches syntax problems without a round trip to the console.

Where Checkpoint stops being the right tool

Checkpoint manages saves. It is not a general file manager, not a game installer, and not a cheat engine in its own right. Cheats arrive through the bundled sharkive script, which downloads the Sharkive database, lets you tick cheats per title, and writes the cheat files Luma3DS (3DS) or Atmosphere (Switch) expect. If you want cheats without a save-management layer, you are pulling in a whole application to get a database download and a file write.

The scripting engine is also not a general-purpose runtime. It is C interpreted by picoc, with the interpreter's limits and the API reference documented in scripts/README.md rather than the main README. That split matters: the top-level README advertises the scripting capability and lists the API areas, but the constraints, the interpreter's limits and the authoring checklist live in a separate file. Anyone evaluating the scripting engine from the README alone is reading the sales pitch, not the specification.

The README is likewise silent on save format compatibility. It does not say whether a backup taken by one version restores under an older one, whether a Switch save backup can be moved to a different console, or what happens when a title's save layout changes after a game update. Those are the questions that decide whether a backup is worth keeping, and the README does not answer them. Treat the first backup you take as unverified until you have restored it yourself.

chlink and the wireless path versus the MTP path

Checkpoint offers two ways to get backups off the console, and they are genuinely different approaches rather than two names for one thing.

chlink is a companion command line app for your PC that talks to Checkpoint's wireless save transfer feature. It sends backups from your PC to the console and receives backups from the console to your PC over the local network, with no cables and no SD card swapping. Transfers are protected by a 4-digit PIN displayed on the console, and chlink automatically recognizes backups coming from a Checkpoint SD card layout, so title and backup information are filled in for you. It is a single, dependency-free executable for Windows, macOS and Linux, downloadable from the releases page or buildable from the tools/chlink folder.

The alternative is Switch-only: a USB MTP server that makes the console show up as a portable device on your PC, so you can drag backups off over the charging cable with no network involved. The trade-off is direct. MTP needs a cable but no network configuration and no PIN exchange; chlink needs both machines on the same network but works with the console sitting anywhere in the room, and it is the only one of the two that can push a backup from the PC back to the console. The README does not state whether chlink works with 3DS consoles, only that it talks to the wireless save transfer feature, so verify that pairing before you plan around it.

Checkpoint also runs a background FTP server for direct access to save backups from a PC, and an HTTP log server that lets you view Checkpoint's logs in real time from any browser on your network. Three network services in one homebrew app is a lot of listening sockets; the README does not describe authentication on the FTP or log servers, so decide whether you trust your local network before leaving them enabled.

Bundled scripts, and what writing your own actually requires

The bundled scripts are the clearest picture of what the engine can do. browser is a file browser for the SD card and for a title's live save archive, supporting copy, move, rename, delete, folder creation, properties, zip and unzip, one item or a batch at a time, with either side of a transfer on the card or inside a save. sharkive handles cheats. googledrive backs up your save backups to your own Google Drive with a device-code sign-in and per-backup zips. webdav does the same for any WebDAV server you already have, naming Nextcloud, Synology and rclone serve webdav as examples, uploading only what is not already there and able to download a backup back onto the console. The 3DS-only scripts cover narrower ground: playcoins sets the console's Play Coins, extdata creates the extdata archive a title has never written so an extdata backup has somewhere to restore into, and notifications backs up and restores everything behind the Notifications applet, the SpotPass content and the notification list alike.

That extdata script is the most interesting entry because it exposes a failure mode the app itself cannot fix. If a title never wrote extdata, there is nothing to back up and nothing to restore into; the script manufactures the archive first. The README presents this as a feature, and it is, but it also means extdata restores can depend on running the right script in the right order rather than on Checkpoint's own menu.

Writing your own is documented in scripts/README.md, which the README describes as containing the API reference, the interpreter's limits, recipes, and a checklist for both human and AI authors. scripts/examples/example.c is described as a runnable guided tour with one menu entry per API area. The workflow is: write a .c file, parse-check it with tools/scriptlint.sh on your PC, copy it to the SD card, then launch Checkpoint and open the Scripts menu. If a script misbehaves, holding B aborts it. That is a workable loop, and it is unusual for console homebrew to offer one at all.

Maintenance, licensing and the cost of tracking releases

The repository is not archived, and the last push was on 2026-08-30. Three releases landed in the two months before that: v5.0.0 on 2026-07-26, v5.1.0 on 2026-08-12, and v5.2.0 on 2026-08-26. The top-level Makefile already declares version 5.3.0, so the source tree is ahead of the published release. That is a normal pattern for a project that tags after merging, but it means building from master gives you a version you cannot match to a release note.

The upgrade cost is mostly on the script side. Scripts are C files on the SD card that include checkpoint.h and call into the app's API. The README does not state whether that API is versioned or whether scripts compiled against one release keep working on the next, and it does not document rollback. If you maintain scripts, pin the Checkpoint release you tested against and re-run tools/scriptlint.sh after upgrading, because the linter is the only pre-flight check the README names.

Licensing is GPL-3.0. That is a copyleft licence, and it applies to the whole project, including the scripting API headers and the bundled scripts. If you plan to distribute a modified Checkpoint build, or to ship a script as part of a larger product, the licence terms govern what you must do with your source. This article is not legal advice; read the LICENSE file in the repository root and, for anything commercial, get your own counsel. The practical point for individual users is simpler: running Checkpoint on your own console is not distribution.

Editorial conclusion

Checkpoint fits anyone with a homebrew-enabled 3DS or Switch who wants save backups, restores and scripted extras such as Sharkive cheat files or WebDAV sync, and who accepts that the README documents neither build prerequisites nor save format compatibility. Verify the licence terms for your own distribution plans, and check the scripts/README.md API reference before writing a script, because the README does not document the interpreter's limits.

Frequently asked questions

Official sources

1. BernardoGiordano/Checkpoint on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases