# bisibility: a self-hostable SEO rank tracker that bills your own providers

> bisibility is a TypeScript SEO platform for tracking Google rankings, researching keywords, inspecting backlinks and watching AI answers, built on Next.js, PostgreSQL and Temporal. It ships no data of its own, so every real result comes from provider accounts you connect yourself, which makes the cost model and the AGPL licence the two decisions that matter before you adopt it.

**CorgiCorner/bisibility** — Open-source SEO platform. Track Google rankings. Research keywords. Inspect backlinks.

- Repository: https://github.com/CorgiCorner/bisibility
- Website: https://bisibility.com
- Stars: 588 · Forks: 34
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/corgicorner-bisibility

## What bisibility tracks and who it is for

bisibility is an open-source SEO platform whose stated scope has four parts. The first is seeing which Google rankings changed: it tracks ranking URLs and their history by market and by device, schedules checks, sets alerts, and compares competitor Share of Voice. The second is finding keywords worth investigating, with suggestions, search volume, trends, CPC, difficulty and intent. The third is understanding a backlink profile, including referring domains, new and lost links, and link attributes. The fourth is following selected AI prompts over time, where recurring AI Tracking retains answers, citations and comparable history.

That last capability comes with an explicit caveat in the documentation, and it is worth repeating. The observations come from supported consumer-answer sources, model API responses and Google AI Overview, and source, model and market availability varies. The documentation states plainly that these observations do not cover every AI service or market.

The audience is therefore an in-house or agency SEO team, or an engineer who wants the same data in scripts and agent workflows. The repository topics describe it as a keyword tracker and SERP tracking platform, and the package description calls it a self-hostable keyword rank tracker with keyword and backlink research, MCP and bring-your-own providers.

Two deployment paths exist. There is a hosted beta where the application stack and scheduling are operated for you, and a self-hosted path where you run the app and keep its history in your own PostgreSQL database.

## The local demo is disposable and the authentication is insecure

There is a third path, and it is the one to start with. The documentation points new users at a live demo and at a local demo quickstart that runs with synthetic data.

The quickstart is the fastest way to see the interface and the workflows without spending anything on provider calls. The documentation is also explicit about its limits: the local demo is disposable and uses intentionally insecure demo authentication. Use the production guide for a real deployment, and see the deployment options page for current hosted beta limits and what each path requires.

That sentence matters more than it looks. A demo build with demo authentication is a developer convenience for exploring screens with fake data, not a base you harden. Anyone treating it as a starting point for a real deployment is carrying an authentication decision that the documentation already flagged as wrong for production use.

For a self-hosted installation the documented requirement is larger than a single container. The production guide covers running the app and keeping its history in your PostgreSQL database, and scheduled work also needs the worker and Temporal. The repository tree confirms that shape, with separate Dockerfiles for the app and the worker, and separate compose files for the main stack, the worker, Temporal, a mail service, a debug setup, a self-hosted setup and a Sonar setup.

## Bring your own provider means the data is not included

The billing model is the defining design choice of this project, and it is stated without ambiguity.

Connect your own provider accounts and credentials. Google rank checks support DataForSEO and SerpAPI, while keyword, backlink and domain research use DataForSEO. AI Tracking uses supported DataForSEO answer sources and Google AI Overview sources. Supported configurations are checked before any provider work happens.

Real provider-backed data is not included with the application. Provider usage is billed directly by your connected provider on both hosted and self-hosted deployments. Self-hosting has no application subscription or per-keyword licence fee, but your infrastructure and provider usage remain separate costs. The hosted service has current beta limits, which the documentation notes may change as the beta progresses.

Two budget rules are stated. AI Tracking schedules start disabled, and running paid observations or enabling a schedule requires a fresh review and explicit cost consent. Project spending caps apply together with connection budgets, and unconfirmed historical costs block new paid calls on the affected connection or project until they are reconciled.

Credentials stay in your self-hosted instance, and the hosted service stores them encrypted. The documentation also points you to a rank-check cost calculator before enabling a large schedule, which tells you how variable the bill can get when you schedule checks across markets and devices.

## The metering layer and the upgrade procedure you have to follow

Both hosted and self-hosted builds use Usagekit Meter for paid-call admission and its PostgreSQL Store for usage history. That is a separate metering layer sitting in front of the provider calls, and it has consequences for how you upgrade.

