unsubbed.co

Mergeable

Self-hosted personal dashboards tool that provides better inbox for GitHub pull requests.

Self-hosted GitHub pull request management, honestly reviewed.

TL;DR

  • What it is: A browser-based dashboard that turns GitHub’s scattered pull request notifications into a structured, filterable inbox [README].
  • Who it’s for: Developers and engineering leads who work across multiple GitHub repositories and lose track of which PRs need their attention. Not a tool for non-technical founders.
  • Cost savings: There is no SaaS bill to replace — GitHub PR notifications are free and Mergeable is free. The value is time, not money: you stop clicking through five tabs to find the one PR that’s been waiting on your review for three days [README][website].
  • Key strength: No backend required. All data stays in your browser’s local storage. No OAuth app to install, no server to trust with your GitHub token [README].
  • Key weakness: 104 GitHub stars at the time of this review. This is a small, early-stage project with an unclear roadmap and no visible commercial backing. Treat it as a useful utility, not infrastructure.

What is Mergeable

Mergeable is a static web application that connects to your GitHub account and displays your pull requests in a configurable dashboard. The tagline — “Never miss a pull request again” — is an honest description of the problem it solves [website].

GitHub’s default notifications and PR pages were not designed for engineers who touch multiple repositories daily. The native inbox shows everything chronologically. There is no way to separate “PRs I’m blocking” from “PRs blocked on CI” from “PRs I need to review today” without clicking through each one [README].

Mergeable fixes this by letting you define sections — named groups of PRs — using GitHub’s search query syntax. You write the same query you’d type into GitHub’s search bar, and Mergeable shows that slice of your PR universe as a named column. The “attention set” feature goes one step further: it highlights PRs where the ball is specifically in your court, filtering out the noise of PRs waiting on CI or on someone else’s review [README].

The architectural choice worth noting: the tool stores everything in browser local storage. There is no Mergeable server receiving your GitHub token, no account to create, no data leaving your browser beyond the GitHub API calls the app makes on your behalf [README]. For teams with strict data handling requirements, this matters.

The project is MIT-licensed, maintained by a single contributor (pvcnt), and has a public hosted instance at https://app.usemergeable.dev if you want to try it before self-hosting [README][website].


Why people choose it

There is no substantial third-party review coverage of Mergeable at this time. With 104 GitHub stars, it has not reached the threshold where bloggers benchmark it against competitors. The decision to use it comes from a simple calculation: if you find yourself spending meaningful time each morning reconstructing the state of your PR queue from GitHub’s native interface, a five-minute setup of a PR inbox pays for itself immediately.

The “attention set” concept — borrowed from code review systems like Gerrit and Google’s internal tooling — is the most differentiated feature. Axolo’s documentation [3] describes a similar concept for Slack-based PR workflows, where pull requests move through statuses: Draft, WIP, Reviewable, Mergeable, Closed, Merged. Mergeable (the tool) operationalizes this in a standalone UI without requiring a Slack integration or a third-party bot.

The zero-backend model also stands out in a category where most alternatives require either GitHub app installation or a server-side component that touches your repositories. Engineers working in GitHub Enterprise environments with restricted OAuth app approvals will find this appealing — Mergeable connects directly via personal access token with no app installation required [README].


Features

From the README and website:

Core dashboard:

  • Define sections using GitHub search query syntax — any query that works in GitHub’s search bar works as a section filter [README]
  • Sections are persistent and configurable per user in browser local storage [README]
  • Attention set: surfaces PRs where it is your turn to take action, reducing the noise of PRs blocked on others [README]
  • Keyboard shortcuts for navigating between sections and PRs [README]

Multi-instance support:

  • Connect to multiple GitHub instances simultaneously [README]
  • Supports private GitHub Enterprise installations alongside github.com [README][website]
  • Useful for contractors or employees who maintain both a personal GitHub account and an enterprise account

Privacy and data model:

  • All data stored locally in browser storage — no Mergeable server, no telemetry beyond GitHub API calls [README]
  • No GitHub app installation required — works with a personal access token [README]
  • The self-hosted version is identical to the public instance in features

Deployment options (self-hosted):

  • Static web app built on Vite + Turborepo + pnpm [README]
  • Can be deployed on bare metal, Kubernetes, or any PaaS that serves static files [website]
  • No database, no backend, no server-side dependencies to manage

What it does not have:

  • Native notifications or email digests
  • PR commenting or review submission from within the interface
  • Integration with project management tools (Linear, Jira, GitHub Projects)
  • Team dashboards — this is a personal tool, not a shared team view
  • Mobile app or responsive mobile layout

Pricing: SaaS vs self-hosted math

This section is simpler than most tools in this category.

Mergeable public instance (https://app.usemergeable.dev): Free. No tiers, no usage limits mentioned [website][README].

Self-hosted: Free. MIT license, zero infrastructure cost beyond a static file host. You can serve it from GitHub Pages, Cloudflare Pages, Netlify, or any $0/mo static hosting option. No database, no backend server means the hosting cost is effectively zero [website][README].

What you’re replacing: GitHub’s native PR notifications are free. Mergeable is not replacing a paid SaaS subscription — it is replacing time. If you spend 20 minutes each morning reconstructing which PRs need your attention across repositories, Mergeable recovers that time. That is the value proposition, not cost reduction.

Paid alternatives in this space for comparison:

  • Axolo (Slack-based PR notifications): paid plans after a free tier, pricing not public at time of writing [3]
  • LinearB (engineering metrics + PR management): enterprise pricing, not suitable for individuals or small teams
  • Swimm (code documentation, not directly comparable): separate use case

If you are an individual engineer or small team on GitHub Free/Pro, Mergeable costs nothing to try and nothing to keep.


Deployment reality check

The website describes deployment as “easy” on bare metal, Kubernetes, or PaaS [website], which for a static web app is accurate. There is no backend to configure. The build output from pnpm run dev (or a production build) is a folder of static HTML/CSS/JS files.

What you actually need:

  • A static file host (Cloudflare Pages, Netlify, Vercel, nginx serving a folder — anything works)
  • A GitHub personal access token with repo scope to read PR data
  • Optional: a custom domain if you want something other than a platform-assigned URL

What can go sideways:

  • GitHub API rate limits. The tool makes GitHub API calls directly from your browser. Personal access tokens are rate-limited to 5,000 requests/hour. If you have hundreds of open PRs across dozens of repositories and refresh frequently, you may hit this. There is no server-side caching layer because there is no server.
  • Browser storage limits. Data is stored in localStorage, which browsers cap at roughly 5–10MB per origin. For engineers with very large PR queues, this could be a constraint — though in practice, PR metadata is small.
  • Single-maintainer risk. The project has one contributor visible in the GitHub history (pvcnt). There is no public company, no funding announcement, and no roadmap document. This is the most significant operational risk for any team considering it as a daily workflow tool.
  • No offline mode. The tool fetches live data from GitHub on each load. No internet, no PRs.

Realistic setup time: Under 30 minutes for anyone comfortable with a personal access token and a static host. The public instance at https://app.usemergeable.dev is ready to use in under 5 minutes — enter your GitHub token, configure your first section, done.


Pros and cons

Pros

  • Zero-trust architecture. No Mergeable server ever touches your GitHub token or repository data. Everything happens in your browser [README]. This is rare in the PR tooling category.
  • No GitHub app installation required. Works via personal access token, which is a meaningful advantage in enterprise environments where OAuth app approvals require IT tickets [README].
  • Multi-instance support. Connect github.com and GitHub Enterprise in the same view — a real pain point for contractors and open-source contributors [README][website].
  • Flexible section queries. The GitHub search query syntax is expressive. You can build sections like “assigned to me + awaiting review + not draft + not mine” in a single query.
  • MIT license. Fork it, modify it, embed it in your internal tooling. No restrictions [README].
  • Genuinely simple. There is no configuration surface to wrestle with beyond “write GitHub search queries.” Non-engineers who happen to use GitHub could learn it in ten minutes.
  • Free public hosted instance. Evaluate it in five minutes without deploying anything [README].

Cons

  • 104 GitHub stars = early stage. This is not a criticism of quality — it is a factual signal about adoption, community size, and bus factor. The project could be abandoned or go unmaintained without warning. Do not build a team workflow around it without accepting this risk.
  • Personal tool only. There is no team view, no shared dashboard, no way to see your team’s collective PR queue. Each engineer maintains their own browser-local configuration [README].
  • No notifications. Mergeable is a dashboard you visit, not a system that alerts you. It does not send emails, push notifications, or Slack messages. If your problem is “I forget to check PRs,” this does not fix that — Axolo or GitHub notification settings are better suited.
  • Browser-local storage has limits. The data model that makes Mergeable private also means you cannot access your configured sections from a second device or browser. Your sections exist in one browser profile on one machine [README].
  • No GitHub comment or review actions. You read PR status in Mergeable; you do everything else in GitHub. It is a read-only dashboard.
  • No roadmap or community forum. The GitHub repository has no public discussions enabled (at time of writing) and no ROADMAP file. Feature requests have nowhere to go beyond filing issues.

Who should use this / who shouldn’t

Use Mergeable if:

  • You are an individual developer or engineering lead tracking PRs across 3+ repositories and find GitHub’s native PR view inadequate.
  • You work in a GitHub Enterprise environment where installing OAuth apps requires approval, and you need something that works with just a personal access token.
  • You want a zero-backend, private PR dashboard you can self-host on a static file host at no cost.
  • You are comfortable with GitHub’s search query syntax — the configuration model requires it.

Skip it if:

  • You want team-level visibility into PR status across your whole engineering team. Look at LinearB, Axolo, or GitHub Projects instead.
  • You need alerts when PRs need your attention, rather than a dashboard you proactively check. Axolo (Slack-based) or GitHub’s notification settings solve this better.
  • You are building on a tool long-term and need a committed maintainer or commercial backer. At 104 stars and single-contributor, Mergeable is not there yet.
  • Your team uses GitLab or Bitbucket. This is GitHub-only [README].

Alternatives worth considering

  • GitHub’s native PR inbox (https://github.com/pulls) — the obvious baseline. Free, always up to date, no setup. Lacks cross-repo section organization and the attention set concept. For engineers with 1–2 repositories, often sufficient.
  • Octobox — self-hosted GitHub notification manager, older project, similar privacy-first philosophy. Focuses on notifications rather than PR organization.
  • Axolo — Slack-based, creates dedicated Slack channels per PR, surfaces PR status using a status model similar to Mergeable’s attention concept [3]. Requires Slack and GitHub app installation. Better for teams, worse for individuals.
  • Linear (with GitHub sync) — if your team already uses Linear for issue tracking, the GitHub integration surfaces PR status in context of the tickets they close. Different use case but overlapping value.
  • Gitify — desktop app for GitHub notifications, macOS/Windows/Linux. Closer to notification management than PR organization.
  • Refined GitHub (browser extension) — improves GitHub’s native interface without replacing it. Lower commitment if you just want marginal improvements to the existing experience.

Bottom line

Mergeable is a sharp, single-purpose tool that solves one real problem: GitHub’s PR interface was not designed for engineers who work across many repositories. The solution — configurable sections powered by GitHub search queries, an attention set that surfaces PRs waiting on you specifically, and a zero-backend architecture that keeps all data in the browser — is well-conceived and works as described.

The honest caveat is the one you cannot ignore: 104 GitHub stars, one visible contributor, no commercial backing, no public roadmap. For a personal developer workflow tool, that risk is acceptable. For a team process you depend on daily, it is a real concern. Use the public instance (https://app.usemergeable.dev) to evaluate it; self-host if you adopt it seriously; and keep a mental backup plan for the day maintenance stops.

If the setup is a blocker, or if you need a full team PR workflow beyond what Mergeable provides, upready.dev can assess your engineering tooling stack and recommend the right combination.


Sources

  1. Brandon Brown, brandonb.ca“Orchestrating my homelab self-hosted services with Komodo and git” (Dec 22, 2025). https://brandonb.ca/homelab-komodo-docker-orchestration
  2. env zero documentation“Bypass Apply Mergeability Check”. https://docs.envzero.com/guides/policies-governance/bypass-apply-mergeability-check
  3. Axolo documentation“Understanding Axolo pull request status”. https://axolo.co/docs/makethebest/understanding-pr-status

Primary sources: