BSManager: running several Beat Saber versions side by side

The version juggling problem BSManager exists to solve

BSManager describes itself as an all-in-one tool for managing Beat Saber versions, maps, mods and more, and the README puts it more plainly: download, manage and customize your versions of Beat Saber with a simple click.

The interesting word in that sentence is versions. A single version of Beat Saber with a single set of plugins is not a hard problem. The problem starts when a map needs a game build from before a certain update, or a mod only works with a specific build, or you want to test something risky without destroying the setup you already have. The answer used to be a folder of game copies and manual copying, and the answer BSManager offers is a launcher that keeps them organised and lets you switch.

That is also why downgrading appears among the project topics, alongside beatsaber, mods and launcher. The tool is aimed at a player who is deep enough in the mod scene to have hit a version conflict, not at someone who has never launched the game.

The project is a community effort rather than a product from the game's developer. The README points to a Discord server, a Twitter account, a website at bsmanager.io and a Patreon page for supporting the project, and it invites bug reports, feature requests and security vulnerability reports through issue templates. The repository is not archived and the last push was on 2026-10-15, so work is still going on.

The stack: Electron, electron-vite, Tailwind and Rust helpers

BSManager is a TypeScript desktop application. The build tooling is electron-vite with electron-builder doing the packaging, configured in electron.vite.config.mts and electron-builder.config.js. The main entry point in package.json points into a release/ directory, which is where electron-vite writes its output, and the built application is then packaged from there.

Alongside the TypeScript there is a Rust component. The scripts build-rust-scripts and rebuild handle it, the latter running electron-rebuild against the release/app module directory to recompile native modules for the packaged Electron runtime. That is the usual pattern for an Electron app with native Node addons, and it is also the first thing that will fail on a machine with a mismatched toolchain.

The rest of the tooling is conventional. Tailwind handles styling, eslint and prettier handle code quality, jest runs the tests, and pnpm manages the workspace. The .erb directory at the repository root holds a set of build helper scripts that are invoked directly with tsx, including clean.js, check-bundle-dependencies.ts, check-native-dep.js and check-port-in-use.js.

The .erb naming points at the electron-react-boilerplate lineage that this project is built on, and the scaffolding is visible in the file layout: mise.toml for tool versions, .nvmrc for the Node version, a pnpm-workspace.yaml, and separate tsconfig files.

"main": "./release/app/dist/main/main.js",
"version": "1.6.0",
"packageManager": "[email protected]"

Building it yourself, and the pnpm lock that stops npm

The package.json declares the package manager as pnpm 10.34.4 and repeats it in devEngines with onFail set to error, and there is a preinstall hook that enforces it.

"preinstall": "node .erb/scripts/require-pnpm.cjs",
"devEngines": {
    "packageManager": {
        "name": "pnpm",
        "version": "10.34.4",
        "onFail": "error"
    }
}

The practical effect is that running npm install fails on purpose, and you need pnpm 10.34.4 exactly. A pnpm-lock.yaml is committed at the repository root, so the dependency set is reproducible once you have the right package manager.

The everyday commands are short. The dev script checks that a port is free before launching electron-vite in development mode, and the build script cleans the output directory, compiles with electron-vite in production mode and then verifies the bundle dependencies.

pnpm start
pnpm run build

Packaging is a separate step, and there are two variants. The unsigned one skips signing and disables identity auto discovery, which is what you want if you are not a registered developer with a certificate.

pnpm run package:unsigned

There is also a Windows-only target, build:win, which packages for win and x64. The full package command uses the same electron-builder config file and never publishes, so it produces local artefacts only.

Tests run through jest with a narrow path filter, which tells you where the unit tests live.

pnpm run lint
pnpm run test:unit

What the release history says about the pace of change

The tagged releases show a project on a steady cycle. BSManager v1.5.6 shipped on 2026-02-08, an alpha of the next major, 1.6.0-alpha.1, on 2026-07-18, and the final v1.6.0 on 2026-08-18.

The gap between the alpha and the final release is worth noting, because it is a month, and the gap between v1.5.6 and the alpha is five months. This is the pattern of a tool that has to be re-cut when the game updates, since the whole reason a version manager exists is that the game changes underneath it. A build that works against one game release can stop working against the next, and the maintainers have to react.

