Better Hub ships a browser extension rather than asking you to move your repositories

Built by people who spend all day on GitHub

The Why section is two sentences and it is the clearest statement of intent in the repository.

At Better Auth, the team says they spend a lot of their time on GitHub, so they decided to build the experience they actually wanted. Better Hub is described as improving everything from the home page to repo overview, PR reviews and AI integration, faster and more pleasant overall.

So this is a competing front end over GitHub data, built by the Better Auth team.

The feature list is grouped by the object it acts on.

Repo overview gives a cleaner layout with README rendering, a file tree and an activity feed. PR reviews give inline diffs, AI-powered summaries and review comments. Issue management is triage, filter and act.

Then three features that are not about a single object. CI/CD status shows workflow runs and compares across branches. Security advisories track vulnerabilities per repo. And the command center searches repos, switches themes and navigates anywhere on `⌘K`.

The security advisories and CI/CD entries are the ones that separate it from a skin. A tool that reads workflow run history and vulnerability data for your repositories has a view across all of them, not just the one you have open.

The project site is better-hub.com, the licence is MIT, and the last push was on 2026-05-31.

Ghost is the AI feature and the command palette is the entry point

Two entries in the feature list define the interaction model, and both are about not using a mouse.

The AI assistant is called Ghost. Its description covers four jobs: reviewing pull requests, navigating code, triaging issues, and writing commit messages, with `⌘I` to toggle it.

Four capabilities is a lot to ask of one assistant, and the split is worth noting. Reviewing a PR and writing a commit message are the two most concrete: both have a defined input and a defined output. Navigating code is the one that needs the most access to your repository, since it has to understand the tree, the search results and the file you are looking at.

The other shortcut is `⌘K` for the command center, which searches repos, switches themes and navigates anywhere. A palette that can switch themes is a small thing that tells you this is built by people who use it all day.

Then the general principle, stated as its own bullet: keyboard-first, with most actions accessible via shortcuts.

For an evaluation, that is worth testing rather than accepting. The features that pair with shortcuts are the ones that will be fast; anything reachable only by clicking is the thing you will do a hundred times a day.

The browser extension is the adoption strategy

The last feature in the list is the one that determines whether anyone tries this.

A browser extension that adds an Open in Better Hub button on GitHub pages, with Chrome and Firefox supported.

That is a deliberate decision about switching costs. Asking a team to migrate their repositories, their issue tracker and their review history into a new product is a project. Adding a button that appears on the page they already visit is not.

It also means Better Hub is a front end over GitHub rather than a replacement for it. Which follows from the Why section, since the team describes it as improving the experience of an existing workflow.

The security question that creates is obvious and worth asking directly. An extension that reads your repository content, workflow runs and security advisories, and that can write review comments, is asking for substantial access to your GitHub account and your organisation's data.

The repository has a SECURITY.md at the root, and a SECURITY advisories feature in the product itself, so the team is not unaware of this area. But a SECURITY.md is where vulnerabilities in Better Hub get reported, not a description of what the extension requests from GitHub. That description is not in the README, and for an extension that is the first thing to look for before installing it in an organisation.

A bun monorepo with oxlint and oxfmt doing the checking

The package manifest describes the whole development workflow, and it is unusually compact.

"workspaces": ["apps/*", "packages/*"],
"scripts": {
  "go": "bun run",
  "build": "bun run --workspaces build",
  "dev": "bun run --workspaces dev",
  "check": "bun lint && bun fmt:check && bun typecheck",
  "fix": "bun lint:fix && bun fmt"
}

Two things stand out. The `go` script is an alias for `bun run`, so every command can be typed with the same prefix. And `check` chains lint, format check and typecheck, with `fix` as its counterpart, which is the same two-command shape that good projects converge on.

The linting is oxlint and the formatting is oxfmt, both at recent versions, with their own ignore files at the root, `.oxlintignore`, `.oxfmtignore` and `.oxfmtrc.json`. This is a relatively new dependency choice in a TypeScript project.

The consequence is visible in the git hooks. `simple-git-hooks` installs on prepare, and lint-staged runs `oxfmt --write` then `oxlint --fix` on staged TypeScript, and `oxfmt --write` on staged JSON. So formatting and linting both happen at commit time and neither needs a separate pass.

The typecheck script is unusual: `bun -r exec tsc --noEmit`, running the TypeScript compiler recursively across the repository in one invocation rather than per workspace.

The package manager is pinned to `[email protected]`, and the root is `@better-hub/monorepo`, private, with `apps/` and `packages/` as the workspace globs.

Postgres on 54320 and a Redis HTTP bridge on 8079

The docker-compose file is short and three details in it are informative.

Postgres is `postgres:16-alpine` with `restart: unless-stopped` and a named volume for its data. The command line raises `max_connections=300` from the default, which tells you the application is expected to hold a lot of connections, which in turn points at a connection pool somewhere in the application.

The password is interpolated from an environment variable with a fallback, `POSTGRES_PASSWORD:-postgres`, and the database is named `better_hub`. The port mapping is `127.0.0.1:54320:5432`, so the database is published on a non-standard host port and, more importantly, bound to loopback rather than to all interfaces. That is a deliberate choice for a development stack and a common source of accidents when copied to a shared machine.

Redis is `redis:7-alpine` with a named volume and no published port, which means it is reachable only inside the compose network.

Then the third service, which is the interesting one. `redis-rest` runs `hiett/serverless-redis-http:latest` and publishes `127.0.0.1:8079:80`, configured with `SRH_MODE: env`, a `SRH_TOKEN` defaulting to `local_token`, and a connection string pointing at the internal Redis.

This third-party service provides an HTTP interface to Redis with token-based configuration.

The volumes section declares `postgres_data` and `redis_data`, so state survives `docker compose down`.

There is no release history, so there is no version to pin, and the repository does not document how to run the stack beyond the compose file itself.

Editorial conclusion

Adopt Better Hub if you want a different review and triage experience on GitHub without migrating your repositories, since the extension puts it one click away from a GitHub page. Skip it if your organisation standardises on a self-hosted GitLab or Gerrit, since this is a front end for GitHub data. Verify first how it authenticates to your GitHub organisation and what permissions the extension needs, because a tool that reads your code needs an answer before you install it.

Frequently asked questions

Official sources

1. better-auth/better-hub on GitHub
2. Issues
3. License: MIT
4. Project website
5. README