Station's desktop-app repo is a working Electron operations manual, not a product

The README is written for someone who already works on it

Read the table of contents and the audience is immediately clear. There is no feature list and no screenshot section. Instead there is Installation broken down per platform, Run, a DevTools section with four subsections, a list of development environment variables, Migrations, Packaging, and a release procedure.

This is an operations manual for Station, described in the repository as one app to rule them all, with the topics tagged browser, electron and saas. The absence of marketing content is the first signal about what this repository is: it is the internal development documentation for a shipping desktop product, published.

The installation section is where that shows most clearly. The requirements are stated as node >= 18.x and yarn >= 1.19.x, followed by three commands:

$ git clone https://github.com/getstation/desktop-app.git
$ cd desktop-app
$ yarn

Then platform prerequisites, which differ substantially. macOS needs nothing additional. Windows needs the node-gyp build tools installed globally with `--add-python-to-path`. Ubuntu needs a list of system packages including graphicsmagick, icnsutils and the X11 development headers:

$ sudo apt install graphicsmagick icnsutils libxtst-dev libx11-dev libxrender-dev libxkbfile-dev libgconf-2-4

CentOS or Amazon Linux 2 requires CentOS 9 specifically, with its own package list covering clang, gtk3-devel, cups-devel, nss-devel and others. The CentOS 9 requirement is the kind of constraint that dates a README quickly, and it is worth noticing when you assess whether this codebase still installs cleanly.

The env var list is the most reusable thing in the repository

The section headed useful env variables for dev is a switchboard for every subsystem, and it is the part most likely to be useful to a reader who will never run Station.

The first group controls what loads at all. `STATION_NO_WEBVIEWS`, if it exists, means webviews are not loaded. `STATION_DISABLE_ECX` prevents electron-chrome-extension from loading. Between them they tell you the browser's tab content is an extension of some kind, since the toggle is specifically about whether webviews exist.

The second group tunes tab lifecycle, which is where a browser of this design does its real work. `STATION_CHECK_INACTIVE_TAB_EVERY_MS` overrides the interval between checks for inactive tabs, `STATION_WAIT_MS_BEFORE_KILL_TAB` overrides the time to wait before a tab is considered inactive and killed, and `STATION_QUICK_TRANSITIONS` makes all transitions quick for testing colour changes. That combination describes a browser that suspends and kills tabs on a timer to bound memory use.

The third group is about state isolation and diagnostics. `OVERRIDE_USER_DATA_PATH` replaces the `userData` path, with the example `OVERRIDE_USER_DATA_PATH="Station Canary" yarn run dev` showing the intended use, running a development build beside an installed one. `STATION_NO_CHECK_FOR_UPDATE` disables update checks, and `STATION_AUTOUPDATER_MOCK_SCENARIO` mocks the AutoUpdater module with two named scenarios, `available` as the default and `not-available`.

Finally: `DEBUG=service:*` prints debug info from the Service framework across all processes, `STATION_REACT_PERF` adds react-addons-perf, `STATION_REDUX_LOGGER` enables redux-logger in the renderer, and `STATION_SHOW_REQUIRE_TIME` displays module require times on quit, though both its Main and Renderer sub-options are struck through as disabled for now.

That last detail is worth pausing on. Two documented options are marked disabled, which is a small but telling signal about how current the rest of the list is.

Debugging a three-process Electron app with GraphQL and Redux

The DevTools section describes a real multi-process setup, which is the main thing an outside reader can learn from it.

Chrome DevTools toggle shortcuts are given per platform: Cmd+Alt+I or F12 on macOS, Ctrl+Shift+I or F12 on Linux and Windows, powered by electron-debug. Inside the renderer, React DevTools and Apollo Client DevTools are both available in Chrome DevTools, which is a strong hint that the renderer talks to a GraphQL backend rather than only to local state. A repository doc path named packages/app/src/graphql/README.md confirms a local GraphQL layer exists.

Redux state inspection needs extra setup. You install Redux DevTools or the browser extension, click Open Remote DevTools, and enable Use (custom) local server on `localhost:8000` in the settings. That specific instruction exists because a remote debugging server has to be allowed before the extension can attach.