The current version in package.json is 1.6.0, matching the most recent tag, which means the tree is at the released state rather than ahead of it, despite the last push landing on 2026-10-15.

For an adopter, that pattern sets expectations. A version manager for a live game is not a project where you install once and forget it. Each game update tends to mean a new BSManager release, and the application that managed your folders last month may not have a profile for the newest build yet.

The repository also carries the usual community paperwork, a CHANGELOG.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md and a pull request template, which is what you would expect from a project with a Discord and a Patreon behind it.

Where BSManager is the wrong tool

The first limitation is that there is no official binary in the repository. The homepage field is empty, so there is no single canonical download page in the project metadata, and the way to get the application is a signed release from the project's own site or a build you make yourself with the packaging scripts. That is a real friction point for a tool whose entire appeal is convenience.

The second limitation is the toolchain weight. To build from source you need pnpm 10.34.4 exactly, Node as pinned in .nvmrc, the mise tool versions, a Rust toolchain for the helper scripts, and a working electron-builder environment that can rebuild native modules. On a machine where the game already runs, none of that is a given.

The third limitation is the narrow test surface. The test script filters on src/__tests__ with a regex matching .test.ts files, and there is a separate unit target. The coverage of an application that manipulates versions, folders and mod configurations is therefore something the maintainers measure rather than something you can read off the repository, and the unit tests are the part most likely to be portable across versions.

The fourth limitation is platform reach. The packaging script has an explicit Windows target, and the project ships a Windows build by convention, but the electron-vite and electron-builder setup does not make a native application for every platform. Anyone on Linux would be relying on the compatibility of the underlying Electron runtime rather than on a first class build.

BSManager next to Mod Assistant and a Rust rewrite

The comparison that helps a new user is with the other tools in the same problem space, because the difference is in the model rather than in the feature list.

Mod Assistant is the Windows oriented .NET tool that the community has used for a long time. Its approach is to work inside one game installation, with one set of folders, and to install mods and maps into it from the community catalogue. That model is simple and it is where the fragility comes from. When a game update changes the folder layout, a single-installation manager has to migrate in place, and the user is left with a broken setup if the migration does not cover what they had.

BSManager's model is the opposite. It treats the game version as the unit of organisation, keeps more than one version on disk, and lets you choose which one a given session runs with. The cost is disk space and a slightly heavier application, and the benefit is that an old build for a specific map stays intact while a new build runs separately.

A third direction is a Rust and Tauri rewrite of the same idea, which drops the Electron runtime for a native webview and produces a much smaller application. The trade-off is the one every Tauri project carries: a smaller binary and a smaller memory footprint in exchange for a plugin ecosystem that is not as rich as Electron's, and a codebase that is younger.

All three ultimately depend on the community catalogue of maps and mods for their content. BSManager's contribution is the version layer, not the content.

Licence, security reporting and community support

BSManager is released under the GNU General Public License version 3, with the licence text in the LICENSE file at the repository root. GPL 3.0 is a copyleft licence, so if you distribute a modified BSManager you have to pass on the source under the same terms. For a personal launcher that is not a practical constraint, and it is a reasonable licence for a community tool that other players depend on.

There is a SECURITY.md file at the repository root and a dedicated security policy link in the README for reporting a vulnerability, which is a sensible arrangement for an application that has write access to game installations and runs third party plugins in the game process.

Community support runs through Discord, and the README also links a Twitter account, the project website and a Patreon page for financial support. The release history, the changelog and the regular pushes to the master branch all point to a project with a steady group of people behind it, and the last push on 2026-10-15 is recent enough that the tree reflects current work on the game rather than a dormant snapshot.

Editorial conclusion

Adopt BSManager if you play Beat Saber across several game versions, for example to keep a build that a map or mod requires alongside a current one, and if you are willing to build the app from source or install a signed release. Skip it if you have one version and one mod folder, where copying a plugin is faster. Before switching, run pnpm install in a checkout and confirm the pnpm version check passes, then use the signed package rather than the unsigned build script unless you have your own signing identity.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Zagrios/bs-manager on GitHub