Gitify: GitHub and GitLab notifications in your menu bar

The notification problem Gitify targets

Git hosting platforms each have their own notification inbox, and each one wants a browser tab. If your work spans a GitHub organisation, a self-managed GitLab instance and a company Gitea server, you end up checking three web UIs on a rotation, and the only thing they share is that you forget about them. Gitify's answer is to move the inbox out of the browser and into the operating system tray or menu bar, where a badge count is visible without a tab.

The audience is narrow but real: developers and reviewers who are already in a tray-based workflow on macOS, Windows or Linux and who authenticate against more than one forge. The README states the app supports GitHub Cloud, GitHub Enterprise Server, GitHub Enterprise Cloud with Data Residency, Gitea, Forgejo, Codeberg, Bitbucket Cloud and GitLab Cloud and Self-Managed. A single-forge user on GitHub can get most of this from GitHub's own notification UI, so the multi-forge list is where the project earns its place.

How the forge adapter pattern actually splits the feature set

The repository describes a forge adapter pattern, with adapters living under src/renderer/utils/forges/, and the README states that a new forge needs an adapter plus a designated maintainer. That design choice explains the support table better than any feature list: capabilities are per adapter, not global.

GitHub Cloud is the only row with every column ticked: notifications, mark read, mark done, unsubscribe and enriched details. GitHub Enterprise Server below 3.13 loses mark done. Gitea, Forgejo and Codeberg show notifications and mark read, with dashes for mark done, unsubscribe and enriched details. Bitbucket Cloud is the same shape. GitLab Cloud and Self-Managed has notifications, mark read, mark done and enriched details, but no unsubscribe. Azure DevOps and Gerrit are listed as considering, with every capability column empty.

So the honest reading is that Gitify is a full client for GitHub and a read-mostly client for everything else. If your daily loop involves unsubscribing from threads on Gitea, the adapter does not offer it. The table is also version-sensitive: the GitHub Enterprise Server row splits at 3.13, which means the same server product behaves differently depending on how recently it was upgraded.

Installing Gitify and authenticating your first account

The README's quick start is three steps: download from gitify.io, install and launch for your platform, then authenticate with one or many supported accounts. macOS users have a second path through Homebrew, which installs the cask named gitify:

brew install gitify

After that command completes, the app is available as a normal macOS application and launches from the menu bar. The README does not document a first-run wizard, so the authentication flow is reached from the app itself once it is running.

If you want to build from source rather than use a release, the README gives three pnpm commands:

pnpm install
pnpm build
pnpm dev

The package.json adds a start script that chains the build and the dev server, plus platform packaging scripts named package:macos, package:win and package:linux, which run electron-builder with the corresponding target. The dev script runs the Vite dev server and GraphQL codegen concurrently, which tells you the app talks to forges through GraphQL in at least the GitHub case. The README points to CONTRIBUTING.md for the full development instructions rather than reproducing them.

Where Gitify stops being the right tool

The support table is the first limitation, and it is a hard boundary rather than a rough edge. Azure DevOps and Gerrit appear only under the considering symbol, and the README notes that a new forge needs an adapter plus a designated maintainer. That is a policy, not a backlog promise: if no maintainer picks up the adapter, the forge stays unsupported.

The second limitation is capability asymmetry. Mark done and unsubscribe are GitHub and GitLab features in this app. On Gitea, Forgejo, Codeberg and Bitbucket Cloud you can read notifications and mark them read, and nothing more. Enriched details, which the table treats as a separate capability, are also absent for those four forges, so the notification you see there carries less context than the GitHub equivalent.

The third is that Gitify is a notification surface, not a triage system. Nothing in the README describes rules, routing, escalation, labels or automation. If your team needs notifications to trigger a workflow, this app is the wrong layer, and the README does not claim otherwise.

Gitify against a browser tab and against forge-native clients

The obvious alternative is the forge's own web notification page, kept in a pinned browser tab. The difference in approach is where state lives. A pinned tab has every capability the forge exposes, including unsubscribe and mark done on forges where Gitify's adapter has neither, but it costs a tab and it does not aggregate across hosts. Gitify trades capability depth for one list and a tray badge.

A second alternative is a single-forge desktop client. GitLab and GitHub both have their own surfaces, and if you only use one forge, a native client will track that forge's features more closely than an adapter written by a third party. Gitify's advantage only appears when the second and third forge enter the picture, because that is when the aggregation cost of browser tabs becomes real.

A third comparison is against nothing at all: turning off email notifications and checking the web UI when you remember. That is free and has no adapter table to consult, but it is also the workflow Gitify exists to replace.

Maintenance cadence, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-08-28. The release list shows v7.5.0 on 2026-08-24, v7.6.0 on 2026-08-26 and v7.7.0 on 2026-08-28, so three releases landed inside five days, while package.json carries version 7.8.0. That pattern suggests a fast minor-release cadence rather than long-lived stable branches, and the repository includes release-please-config.json and a release-please manifest, which is consistent with automated release PRs.

For an operator, the upgrade cost is mostly the Electron packaging cycle: releases arrive frequently, and the app is distributed as a signed desktop build, so you reinstall rather than pin a server version. The repository also carries renovate.json and a Renovate badge, which means dependency updates are automated on the maintainer side; that reduces the risk of stale Electron versions but does not remove the need to reinstall.

Gitify is MIT licensed. In practical terms that permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained, but the LICENSE file is the authority and this is not legal advice. One licence-adjacent detail worth checking before you build on the code: the repository contains a patches/ directory and a pnpm-workspace.yaml, so the build applies patches to dependencies, and anyone forking should confirm those patches are compatible with their own distribution plans.

Editorial conclusion

Adopt Gitify if you work across several forges and want one tray list, and you are willing to accept that Gitea, Forgejo, Codeberg and Bitbucket Cloud only support notifications and mark read. Do not adopt it if Azure DevOps or Gerrit is your forge, since the README lists both as considering only, or if you need mark done and unsubscribe everywhere rather than on GitHub and GitLab. Verify first that your forge version matches the support table, particularly GitHub Enterprise Server below 3.13 where mark done is listed as unsupported, and check the adapter policy in CONTRIBUTING.md before assuming a new forge will be added on request.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes