Blue Recorder is a Rust screen recorder built on GTK4 and FFmpeg

A recorder you configure, rather than one you press once

Blue Recorder is described as a simple desktop recorder built using GTK4 and FFmpeg, and the project says it is based on Green Recorder and rewritten in Rust with improvements.

The feature list is short and each line describes a choice the user makes. It supports recording audio and video on Windows and almost all Linux and FreeBSD interfaces, with support for the Wayland display server on GNOME and KDE sessions. The formats currently supported are avi, gif, mkv, mp4, nut, webm and wmv. You can choose the audio input source you want from the list. And you can set the default values you want by simply changing them in the interface, and the program will save them for you for the next time you open it.

That last point is the one that separates it from a screenshot key. A recorder that remembers your chosen format, your audio source and your other defaults is a tool for someone who records regularly, and the README's framing, a simple desktop recorder, understates how opinionated the saved-settings behaviour is.

The primary language is Rust, the repository is not archived, the last push was on 2026-06-25, and the one tagged release is v0.3.0 from 2026-06-21.

Install as a Snap or a Flatpak

For most people the install is a package, not a build. Blue Recorder is available as a Snap and Flatpak package, and the README links both the Snap Store listing and the Flathub entry, whose application identifier is `sa.sy.bluerecorder`.

The Flatpak route is the more interesting one for a Linux user, because it resolves the dependency list described later in this article in a single step, and it is the only route that gives you a working recorder without installing PipeWire, GStreamer and GTK development files on the host.

The Snap is the older packaging, and the repository carries both a `snap/` and a `flatpak/` directory, so the packaging is maintained in tree rather than living elsewhere.

What neither route gives you is the ability to pick up a patch or change the defaults at build time. For that, the README has a build from source section, and the next part of this article covers what it actually takes.

The dependency list is short and specific

Blue Recorder depends on ffmpeg, gstreamer, libadwaita, pipewire and pipewire-pulse, with xwininfo needed on X11 only, for area selection.

That list explains most of the project's design. PipeWire and PipeWire Pulse are how modern Linux desktops route audio, and a recorder that captures system sound has to sit on that pipeline rather than on ALSA. GStreamer does the muxing and encoding work, FFmpeg is the encoder, and libadwaita is the widget library behind the GTK4 interface, so the interface matches the rest of a GNOME or libadwaita desktop.

The xwininfo entry is the one that is conditional, and it is worth understanding why. On X11, selecting a region of the screen by dragging a rectangle requires querying the window geometry, and xwininfo is the tool that answers that question. On Wayland, the compositor does not hand out that information the same way, which is why the dependency is marked as X11 only, and why area selection is not the same feature on every session type.

For a user on Fedora or Arch with GNOME, all of these are already installed or one package away, and the Flatpak avoids the question entirely. For a user on a minimal system, the list is the build instructions.

Three platforms, three package managers

The build from source section gives one command per platform family.

On Ubuntu and Debian based distributions:

sudo apt install build-essential cargo clang ffmpeg gstreamer1.0-plugins-good libadwaita-1-dev libgstreamer1.0-dev libpipewire-0.3-dev pipewire-pulse pulseaudio-utils x11-utils

On FreeBSD:

sudo pkg install ffmpeg gstreamer1 libadwaita llvm pipewire pulseaudio rust xwininfo

On Windows, with the winget package manager:

winget install BrechtSanders.WinLibs.POSIX.MSVCRT Git.Git Gyan.FFmpeg LLVM.LLVM Rustlang.Rustup wingtk.gvsbuild.GTK4

The Windows line is the interesting one, because it pulls in a POSIX runtime and a prebuilt GTK4 package, since a Rust application on Windows still needs the GTK libraries. The README then has a Windows only step, switching to the GNU toolchain:

rustup default stable-x86_64-pc-windows-gnu

That is the toolchain the prebuilt GTK4 package expects, and getting it wrong produces link errors rather than anything that names the cause.

Cargo builds it, and you copy the data next to the binary

The final build sequence is the same everywhere:

git clone https://github.com/xlmnxp/blue-recorder
cd blue-recorder/
cargo build --release
cp -a data gui/interfaces locales target/release

The third line is the part that is easy to miss. The executable alone is not the application. The `data` directory holds the application's resources, `gui/interfaces` holds the interface definitions, and `locales` holds the translations, and the `cp -a` copies all three next to the built binary.

After that, the README says you will find the executable file at `blue-recorder/target/release/blue-recorder`.

Copying rather than installing is a deliberate simplification for a manual build, and it has a consequence: an upgrade is a fresh clone, a fresh build and a fresh copy, and there is no package manager step in between. The Snap and Flatpak packages exist precisely to avoid that.

The repository layout explains the rest. The `Cargo.toml` at the root is a workspace with two members, `core` and `gui`, so the recording logic and the interface are separate crates, and the top level also carries `data/`, `locales/`, `flatpak/`, `snap/`, `screenshots/`, a `cliff.toml` for generating the changelog, a `CHANGELOG.md` and a `Cargo.lock`.

Where a screen recorder stops being the right answer

Two cases stand out.

The first is a one-off. If you need a screenshot of a window on a modern desktop, the desktop already has a recorder, and on a Wayland session the compositor's own recorder is a single keypress away with no installation, no format list and no audio source picker. Blue Recorder earns its place when you record often enough to want the defaults remembered, and when you want to choose the container and the audio device rather than accept what the compositor offers.

The second is coverage. The README says Wayland support is for GNOME and KDE sessions, and the X11 only entry for xwininfo covers area selection. So on a compositor outside those two, the project is not claiming to work, and the area selection feature is tied to X11. That is a narrower claim than the phrase almost all Linux and FreeBSD interfaces suggests, so check your session type before installing.

A third case is editing. This is a recorder, not an editor, and the README describes no trimming, no annotation and no post-processing. The alternative approach for anything beyond capture is to record and cut elsewhere.

What Blue Recorder gives you in exchange is a small Rust codebase with a two crate workspace, an explicit format list, a selectable audio source, and settings that survive between sessions. For a Linux user whose desktop recorder cannot capture system audio, that is a real reason to install it.

Editorial conclusion

Adopt Blue Recorder when you want a recorder you drive yourself, with a choice of output format, a selectable audio input and settings that persist between sessions, and when you are on Linux with PipeWire and GStreamer present. Do not adopt it for a one-off screenshot on a modern desktop, where the built-in recorder is one keypress away, and do not assume full Wayland coverage, since the README names GNOME and KDE sessions specifically. Verify first that your distribution provides PipeWire, PulseAudio and GStreamer, that the audio source you want is listed in the interface, that the output format you need is one of the seven the README lists, and that the licence file in the repository matches GPL-3.0-only before you redistribute a build of it.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. xlmnxp/blue-recorder on GitHub