Merrit/nyrna: a console style suspend button for games and long jobs on the desktop

A console's suspend button, on a desktop

Nyrna suspends games and applications, and the analogy the project draws is the one that explains the whole idea. It is similar to the incredibly useful sleep and suspend function found in consoles like the Nintendo Switch and Sony PlayStation. You suspend your game, and its resource usage with it, at any time, and resume whenever you wish, at the push of a button.

That analogy is doing more work than marketing usually allows. On a console, suspending a game is a first class operation that the platform, the title and the hardware all cooperate with. On a desktop, none of that exists. A game keeps running, keeps its frame budget, keeps its audio, and a cutscene cannot be paused. A render keeps the CPU and the GPU busy for hours while you want the machine for something else.

What Nyrna does is freeze the process, in a way that keeps its state, and stop it consuming CPU and GPU time. When you resume, it is where it was. The README's phrasing for applications is that the CPU and GPU resources are being used by said task, maybe for hours, when you would like to use the system for something else, and with Nyrna you can suspend that program, freeing up the resources, excluding RAM, until the process is resumed, without losing where you were, like the middle of a long job or a gaming session between save points.

That parenthetical about RAM is the important technical caveat, and it is the difference between this and a swap file or a hibernate feature. The CPU and the GPU stop working. The memory stays allocated, because the process is still there, still holding its pages, just not running.

The game cases are the ones people write about

The README lists four game situations, and they are specific enough to show that the tool was built around real frustrations.

You can pause cutscenes to read the subtitles, examine the scene, or answer the door, which is a problem that a conventional pause menu cannot solve because the cutscene is not in a pausable state.

You can pause games that cannot normally be paused, and the examples given are single player games like Dark Souls and Elden Ring. Being able to stop one is exactly the kind of small convenience that turns a console habit into a desktop requirement.

You can suspend games whose pause screens keep the system running hot or playing unwanted music, which is a different problem again, the game is technically paused but the process is still doing work, and suspending it is the only way to get the machine quiet.

And you can suspend in between checkpoints, with Hollow Knight given as the example, which is the framing that makes the feature safe to use. Suspending at a save point rather than in the middle of a fight is the difference between parking a process and corrupting it.

That last point is the pattern to follow, and the four examples together describe a tool for the gaps in a game rather than for the middle of one.

The application case is the bigger one

The README is clear that Nyrna can be used to suspend normal, non-game applications as well, and it gives three examples: 3D renders, video encoding and software compilation.

These are the cases where the value is obvious and the risk is lowest. A 3D render is a job with a defined output and no interactive state, a video encode is the same, and a software compilation is a build you would otherwise have to leave running while you do something else on the same machine. All three are cases where the work is long, the intermediate state is recoverable by re-running, and the machine would rather be doing something else for a while.

That is a different proposition from pausing a game, and the difference shows in the risk profile rather than in the mechanism. Suspending a compiler mid-build and resuming it is a much smaller risk than suspending a game that is halfway through a save, and the project does not pretend otherwise, because the disclaimer applies to all of it.

The practical constraint is the one already noted. Suspending frees the CPU and the GPU but not RAM, so a render that needed eight gigabytes of memory still needs that eight gigabytes to stay allocated while it is parked. On a machine with a small amount of memory, that is a real limitation, and the README does not claim otherwise.

The crash disclaimer is the whole risk story

The disclaimer section is short, and it is the most important thing in the README for a prospective user.

Modifying running applications comes with the possibility that the application will crash. While this is rare, it is a known possibility that Nyrna can do nothing about. Please make sure to save your data or game before attempting to use Nyrna.

The structure of that statement matters. The project does not claim to be safe, and it does not claim the failure rate is low, it says the failure is rare and known, and it says explicitly that Nyrna can do nothing about it. The cause is in the first sentence. Modifying running applications is the mechanism, and any mechanism that reaches into a process and suspends it is inherently in a category where the application's assumptions about its own state can be broken.

So the guidance to save your data is not boilerplate caution, it is the operating procedure. For a game that writes a save file periodically, suspending between checkpoints is the sensible usage. For an application with unsaved work, the sensible usage is to save first and accept the residual risk.

What the project does not do is offer any guarantee to lean on. There is no configuration to make it safe, and the FAQ confirms that the feature set is narrow, so the risk has to be managed by when you use it rather than by how you configure it.

Why suspend to disk is not on the table

The FAQ contains one question and its answer is the most technically interesting text in the repository.

Can I suspend to disk so that I can restore after a reboot, or free up RAM usage? Unfortunately no. CRIU looks very promising to allow this on Linux, however it does not currently support suspending GUI applications, with a link to the CRIU page on X applications.

The reasoning is clean. Suspend to disk would mean serialising a process's memory to storage and restoring it later, which is what a checkpoint and restore system does, and CRIU is the well known implementation of that idea for Linux. The blocker is the GUI, because a graphical application has a connection to a display server, and restoring that connection, along with the graphics driver state, is not something CRIU handles.

That explains the RAM caveat as well. A process that is suspended rather than restored has to stay resident in memory, because its pages have to remain valid for the resume to work. Only a full checkpoint to disk, and a restore into a fresh boot, would allow the memory to be reclaimed, and that is exactly the case this project cannot support for graphical applications.

So the design has one boundary and one reason, and the README is upfront about both.

A Flutter application, packaged for two platforms

The repository layout is a Flutter project, which is visible in the tree and in the configuration files. There is a `lib/` directory for the Dart code, `linux/` and `windows/` directories for the two platform runners, `packaging/` and a `snap/` directory for distribution, `test/` for the tests, and `assets/` and `images/` for resources.

The Flutter tooling is present too, with `pubspec.yaml` and `pubspec.lock`, `analysis_options.yaml` and `devtools_options.yaml` for the analyser, and `l10n.yaml` for localisation, which is the tool that generates the translation files for the app's strings. There is a `.devcontainer/` directory and a `.vscode/` directory, so a contributor can work in a container with the editor already configured, and a `BUILDING.md` that the README points to for build instructions. `ATTRIBUTION.md` and `PRIVACY_POLICY.md` are also in the tree, which is unusual and welcome for an application that suspends other processes.

The website lives in the repository as well, with a `CNAME` file and a `_config.yml`, which are the GitHub Pages configuration for the site at nyrna.merritt.codes, and the install options are served from the download page on that site rather than being described in the README.

On the state of the project, the releases are v2.27.0 on 2026-03-21, v2.27.1 on 2026-05-01 and v2.27.2 on 2026-05-26, and the last push was on 2026-05-26, with the repository not archived and the licence GPL-3.0.

Editorial conclusion

Adopt nyrna if you have a game that cannot be paused or a long job such as a render or a compile that you want to park without losing its place, since a real suspend that preserves state is something neither the operating system nor the applications themselves offer. Do not adopt it as a memory management tool, since the README is explicit that RAM is not freed, and do not adopt it if a crash of the target application would cost you work, because the disclaimer says exactly that this can happen. Verify first that your Linux session is X11, since the README states support for Linux with X11 and does not mention Wayland, that you have saved anything the suspended application holds, and that on Windows you can run it as an administrator, which the troubleshooting section says resolves most issues there.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Merrit/nyrna on GitHub
3. Project website
4. README
5. Releases