The main process is inspected separately: you connect Chrome by visiting `chrome://inspect` and selecting the launched Electron app. This is standard Electron, and stating it is useful only because it confirms the process split.

Database work follows the same pattern. Migrations run through umzug with umzug-cli, and there are two commands:

// Apply migrations
$ yarn run database migrations up
// Revert last applied migration
$ yarn run database migrations down

To look at the data directly, the README tells you to install TablePlus and open a SQLite connection to a database file at `~/Library/Application Support/Station Dev/db/station.db`. The `Station Dev` suffix matches the `OVERRIDE_USER_DATA_PATH` mechanism, so a dev build and an installed app keep separate databases.

Packaging and the release procedure CI owns

Packaging is a single command for the local platform:

$ yarn run build

Everything beyond that belongs to CI. The README states the application will be automatically signed by the CI on the `release` branch, which is the modern arrangement and also means you cannot reproduce a signed build locally.

The release procedure is a five step list that is worth reading because it explains the branch layout. You draft a new release on GitHub tagged with the desired version, apply your changes on the `release` branch, then on that branch bump the version with `yarn version` to the corresponding version number. Let the CI build artifacts for each platform, then publish the draft. A note adds that you can remove artifacts and push further changes over the same draft, which is how a bad build gets replaced without a new tag.

So `main` is where development happens and `release` is where the shipping version lives, with the version number in package.json as the single source of truth. That explains the current package version being `4.0.0-b1`, a prerelease.

The repository layout supports this being a workspace. package.json declares `workspaces` as `packages/*` with yarn 4.18.0 as the packageManager, and the top level has a `packages/` directory, `ci/`, `scripts/`, `dev_utils/` and a `docs/` folder. The README has a section titled Workspace management marked TODO, which says the repository should be used as a proper monorepo and lists packages that should be affected: appstore, already in the repo but not handled by any monorepo tool yet, plus `@getstation/sdk` and `@getstation/theme`.

Version drift, a versionless homepage, and who this is for

Several details suggest a codebase between major versions rather than in steady upkeep.

The README requires node >= 18.x and yarn >= 1.19.x. The package.json requires node >= 24.0.0 through its devEngines block, and pins volta to node 24.19.0 with yarn 4.18.0, with yarn 4 rather than the 1.x the README names. The README is a major toolchain version behind its own configuration, which is the kind of drift that hurts a newcomer before they write a line of code.

Linting shows the same pattern. The development tools list recommends Editorconfig, ESLint and TSLint, and the repository contains both `.eslintrc` and `tslint-ci.json`. TSLint is deprecated in the TypeScript ecosystem, so its presence as a documented tool is a dated signal.

The homepage is the odd one. It points at a web archive snapshot of getstation.com dated 2025-12-16 rather than at the live site, which usually means the live site is not serving what the project needs to claim.

The release history fits the same picture: v3.2.0 on 2024-10-15, v3.3.0 on 2024-12-01, then v4.0.0-b1 on 2026-08-15, with the last push on 2026-10-11. A prerelease of a major version after a two month gap since the tag.

So who is this for? Two groups, in order. Station's own contributors, for whom the README is genuinely useful documentation. And engineers building Electron products with webviews, extensions, SQLite and tab lifecycle management, for whom the environment variable list and the umzug and remote debugging setup are concrete patterns worth borrowing.

It is not a template. The package is private, named station-project, the internal architecture includes a services framework, a score engine, a bang lifecycle and a persistence layer with its own documentation, and none of that is extracted for reuse. Licence is Apache 2.0, so the code can be read and reused, but nothing here has been shaped into something you would start a project on.

Editorial conclusion

Adopt this repository if you are evaluating how a production Electron browser with webviews, browser extensions, a SQLite database and per-tab lifecycle management is put together, and you want to read a real operations setup rather than a tutorial. Do not adopt it as a starting point for your own Electron application, because it is Station's private product with its own services, score engine, bang lifecycle and GraphQL layer, not a template. Verify first that the product you can see matches this source, since the README describes a browser and the only homepage given is a web archive link dated 2025-12-16.

Frequently asked questions

Official sources

1. getstation/desktop-app on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases