# OpenNOW: an open-source GeForce NOW desktop client built on Qt Quick and Rust

> OpenNOW replaces the retired Electron client with a Qt Quick interface and a separate Rust process for accounts and streaming. It is a community client, not an NVIDIA product, and the Qt build is still marked as under development.

**OpenCloudGaming/OpenNOW** — Custom GeForce Now Client Named OpenNOW

- Repository: https://github.com/OpenCloudGaming/OpenNOW
- Stars: 2,465 · Forks: 178
- Language: Rust
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/opencloudgaming-opennow

## What OpenNOW is, and who it is actually for

OpenNOW is a community-built desktop client for GeForce NOW. The README states plainly that you need your own GeForce NOW account, and that your subscription, region and hardware determine which games and stream settings you can use. It also states that OpenNOW is not affiliated with, endorsed by, or sponsored by NVIDIA, and that NVIDIA and GeForce NOW are trademarks of NVIDIA Corporation. That framing matters more than it usually would: this is a client for a service someone else operates, so the client cannot widen your catalog or raise your tier.

The people this fits are GeForce NOW subscribers who want a desktop application rather than a browser tab, and who are willing to run software the project itself describes as still under development. The README's own warning is unusually direct for a project page: expect bugs, including platform-specific streaming and GPU issues, and note that the Qt app has no Chromium/WebRTC fallback. That last point is the real dividing line. If a stream fails in OpenNOW, there is no second rendering path inside the app to fall back on.

It is not a way to get GeForce NOW for free, and it is not a replacement for the service. Everything downstream of sign-in depends on NVIDIA's infrastructure and on what your account is entitled to.

## Qt Quick draws the window, Rust runs the stream

The architecture is a two-process split, and the README is explicit about the boundary. Qt draws the interface and handles windows, navigation, focus and overlays. The Rust core runs in a separate process. It manages accounts, settings and catalog requests, then prepares the stream. Keeping those apart means a hung or crashed streaming core does not have to take the UI with it, and it means the interface layer is not written in the same language as the media path.

The desktop app carries two layouts inside one binary. A keyboard-and-mouse layout is the default, and a console layout switches the same app to a controller-first grid with button prompts. The README does not describe restarting the app to change layouts.

On the interface side, the repository layout confirms the split rather than just describing it. The Qt code sits under opennow-qt/, and the native Rust crates live under native/, with separate opennow-core and opennow-streamer manifests. The workspace package.json drives both sides from one place, which is why a single npm script can configure CMake and a separate one can run cargo check across both Rust crates.

Feature-wise, the README lists catalog browsing, favorites, collections, resolution and frame rate and bitrate and codec settings, in-stream menus and statistics, screenshots, and recording the source stream to Matroska files. Screenshots and recordings land in Media. There is also a diagnostics export under Settings, About, Copy diagnostics, which is the thing to reach for before filing a streaming bug.

## Installing OpenNOW on Windows, Linux or macOS

The README points at GitHub Releases and says to look for packages whose names start with OpenNOW-Qt-. That prefix is not decoration: older releases may contain the retired Electron app, so the release notes have to be checked before downloading. If no Qt nightly is published, the README says to sign in to GitHub and pull the artifacts from a successful qt-ci run on the dev branch.

Platform packaging differs, and the differences are worth reading before you pick a file. On Windows there is an MSI and a portable ZIP; the README says to install the MSI, or extract the entire ZIP and run bin/OpenNOW.exe. Extracting only part of the archive is not the documented path.

On Linux, the AppImage is the recommended option: make the file executable, then launch it. The .deb exists too, but the README attaches a condition, namely that your distribution must provide Qt 6.8+ and SDL3, and it recommends the AppImage on stock Ubuntu 24.04.

On macOS the package is a .dmg for Apple Silicon on macOS 13 or later: open the DMG and drag OpenNOW into Applications. Intel Macs are not included. Nightly packages are unsigned, so Windows may show an unknown-publisher warning, and the macOS app is not notarized. If Gatekeeper blocks it, the README's instruction is System Settings, Privacy & Security, Open Anyway when offered, and explicitly not to disable Gatekeeper globally.

Building from source is a different route and the workspace is set up for it. The root package.json requires Node 22.22.0 or newer and exposes scripts that wrap CMake and Cargo.

```bash
npm run qt:configure
npm run qt:build
npm run native:check
```

The first two configure and build the Qt app into build/opennow-qt. The third runs cargo check against both native/opennow-core/Cargo.toml and the opennow-streamer workspace, which is the cheap way to find out whether your Rust toolchain and platform dependencies are in order before a full build. Tests run through ctest via npm run qt:test.

## The limitations the project states about itself

The most consequential limitation is written in the README's own warning block: the Qt app is still under development, and publishing a build does not mean it has passed every check in the acceptance checklist at docs/qt-acceptance.md. That sentence is doing real work. It tells you the release pipeline and the verification pipeline are not the same thing, so a downloadable artifact is evidence that a build succeeded, not that it was validated on your platform.

