soirihiroka/shrimply: a pre-alpha Rust video editor that demands an Nvidia or Apple Silicon GPU

What Shrimply is, and who the pre-alpha label excludes

Shrimply is a cross-platform video editor whose main application is written in Rust. The README describes it as "a simple yet powerful cross-platform video editor", and the repository layout backs that up: the Cargo workspace lists crates for export, paint, audio, transcription, text to speech, 3D Gaussian splatting, and a Blender bridge, alongside separate binaries for GTK, Qt and AppKit front ends. This is not a wrapper around an existing editor. It is a new application with its own project model, its own render pipeline and its own GPU backends.

The stated system requirements are narrow: an Nvidia or Apple Silicon GPU, and Wayland or macOS 15 or newer. That rules out Intel integrated graphics, AMD GPUs on Linux, X11 sessions, and any Mac older than the macOS 15 cutoff. The README is equally direct about maturity. It says Shrimply is pre-alpha software and lists what to expect: "Slop", "Undocumented footguns", "Random performance regressions", "Irreversible project file breakage", "Random crashes and resource leaks". Those are the project's own words, not an outside assessment.

So the audience is specific. You are a Linux or macOS user with a discrete Nvidia card or an Apple Silicon Mac, you are comfortable building software from source or installing a Flatpak, and you are editing footage that you can afford to lose. Anyone with a deadline and a client should read the next few sections before downloading anything.

How the Rust workspace splits rendering, media and the interface

The Cargo workspace is the clearest map of the architecture. Interface code lives under crates/ui and crates/binaries: editor-gtk, editor-qt, editor-appkit, launcher-gtk, launcher-qt, launcher-appkit, plus export front ends for each toolkit. GPU work is split by vendor: gpu-vulkan, gpu-metal, gpu-cuda, and denoise-metal. Rendering and export sit in crates/render/export with export-core, export-cuda and export-metal. Media handling is split by kind: crates/media/audio holds audio-engine, audio-modifiers, lip-sync, transcription and tts, while crates/media/visual covers paint, background and a Manim pipeline with manim-ir, manim-state and three backends (manim-wgpu, manim-cuda, manim-metal).

The README names the stack those crates are built on: GTK 4 and libadwaita for the interface, Skia, wgpu, Slang and CUDA for rendering, FFmpeg and PipeWire for media, and a Python compute server. The Dockerfile shows the same split from the packaging side. It builds on Fedora 44, pulls FFmpeg from RPMFusion, installs CUDA from Nvidia's Fedora repository, and then runs make release and make qt-release before installing with make install install-qt. There is a step that symlinks libcuda.so into the CUDA stubs directory, because the container has no Nvidia driver. That is a build-time workaround, not a runtime one.

The result is a layered design where the editor front end is replaceable and the GPU backend is not. You do not choose between GTK and Qt based on taste alone: the Dockerfile builds both, but the CUDA dependency is unconditional in that path. The Python compute server is mentioned in the README as a component, and the workspace has a server/ directory at the top level, but the README does not describe its protocol or what runs inside it.

Installing Shrimply: Flatpak, macOS build, or source

The README does not carry install instructions in the repository itself. It points to the documentation site, specifically the Getting Started page at https://shrimply.pages.dev/getting-started.html for installation and the Development page for building from source. The releases page lists two artifacts: a macOS build tagged macos-20260914T032230Z and a Flatpak prerelease tagged flatpak-34801497087-1. If you are on macOS 15 or newer with Apple Silicon, the macOS release is the shortest path. If you are on Linux with an Nvidia GPU, the Flatpak prerelease is the packaged option.

Building from source is documented through the Makefile, which pins the toolchain rather than relying on your default:

export RUST_TOOLCHAIN=nightly-2026-04-03
make release qt-release
make install install-qt DESTDIR=/stage PREFIX=/usr

The Makefile sets RUST_TOOLCHAIN to nightly-2026-04-03 by default, so the first line above is only needed if you want to override it. The release targets build both the GTK and Qt front ends. The install targets place binaries under the prefix you pass; the Dockerfile uses /stage and /usr. Dependency installation is a separate target, and the Dockerfile calls it with an explicit package manager:

make deps-fedora DNF="dnf -y"
make qt-native-deps

On Fedora, deps-fedora installs the system libraries and qt-native-deps adds the Qt build dependencies. The Dockerfile also installs cuda-toolkit from Nvidia's repository and sets CUDA_HOME and CUDA_TOOLKIT_PATH to /usr/local/cuda. If your CUDA lives elsewhere, the Makefile accepts CUDA_HOME as an override. After a successful build you should find shrimply, shrimply-editor, shrimply-mcp, shrimply-qt and shrimply-editor-qt under the install prefix's bin directory; those are the five binaries the Dockerfile bundles runtime libraries for.

The GPU requirement is a hard boundary, not a preference

