Overlayed: a native Discord voice chat overlay built on Tauri and React

A voice chat overlay, packaged for all three desktop platforms

Overlayed is described as a modern, open-source and free voice chat overlay for Discord that supports Mac, Linux and Windows. The problem it addresses is narrow and well understood: Discord's own client does not let you place a widget over the voice call, so streamers, players and anyone running a shared session end up with a browser tab or a second window on top of the client.

The three platform names in the description are not incidental. An overlay has to sit above other windows, follow the window it is attached to, and stay transparent in a way that looks native on each desktop. Doing that in a web page is not possible in a way that survives the security model of a browser, which is why the topic tags include tauri and tauri-app alongside react, tailwind and vite.

Tauri is the frame here. It gives a web front end a native host, so the interface can be written in React with Tailwind while the window that floats above Discord is a real native window with real window-manager behaviour. The topic list also carries discord and discord-overlay, which is the naming convention the project uses for the feature itself.

The audience is Discord users who want the overlay and do not want a subscription for it, and the emphasis on free and open source in the one line description is a deliberate positioning against the commercial overlay tools that exist for the same purpose.

The project is licensed under AGPL-3.0, the last push was on 2026-10-10, and the homepage is overlayed.dev.

Winget, Homebrew and Flathub: the install path is the distribution strategy

The installation section is three commands and a link, and the shape of it is the point.

On Windows the package is on Winget.

winget install OverlayedDev.Overlayed

On macOS it is on Homebrew.

brew install overlayed

On Linux it is on Flathub.

flatpak install flathub dev.overlayed.Overlayed

Choosing Flathub for Linux rather than a deb or an AppImage is a meaningful decision, because Flatpak sandboxes the application. For an overlay that has to read the window list, sit above other applications and stay out of the way, a sandbox with a flatpak-specific interface is what the Linux desktop expects, and the reverse of that is a package that fights the sandbox.

Each of these three channels also gives something the others do not. A package manager entry means updates arrive with the rest of the system's packages rather than needing a separate download, and it means the user is running a package that the distribution's own infrastructure carries. The cost is that release timing is now coupled to the channel: a new version lands in the three ecosystems at whatever pace they sync.

There is a fourth path for people who want something earlier. The README links to a canary build status badge pointing at the canary workflow, and the root package.json has separate scripts for it.

    "start:canary": "turbo run start:canary",
    "build:canary": "turbo run build:canary",

A canary channel is the standard way to let people run an unreleased build without it being called stable, and the existence of a dedicated workflow and dedicated scripts means the canary is a first class output rather than something a maintainer builds by hand. The installation guide for all platforms is linked from the README at overlayed.dev/blog/installation-guide, which is the place to look for the per-platform detail that the README does not carry.

A pnpm and Turbo monorepo with a separate app, package and distribution layout

The repository root shows a workspace rather than a single application, and the tooling choices are consistent with a multi-package setup.

The root package.json is private and named overlayed-root, and it declares the packageManager as [email protected]. There is a pnpm-workspace.yaml, a pnpm-lock.yaml and a turbo.json, and Turbo is the task runner that drives the scripts. The root scripts are thin wrappers that fan out.

    "start": "turbo start",
    "desktop": "pnpm turbo run start --filter=desktop",
    "build": "turbo run build",
    "build:desktop": "turbo run build:desktop",
    "build:canary": "turbo run build:canary",

The desktop filter is worth noting, because the application is not only the desktop shell. The apps/ directory holds the applications in the workspace, and the desktop filter targets one of them specifically.

The build:desktop:unsigned variant is a detail that tells you about the release process. An unsigned desktop build is one that has not been code signed, and it exists as a separate target so that a build can be produced without a signing identity. That is a development and CI convenience, and it also means the signed artefacts are produced by a separate path.

The rest of the tree follows a conventional split. packages/ holds shared libraries, tooling/ holds the build and repository tooling, distribution/ holds the packaging configuration, and scripts/ holds repository automation such as the contributors script, which the root package.json drives with dl-contrib running a TypeScript file through tsx. The .thing/ directory at the root is not documented in the visible README, and LOCAL.md presumably covers local development setup, since it is the file that would tell a contributor how to run the thing on their own machine.

