StemDeck: a local, no-account stem splitter for musicians

The problem StemDeck targets: separation without an upload

Most stem separators are services. You send a file to someone else's machine, wait, and download the parts. That model brings an account, a quota, and a copy of your material on hardware you do not control. StemDeck inverts it. The README states the project is "Free, local stem separation. No account. No upload. No subscription." The processing happens on your own computer.

The audience is narrow and specific: musicians, producers and hobbyists who already own the audio they want to split, and who want vocals, drums, bass, piano and guitar as separate files for practice, transcription, remixing or other creative work. The README is explicit that this is a separation tool rather than a downloader, and that YouTube import is a convenience for content you have the right to process. If your workflow depends on pulling arbitrary tracks off the internet, that is not what this project is for.

Demucs htdemucs_6s behind a FastAPI service

The separation engine is Demucs, specifically the htdemucs_6s checkpoint, which is the six-source model. Six stems are the ceiling, and the README names them: vocals, drums, bass, guitar, piano, other. That is a different proposition from four-stem tools, where guitar and piano tend to end up smeared into an "other" bucket. Whether six outputs are genuinely cleaner than four depends on the model, not on the interface, and the README does not publish accuracy figures.

Around the model sits a Python service. pyproject.toml lists fastapi and uvicorn as dependencies, so the backend is an HTTP service, and the repository has an app/ directory alongside static/ and templates/. The frontend is deliberately plain: package.json describes itself as existing only so CI can drive a real browser, and notes that "the app itself has no build step and no runtime dependencies." Static JavaScript is served directly rather than compiled through a bundler. For a self-hosted tool that is a reasonable trade: fewer moving parts, and no Node toolchain required to run the thing.

The dependency pins are where the real engineering shows. Demucs is held below 4.1 because, per the pyproject comments, demucs 4.1.0 added a dependency on a native package with no Intel-macOS wheel, so the x64 macOS build compiles from source and fails. torch and torchaudio are held to the 2.6.x line because torchaudio 2.7 removed its built-in audio writer and Demucs 4.0.1 calls torchaudio.save() to write stems. Intel macOS gets an older torch line entirely, since PyTorch does not publish 2.6.x wheels for that platform. These are constraints, not preferences, and they mean StemDeck is more sensitive to your environment than a pure-Python tool would be.

Installing StemDeck and splitting a first file

The repository ships a run.sh at the top level and a packaging/ directory, and pyproject.toml requires Python >=3.10,<3.14. The README does not spell out a full manual install sequence, so the honest starting point is the project's own site and release page rather than a command invented here. What the repository does tell you is the shape of the environment: a Python 3.10 to 3.13 interpreter, FastAPI and uvicorn, and a Demucs install that must respect the pins.

The dependency block in pyproject.toml is the contract you have to honour, and it is written as constraint strings rather than install commands. The non-Intel-macOS path is:

"fastapi>=0.115,!=0.136.3"
"uvicorn[standard]>=0.30"
"yt-dlp>=2026.7.4"
"demucs>=4.0.1,<4.1"
"torch>=2.6,<2.7; sys_platform != 'darwin' or platform_machine != 'x86_64'"
"torchaudio>=2.6,<2.7; sys_platform != 'darwin' or platform_machine != 'x86_64'"

On Intel macOS the torch line changes, because PyTorch does not publish 2.6.x wheels for that platform and the project keeps that target on the 2.2 line instead:

"torch>=2.2,<2.3; sys_platform == 'darwin' and platform_machine == 'x86_64'"
"torchaudio>=2.2,<2.3; sys_platform == 'darwin' and platform_machine == 'x86_64'"

Once the service is running, the first real use is the one the README describes: drag an MP3, WAV, FLAC, OGG/Opus, MP4 or M4A file onto the import bar, or paste a YouTube URL. From there the interface is a DAW-style multitrack mixer where you can mute, solo, balance levels, zoom the waveform, loop a region, and export individual stems or a custom mix. Expect the first run to be slow in a way later runs are not, because the model weights have to be fetched before anything can be separated. The README does not document where those weights are cached or how to pre-seed them for an offline machine.