Most video editors degrade gracefully. Shrimply does not, at least not according to its own documentation. The README states the system requirements as an Nvidia or Apple Silicon GPU and Wayland or macOS 15 or newer, with no fallback listed. On Linux, an AMD card or an Intel iGPU is outside the stated support envelope. On macOS, anything below version 15 is outside it. On Linux, an X11 session is outside it, even with the right GPU.

That constraint is structural. The workspace contains gpu-cuda, gpu-metal and gpu-vulkan crates, but the README's requirement line names Nvidia and Apple Silicon specifically, and the Dockerfile installs the CUDA toolkit unconditionally in its build path. The Vulkan crate exists in the workspace, yet the README does not present Vulkan as a supported configuration for end users. Whether that is a documentation gap or a real limitation is not something the README resolves, and the documentation site is where you would have to check.

The second boundary is data safety. "Irreversible project file breakage" is listed among the expected behaviours of pre-alpha software. That phrase matters more than the crash warnings, because a crash costs you a session and a broken project file can cost you the edit. There is no rollback mechanism described in the README, and no migration or versioning scheme for project files is documented there either. If you keep the only copy of a project in Shrimply's format, the project's own warning tells you what can happen to it.

Shrimply against Kdenlive and Shotcut

Kdenlive and Shotcut are the obvious comparisons for a Linux-first editor, and the difference is in the rendering path. Both are built around MLT and FFmpeg, run on CPUs as well as GPUs, and treat hardware acceleration as an optimization rather than a requirement. Shrimply inverts that: the GPU is the assumed execution target, with dedicated CUDA and Metal crates for export and denoise, and a Slang shader path in the stack. On an Nvidia machine that inversion is the point. On anything else it is a wall.

The second difference is scope. Kdenlive and Shotcut are mature projects with documented project file formats and years of importers. Shrimply's workspace includes a transcription crate, a text to speech crate, a lip-sync crate, a 3D Gaussian splatting crate and a Manim bridge, which suggests generative and analysis features that the MLT-based editors do not ship as core components. The README does not document how those crates surface in the UI, so treat the crate list as architecture, not as a feature list.

The third difference is the interface toolkit. Kdenlive and Shotcut use Qt. Shrimply builds GTK and Qt front ends from the same core, and adds an AppKit front end for macOS. That is unusual, and it means the editor logic is decoupled from the widget layer. It also means the GTK and Qt builds can diverge in behaviour, and the README does not say which one is the reference implementation.

Licence: GPL-3.0 with non-free dependencies

Shrimply is licensed under the GNU General Public License, version 3 or later. The README is explicit that this covers Shrimply itself and not everything it links against. It names Nvidia's CUDA Toolkit and display driver, the OptiX SDK, the Optical Flow SDK and the Video Codec SDK, plus separately licensed model weights, as components that retain their own licence terms. It points to docs/source/licenses.rst and THIRDPARTY.md for details.

The practical consequence is that a GPL-3.0 application with mandatory CUDA and OptiX components is not straightforwardly redistributable by third parties, and the Dockerfile's use of RPMFusion's nonfree repository for FFmpeg codecs is part of the same picture. That is a packaging question rather than a legal one, and it is why the project ships a Flatpak rather than a distribution package. If you plan to redistribute a build, read THIRDPARTY.md before you do, and take your own advice on the licence question rather than this article's.

On maintenance cost, the repository's last push was on 2026-09-14, two days before this writing, and both listed releases carry the same date. The Makefile pins a nightly Rust toolchain, nightly-2026-04-03, which means a source build is tied to a specific nightly rather than stable Rust. CUDA_TARGET defaults to sm_86, so older Nvidia generations are not the default target. Expect to re-read the Makefile when the pinned toolchain moves.

What to verify before you commit a project to Shrimply

Check three things in order. First, confirm your GPU and session: Nvidia or Apple Silicon, and Wayland or macOS 15 or newer. If any of those is false, stop, because the README lists no fallback. Second, read the Getting Started page on shrimply.pages.dev, since the repository README defers installation there and does not repeat the steps. Third, decide how you will protect project files given the README's warning about irreversible breakage. The project documents no rollback, so the protection has to come from your side: keep exports and keep copies.

If you build from source, run make deps-fedora with your package manager before make release, and verify the toolchain the Makefile pins rather than your system default. The Dockerfile is a working reference for the full dependency chain on Fedora 44, including the CUDA repository setup and the libcuda.so symlink that lets the build proceed without a driver. Reading it is faster than discovering each missing package one at a time.

The honest summary: Shrimply is a serious piece of engineering with an unusually broad workspace, and it is also software that tells you it will break your project files. Both statements come from the same README, and you should weigh them together.

Editorial conclusion

Adopt Shrimply only if you have an Nvidia or Apple Silicon machine, run Wayland or macOS 15 or newer, and are willing to lose work to project file breakage while the project is pre-alpha. If you need to deliver video on a deadline, use something else until the release notes stop describing irreversible project file breakage. Before you start, read Getting Started on the documentation site, confirm your GPU vendor, and archive your project files after every session.

Frequently asked questions

Official sources

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