TypeScript is pinned at 5.4.5 in the root devDependencies, and prettier, eslint and tsx sit alongside it.

Release cadence is the open question in this project

The release history and the last push date do not line up, and the gap is worth naming before anyone adopts the tool.

The tags are v0.6.2 from 2024-09-22, v0.6.1 from 2024-09-15 and v0.6.0 from 2024-09-14. The last push to the repository was on 2026-10-10. So the newest tagged release is roughly two years older than the most recent commit, and the project is still on a 0.6 version number.

The most charitable reading is that the work in the two years since has been on the canary channel, on the build and release automation, on the desktop shell, or on dependencies, none of which produces a stable tag. The canary workflow badge in the README is evidence that an unreleased channel exists and is exercised continuously, which is consistent with a maintainer or a small group iterating against Discord's client changes and shipping fixes to canary before promoting them.

The less charitable reading is that the stable release has been neglected, and that a user installing through Winget, Homebrew or Flathub is running a two year old build.

There is no way to tell which from the visible documentation, and the README does not discuss release policy, versioning intent or a maintenance commitment. That is the single fact an adopter cannot verify from the repository, and it is a more consequential gap than the lack of a feature list.

What the repository does carry is the process scaffolding. There is a CONTRIBUTING.md, a CODE_OF_CONDUCT.md, a SECURITY.md, a .github/ directory with the canary workflow, and a scripts/ directory with the contributors generator. The presence of a security policy is notable for a desktop overlay, since an overlay that reads window titles and sits above other applications is a privileged position on the machine.

The commercial comparison is also not documented. Overlays for Discord voice chat are sold as subscriptions, and the free and open source framing in the description is aimed squarely at that market. What the repository does not provide is a feature comparison against those paid tools, so an adopter is choosing on the basis of the licence and the price rather than on a documented capability gap.

Where Overlayed is the wrong tool

The first wrong-tool case is a user who needs the overlay to stay in step with Discord's client automatically. A desktop overlay is coupled to the window it attaches to, and Discord's client changes its own window structure over time. The project ships canary builds partly because of this, but the visible documentation does not describe an update-check mechanism for the overlay itself, and a user whose Discord client has changed shape may find the overlay misaligned or detached until a new build catches up.

The second case is a user on a platform outside the three supported. The description names Mac, Linux and Windows, and the packaging covers exactly those three. There is no browser extension, and no mention of one, so the fallback for an unsupported system is a window the user arranges themselves.

The third case is a team that needs a supportable product. The project is community run, there is a Discord for contact rather than a support process, and the licence is AGPL-3.0, which carries copyleft obligations if you redistribute a modified build. For an organisation that wants to ship the overlay inside its own product or on its own infrastructure, the licence term and the absence of a maintenance commitment are both worth resolving in advance.

There is also a question about what the overlay needs access to. The repository does not document the permissions the application requests, which on Windows and macOS translates into screen recording and accessibility permissions, and on Linux into the portal interfaces Flatpak grants. For an application whose entire job is to draw on top of your screen, those permissions are intrinsic rather than surprising, but they are worth seeing stated rather than inferred, and the README does not state them.

What Overlayed does offer is clear enough. It is a free overlay for the platform you already use, installable with the package manager you already use, with a canary channel for people who want the newest build, and a codebase built on components that are individually replaceable if the project ever needs forking.

Editorial conclusion

Overlayed suits a Discord user on Windows, macOS or Linux who wants a voice chat overlay without a subscription and who is comfortable sideloading a canary build when a fix is not in the stable release. It does not suit a team that needs a supported product, since the project is community run with no support commitment, and it does not suit a user who needs the overlay to track Discord's own client updates automatically. Before adopting, install the stable package for your platform, check the release history against the last push on 2026-10-10 because the newest tag is still v0.6.2 from 2024, and read the installation guide for your platform before enabling a canary build.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. overlayeddev/overlayed on GitHub
3. Project website
4. README
5. Releases