The documented procedure is explicit. Keep the migration runner, the app and the worker on the same release, database, schema and METERING_NAMESPACE, whose default is default. Run the migration script before starting upgraded processes, and enable worker maintenance with SCHEDULED_MAINTENANCE_ENABLED=1 for reservation expiry and receipt reconciliation. Disabling maintenance does not disable budget enforcement.

The migration command is wired into the package scripts:

```json
    "db:migrate": "node --experimental-transform-types --import ./lib/temporal/register-loader.mjs scripts/deploy/migrate.ts",
```

The composition files show how much of the application is configuration driven. The shared environment anchor alone carries a long list of switches for alert delivery, its failure rate threshold, minimum attempts, sweep intervals and window hours, alert digests, spike detection multipliers, health intervals, audit retention, AWS credentials, the Better Auth secret and URL, and several rate limits for the anonymous API, the keyed API and the DataForSEO provider path:

```yaml
x-app-env: &app-env
  ACHIEVEMENTS_ENABLED: ${ACHIEVEMENTS_ENABLED:-}
  BETTER_AUTH_URL: "${BETTER_AUTH_URL:?Set BETTER_AUTH_URL to the public app origin in .env}"
  BISIBILITY_API_ANON_RATE_LIMIT_PER_MINUTE: ${BISIBILITY_API_ANON_RATE_LIMIT_PER_MINUTE:-}
```

The BETTER_AUTH_URL entry fails the compose file outright if it is not set, which is a sensible pattern for a value that must not be guessed.

## Next.js, Prisma, Temporal and a strict Node range

The stack is visible in the package manifest and the container build.

The package name is bisibility, the version is 0.38.0, the package is marked private, and the licence field names AGPL-3.0-only:

```json
  "name": "bisibility",
  "version": "0.38.0",
  "license": "AGPL-3.0-only",
```

The runtime constraint is tight. The engines field requires node >=22.23.1 <23, and the packageManager field pins npm at 10.9.3. The devEngines block repeats those requirements for development. The build script is next build, the start script is next start, and the database scripts run prisma generate, prisma db seed and the migrate runner. The presence of prisma.config.ts and a prisma/ directory confirms Prisma as the database layer.

The Dockerfile goes out of its way to make the build reproducible. It pins npm inside the image so the lockfile resolves to an identical dependency tree, with the comment that the base image bundled npm can differ and reject the lockfile:

```bash
RUN --mount=type=cache,target=/root/.npm npm install -g npm@10.9.3 && npm ci
```

It also builds a self-contained Prisma CLI tree for the runner image, because the platform deploy hooks execute in the final image where copying only node_modules/prisma and node_modules/@prisma is not enough.

Temporal appears in the migrate command itself, and there is a compose.temporal.yaml alongside the other compose files, which tells you the workflow engine is a first class part of the deployment rather than an optional extra.

## REST, OpenAPI, MCP and three SDKs over the same operations

The dashboard shares its authenticated operations with REST API v1, an OpenAPI description and MCP. The documentation puts it plainly: you can read stored history, build reports, or connect SEO data to scripts and agent workflows through the TypeScript, Python and Go SDKs.

The set of surfaces is what makes this usable as infrastructure rather than as a dashboard. A dashboard you have to look at does not fit an agent workflow. A REST API with an OpenAPI description does, and the MCP server lets a tool that speaks that protocol query the same data.

There is also a CLI, documented separately, and signed webhooks for pushing events out. The repository carries an examples/ directory with concrete directories for ai-tracking, cli, deploy-webhooks, go, mcp, python and ts, plus a manifest.json and a docs-tested-clients.json. The presence of a docs-tested-clients file suggests the documentation examples are checked against real clients rather than written and forgotten.

The top level tree reinforces the production intent. There is a Sentry configuration for both edge and server, a sonar-project.properties file, a Storybook setup, a .gitleaks.toml secret scanner configuration, a biome.json formatter configuration, an eslint config, a Playwright config, and an e2e/ directory. A .claude-plugin/ directory at the root indicates the MCP surface is packaged for Claude as well.

## Where bisibility is the wrong tool

The clearest wrong case is expecting data to be there. If you want rankings, volumes, backlinks and AI answers without connecting a provider account and without paying per call, this project does not deliver that. The documentation is unambiguous that real provider-backed data is not included.

The second wrong case is expecting a small deployment. A self-hosted install is a Next.js app, a worker, Temporal and PostgreSQL, upgraded together on the same release and schema. A team without an operations person will spend more time on the platform than on the SEO questions it was meant to answer.