Where StemDeck breaks down

The first limitation is environmental. The pyproject comments describe a real failure mode on Intel macOS: the newer Demucs line pulls a native Rust/CMake package with no x64 macOS wheel, and CMake dropped support for the version that would have built it. That is why the pin exists. It also means an Intel Mac user is on an older torch line than everyone else, and any future Demucs feature that needs a newer torch will not reach that platform.

The second is the absence of a rollback story. The README does not document rollback, and the versioning scheme makes it slightly harder than usual to reason about: pyproject.toml derives the version from the git tag via hatch-vcs, and builds between tags report a dev version such as 0.7.0a5.dev3+g<sha>. If you install from a source checkout rather than a release, you may be running something that was never tagged.

The third is scope. This is a desktop-style local tool. There is no documented API for batch processing a library, no queue, and no headless mode described in the README. If you want to separate two hundred files overnight, or wire separation into a pipeline, the interface described here is a mixer you operate, not a service you call. And on quality, the README makes no claims at all. It positions StemDeck against cloud splitters on cost and privacy, and concedes that "if you need the polish, a mobile app, or deeper musician tooling, the commercial products are a better fit." That sentence is the project's own boundary.

StemDeck versus Moises and LALAL.AI

The README names the comparison directly: StemDeck is "a free, open alternative to cloud stem-splitters like Moises and LALAL.AI: no account, no quota, no uploads, no subscription." The difference is architectural rather than cosmetic. Those products run separation on their servers, which means your upload is the input and their model is the one you get, updated whenever they choose. StemDeck runs the model on your hardware, which means the compute cost is yours and the model version is the one your pins allow.

That flips the trade in both directions. You get privacy and no per-file cost, at the price of a heavier install and separation speed tied to your own CPU or GPU. You get a fixed model you can reason about, at the price of not benefiting from whatever the cloud vendors improve next month. The README is unusually candid about which side of that trade it wins on, and it does not claim to win on output quality. Anyone choosing between them should treat the decision as local-and-free versus hosted-and-polished, not as a quality ranking.

Maintenance, licence and what you are taking on

The repository is not archived, and the last push was on 2026-09-13. Releases have been frequent and small: v0.17.0 on 2026-09-04, then v0.17.1 and v0.17.2 both on 2026-09-13. A patch pair on the same day suggests active bug-fixing rather than a stalled project, but the version number itself is the useful signal: 0.17.x is pre-1.0, so interface and behaviour changes should be expected rather than treated as incidents.

The licence is Apache-2.0, which permits commercial and private use and includes an explicit patent grant. It also carries notice and attribution obligations if you redistribute the software or a modified version, and it does not grant trademark rights. That is a general description of the licence text, not legal advice; if you plan to ship StemDeck inside a product, read LICENSE and the NOTICE requirements with your own counsel.

Upgrade cost is the part worth weighing before adoption. You are not just installing an app; you are maintaining a pinned scientific Python stack. The torch, torchaudio and demucs constraints in pyproject.toml exist for documented reasons and will not lift on their own. Moving to a newer Demucs means someone has to verify that the torchaudio writer path still works, and moving to a newer torch on Intel macOS may simply be impossible. Budget for that, or pin to a release and stop upgrading.

Editorial conclusion

Adopt StemDeck if you want six-stem separation to happen on your own machine and you are comfortable running a Python service with pinned torch and demucs versions. Do not adopt it if you need a mobile app, a hosted API, or separation quality guarantees on dense mixes; the README itself says commercial products are a better fit for polish and deeper musician tooling. Before you commit, verify that your platform has wheels for the pinned torch line, because the pyproject comments describe a source build that fails on Intel macOS, and check which Demucs checkpoint your install actually pulls.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. stemdeckapp/stemdeck on GitHub