The absence of a Chromium/WebRTC fallback compounds this. Many streaming clients keep a browser-based path available for the cases where the native renderer misbehaves. OpenNOW's Qt client does not, so a GPU-specific or platform-specific streaming fault has nowhere to go inside the application.

Distribution has its own costs. Nightly platform packages are unsigned. The macOS build is not notarized, which means every affected user goes through System Settings to allow it. The README notes that published update-enabled nightlies use signed update manifests, but also that older builds without a pinned signing key need one manual upgrade. It is careful about what checksums mean: they detect corrupted downloads, they do not verify who published a package. That is an accurate statement about hashes and a fair warning about treating a checksum as provenance.

Finally, the release-candidate workflow is narrower than the nightly one. The signed 1.0.0 candidate builds Windows and Linux only. Anyone on macOS is on the nightly track, the separate OpenNOW-Mac project, or nothing.

## How OpenNOW differs from Moonlight and Sunshine

The natural comparison is Moonlight paired with Sunshine. That pairing streams from a PC you own: Sunshine runs on your machine as the host, Moonlight is the client, and the whole pipeline is yours to configure, including the host's GPU, encoder and network path. OpenNOW does not host anything. It is a client for GeForce NOW, so the host is NVIDIA's and the account, region and subscription tier decide what you can launch and at what settings.

That difference changes what you can debug. With a self-hosted setup, a bitrate or codec problem leads back to your own encoder configuration. With OpenNOW, the README's position is that your subscription, region and hardware determine which games and stream settings you can use, which puts a ceiling on what any client-side setting can achieve. The client exposes resolution, frame rate, bitrate and codec controls, but those are bounded by the account and the device.

It also changes the failure surface. A self-hosted stack fails in places you control. A third-party client for a hosted service can fail because of the client, because of the service, or because of the interaction between them, and the project's diagnostics export exists precisely because that distinction is not obvious from the outside. If your goal is to stream games from hardware you own, OpenNOW is the wrong tool and Moonlight with Sunshine is the right shape of solution. If your goal is a native desktop front end for a GeForce NOW subscription, the comparison does not apply.

## Maintenance, releases and what the MIT licence covers

The repository is not archived, and the last push was on 2026-09-26. Release cadence is visible in the tags: v1.0.2-nightly.673.1 on 2026-09-19, v1.0.2-nightly.717.1 on 2026-09-21, and v1.0.2-nightly.810.1 on 2026-09-24. The numbering suggests frequent nightly cuts under a 1.0.2 line, and the README's own language about the Qt app being under development is consistent with that. Frequent nightlies are not the same as a stable channel, and the README does not describe one.

The upgrade cost is uneven by platform. Update-enabled nightlies use signed update manifests, so those can update in place. Older builds without a pinned signing key need one manual upgrade, after which the signed path applies. On macOS, each unsigned nightly means another trip through Gatekeeper unless the situation changes.

The project is MIT licensed, with a THIRD_PARTY_NOTICES file at the repository root. MIT is permissive and short, but the licence on OpenNOW's own code does not govern NVIDIA's service, the GeForce NOW name or the account you sign in with, and the README already disclaims affiliation with NVIDIA. Translators should note the crowdin.yml at the root and the locales/ directory, with npm scripts to upload sources and download translations. Nothing here is legal advice; read LICENSE and THIRD_PARTY_NOTICES yourself.

## Conclusion

Adopt OpenNOW if you already hold a GeForce NOW account, want a native desktop client instead of the browser or the retired Electron app, and are comfortable running unsigned nightly packages. Skip it if you need a notarized macOS build, an Intel Mac build, or a client that has passed the project's own acceptance checklist. Before installing, open docs/qt-acceptance.md and the Qt app guide, confirm which release actually contains the Qt build rather than the retired Electron app, and check whether the macOS Gatekeeper workaround in System Settings is acceptable on your machine.

## FAQ

### What is open now for food near me?

This article covers OpenNOW, the GeForce NOW client, not restaurant opening hours. The README does not document anything about food or venues.

### What is open now to eat?

OpenNOW is a GeForce NOW client, so it has no bearing on what is open to eat. The README only describes account sign-in, catalog browsing and streaming.

### What is open now near me?

OpenNOW is not a directory of open businesses. It is a community desktop client for GeForce NOW, and the README states you need your own GeForce NOW account to use it.

## Sources

- [Issues](https://github.com/OpenCloudGaming/OpenNOW/issues)
- [License: MIT](https://github.com/OpenCloudGaming/OpenNOW/blob/main/LICENSE)
- [OpenCloudGaming/OpenNOW on GitHub](https://github.com/OpenCloudGaming/OpenNOW)
- [README](https://github.com/OpenCloudGaming/OpenNOW/blob/main/README.md)
- [Releases](https://github.com/OpenCloudGaming/OpenNOW/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opencloudgaming-opennow