The third is AI coverage. The AI Tracking feature is explicitly partial. Availability of source, model and market varies, and the observations do not cover every AI service or market, so a report that claims to track AI visibility across the board would be reading more into the feature than it supports.

The fourth is licence comfort. AGPL-3.0-only is a strong copyleft licence, and a self-hosted web application that serves users over a network is exactly the case that licence was written for. An organisation that cannot distribute its modified versions of the code will find this a problem, and the honest alternative is a different tool rather than a workaround.

Compare that with the commercial subscription model, where a vendor bundles its own data crawl into a monthly fee. The difference in approach is real and worth stating plainly: bundled data means a single predictable invoice but a closed dataset and a vendor relationship, while bring-your-own-provider means you control the account, the credentials and the raw spend, at the cost of wiring up and budgeting against at least one external API.

## Licence, releases and what changes between versions

bisibility is released under the AGPL-3.0-only licence, and the repository carries both a LICENSE file and a NOTICE file alongside a DEPENDENCY_LICENSES.md file, which is the usual practice when a project aggregates dependencies with their own terms.

The AGPL obligations are worth understanding before deployment rather than after. The licence requires that a modified version, when it is used over a network by users, offers those users the corresponding source. That is the specific term that differs from the older GPL, and it is why the hosted beta arrangement and the self-hosted arrangement have different consequences for a company that modifies the code. Read the LICENSE file yourself and take your own advice on it, because this is not a legal opinion.

The release cadence is fast and the version numbers are honest about it. v0.36.0 landed on 2026-10-17, v0.37.0 on 2026-10-19 and v0.38.0 on 2026-10-19. The repository is not archived, and the last push was on 2026-10-19, the same day as the newest tag.

A 0.x line with three releases in three days means the project is moving quickly and that upgrade notes matter. The CHANGELOG.md and ROADMAP.md files are there for that reason, and the documented requirement to keep the migration runner, app and worker on the same release is the clearest signal that a partial upgrade will break the metering layer. Pin a version, migrate as a set, and read the changelog before you move.

## Conclusion

bisibility suits a team that wants ranking history, keyword and backlink research in a system it hosts and drives with its own provider accounts, and that needs the same data exposed through an API, an MCP server and SDKs. It does not suit anyone expecting turnkey data, since provider usage is billed to you directly, nor anyone unwilling to run Postgres, a worker and Temporal alongside the app. Before adopting it, price a real rank-check schedule against your DataForSEO or SerpAPI plan, read the AGPL-3.0-only terms with your own counsel before exposing it over a network, and set the project spending caps before you enable AI Tracking schedules, which start disabled and need explicit cost consent.

## FAQ

### Does bisibility include ranking and keyword data, or do I need provider accounts?

You need provider accounts. Google rank checks support DataForSEO and SerpAPI, and keyword, backlink and domain research use DataForSEO, with credentials you connect yourself. Real provider-backed data is not included, and provider usage is billed directly by your provider on both hosted and self-hosted deployments.

### What does it take to self-host bisibility?

The production guide covers running the app and keeping its history in your own PostgreSQL database, and scheduled work also needs the worker and Temporal. The migration runner, app and worker must run on the same release, database, schema and METERING_NAMESPACE.

### Is the local bisibility demo safe to deploy?

No. The documentation states that the local demo is disposable and uses intentionally insecure demo authentication, and that the production guide should be used for a real deployment.

### How do I control spending on bisibility provider calls?

Project spending caps apply together with connection budgets, and unconfirmed historical costs block new paid calls until they are reconciled. Both hosted and self-hosted builds use Usagekit Meter for paid-call admission, and AI Tracking schedules start disabled and require explicit cost consent before running paid observations.

### Which Node version does bisibility need?

The package manifest requires node >=22.23.1 <23, with npm pinned at 10.9.3, and the Docker build installs that npm version explicitly so the lockfile resolves to an identical dependency tree.

### Can I query bisibility from scripts and AI agents?

Yes. The dashboard shares its authenticated operations with REST API v1, OpenAPI and MCP, and there are TypeScript, Python and Go SDKs, a CLI, and signed webhooks for pushing events out.

## Sources

- [CorgiCorner/bisibility on GitHub](https://github.com/CorgiCorner/bisibility)
- [License: AGPL-3.0](https://github.com/CorgiCorner/bisibility/blob/main/LICENSE)
- [Project website](https://bisibility.com)
- [README](https://github.com/CorgiCorner/bisibility/blob/main/README.md)
- [Releases](https://github.com/CorgiCorner/bisibility/releases)

---

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