Streamlabs Desktop: building the OBS-based streaming client from source

Who Streamlabs Desktop is for, and what it is not

Streamlabs Desktop is a live streaming client. Its README opens by calling it "Simple, powerful, and efficient live streaming software built on Electron and OBS." The package name is slobs-client and the product name is Streamlabs Desktop, which tells you which half of the stack is the product and which half is the shell.

The repository is aimed at contributors, not end users. There is no download link in the README, no installer walkthrough, and no user manual. What it does give you is a dependency list, a build sequence, an architecture summary, and a contribution policy. If you want the shipped application, the homepage is streamlabs.com. If you want to change how the application behaves, this repository is the place.

The platform support line is blunt: "This application currently only supports OSX 10.14+ and 64-bit Windows." Linux is not mentioned anywhere in the README. That single sentence rules out a large slice of the OBS community, which is a real consequence of the Electron shell rather than an accident of packaging.

The licence is GPL-3.0, declared both in the repository metadata and in the license field of package.json. The author field reads General Workings, Inc.

Windows, workers and the IPC backbone

The architecture section of the README is the most useful part of the document, because it explains why the codebase looks the way it does. The application is not one process. It is several separate copies of the same JavaScript application, each running a different slice of the code and talking to the others over Electron IPC.

Three of those windows are named. The worker is a persistent invisible window that runs the entire services layer. The main window is what the user sees, and it reaches the worker to perform actions. The child window stays running in the background so that windows like Source Properties can appear quickly; the README explains the reason directly, noting that Electron windows can take several seconds to initialize. Beyond those three, the README says there can be many other JavaScript runtime processes for features such as Apps, embedded webviews, and one-off windows like projectors and pop-outs.

The consequence for anyone writing code here is spelled out in the Sync / Async subsection. Because the app leans so heavily on interprocess communication, the README recommends asynchronous IPC wherever possible. A synchronous call such as StreamingService.toggleStreaming() can be rewritten as StreamingService.actions.toggleStreaming(), and the async form returns void because actions cannot return values. To read state back, the README points at views, which run in-window and are backed by a vuex store replicated across windows.

This is a deliberate split between commands and queries, and it is the single most important thing to internalize before touching a service. If you need a value, you do not call the service; you read a view.

Vue and React in the same tree

The repository is mid-migration between two UI frameworks, and the README does not pretend otherwise. It states that the project is in the process of migrating from Vue to React, that both frameworks are present, and that all new components should be written in React. Major non-trivial changes to existing Vue components should come with a rewrite to React.

For a contributor this is a clear rule with an awkward edge. A small bug fix in a Vue component stays in Vue. A large feature in the same file is expected to arrive as a React component, which means the diff is bigger than the bug. The README also commits to a style within React: functional components only, with the hooks API for state and lifecycle.

The repository topics list both react and vue, along with vuejs, which matches the README's description of a codebase holding components from both. The practical effect is that a newcomer cannot learn one framework and ignore the other. Reading a feature often means reading a React component that renders alongside Vue components in the same window.

The migration is not described with a timeline, and the README does not say how much of the tree remains in Vue. That is a gap worth knowing about before you estimate any UI work.

Installing the toolchain and starting the app

The README lists four dependencies before any build step: Node.js, Yarn, a bash-like environment, and the native modules. Node is used for installing npm packages and running scripts, and the README recommends the latest LTS release. Yarn is the package manager, and the project uses yarn modern (berry) with the yarn version checked into version control. The README currently recommends getting the Yarn CLI through npm:

npm install -g yarn

On Windows the README recommends Git Bash, which ships with Git for Windows. On macOS the default shell should work.

The native modules deserve a note. Streamlabs Desktop uses several native C++ modules that live in separate repositories and are installed automatically as prebuilt binaries by Yarn. The README states that if you are not doing development on those modules, no additional action is required. That is the good case. The bad case is not documented here.

With the toolchain in place, install the node modules and compile the assets:

yarn install
yarn compile

If you are going to iterate on app files, the README offers a watch mode instead of a one-shot compile:

yarn watch

Then start the application:

yarn start

The start script is electron . with the main entry at main.js. The README notes that you can open dev tools by clicking the button on the sidebar, and that in the development environment the titlebar of the main window lights up red when an exception occurs in any window. That red titlebar is the fastest signal you get that something in one of the IPC-linked windows has thrown.

Environment variables you will actually reach for

The README documents five development environment variables. They are the difference between guessing at behaviour and forcing it.

SLOBS_FORCE_AUTO_UPDATE makes the auto-updater run in development, where it would normally only run in production. SLOBS_CACHE_DIR relocates the user data cache directory, which matters when you want a clean profile without deleting the real one. SLOBS_DISABLE_MAIN_LOGGING turns off JavaScript logging in the main process. SLOBS_REPORT_TO_SENTRY sends errors to Sentry from the dev environment. SLOBS_PRODUCTION_DEBUG forces dev tools to open when the app starts.

None of these are required to run the app, and the README frames them as ways to force certain behaviour in development. The set is small, which is a fair reflection of how much the README chooses to document rather than how much the codebase contains.

Two more variables appear later, in the packaging section, and they exist to let you skip steps you cannot complete locally: SLOBS_NO_SIGN to skip codesigning the app package, and SLOBS_NO_NOTARIZE to skip notarizing the macOS package. They are not development flags, but they are the ones people reach for first when a local package build fails.

Packaging, code signing and the missing rollback story

The packaging scripts are short and the requirements behind them are not. For Windows the README gives yarn package; for macOS it gives yarn package:mac. Both commands require code signing certificates to be present in the environment, and in the macOS case a valid Apple developer account for notarization of the app package. The underlying scripts run electron-builder against electron-builder/base.config.js, and the package script regenerates the agreement file and clears dist before building.

That is a hard dependency on credentials most contributors do not have. The escape hatches are SLOBS_NO_SIGN and SLOBS_NO_NOTARIZE, which let the build finish without signing or notarizing. The README does not say what the resulting unsigned artifact can and cannot do, so treat an unsigned build as a build check rather than a shippable package.

There is also a macVirtualCamUrl field in package.json pointing at a versioned virtual camera installer tarball on S3, and a slobs-virtual-cam-installer directory at the top level. The README does not explain how that installer is wired into the desktop app.

What the README does not cover at all is rollback. There is no documented way to return an installed build to a previous version, and the release notes were not available, so the upgrade path is only half described. Anyone deploying this in an environment where a bad build must be reverted is working without documentation.

Contributing, the CLA and the translation wall

The contribution policy is more restrictive than the licence alone suggests. The README says outside contributions are accepted and that the team does its best to respond to pull requests, but every contributor must sign a Contributor License Agreement before code is merged. It also states plainly that not all external pull requests will be merged. A BASEAGREEMENT file sits at the top level of the repository, alongside the LICENSE file.

Translations are closed. The README states that translations submitted to GitHub cannot be accepted at this time, because a professional translation team manages them elsewhere. A crowdin.yml file is present in the repository root, which is consistent with translation work happening on an external platform rather than through pull requests. If your interest in Streamlabs Desktop is localization, the repository is not the entry point.

The GPL-3.0 licence is worth reading alongside the CLA rather than instead of it. The licence governs redistribution of the code; the CLA governs what the project may do with a contribution once it is merged. Those are different questions, and the README does not discuss the interaction between them. That is a question for your own legal review, not something this article can settle.

On maintenance, the last push to the default branch was on 2026-09-22, so the repository is not dormant. The README does not describe a release cadence or a support window for older builds.

Editorial conclusion

Adopt it if you are comfortable in a Yarn and webpack monorepo, your target is macOS 10.14+ or 64-bit Windows, and you are willing to sign a Contributor License Agreement before any patch lands. Do not adopt it if you need a Linux build, if you want to submit a translation, or if your plan depends on the native modules being vendored inside this repository. Before you start, confirm that Node and Yarn are installed, that the native modules resolve as prebuilt binaries during yarn install, and that you have the code signing certificates the packaging scripts expect. Then run yarn compile and yarn start.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. streamlabs/desktop on GitHub