NiubiGEO: self-hosted AI brand visibility reports for a domain

The question NiubiGEO answers: does an AI model recommend your product, and who does it name instead

Ask a chat model for tools in your category and you get a short list. Your product may not be on it, and the list may differ between models. NiubiGEO is built around that gap. The README states the purpose plainly: enter a domain, compare how models describe your product, who they recommend, and which sources they cite. The audience is a product or marketing team that already has a domain and wants evidence rather than a dashboard score. Each domain becomes its own project, with its own configuration, runs and evidence, so several products do not end up mixed in one report. The repository also ships examples/README.md, which the README describes as 20 real cases you can read without installing anything or holding an API key. That is the cheapest way to judge whether the output format is useful before you spend on model calls.

How a run works: OpenRouter models, per-model web search, and stored evidence

The mechanism is a small local server that calls models through OpenRouter and writes the results to disk. You create a project for a domain, then search for and select one or more OpenRouter models. Web search is set separately for each model: a model can run offline or use its supported native search mode. The README says models answer independently, and that if one fails the other results remain available, which matters when you are comparing four or five models and one provider is having a bad day. A failed model can be retried on its own. What comes back is stored in layers: business descriptions, categories, competing products, associated keywords, the original answer text, Provider citations and ordinary answer URLs are kept as separate items. The README is explicit that failures and uncertainty remain on record. Keyword tests are a second pass: you confirm the keywords you want to measure and run them without including your own brand name, so you can see who gets mentioned when nobody prompts for you. Repeated runs and scheduled monitoring build a history of comparable records. The worker that drives scheduled runs is a separate process, which is why docker-compose.yml defines a second service under the monitoring profile.

Installing NiubiGEO and running a first audit

The README requires Node.js 22+ and your own OpenRouter API key. The commands below clone the v0.2.0 tag shallowly, install dependencies from the lockfile, and copy the environment template.

git clone --branch v0.2.0 --depth 1 https://github.com/Albert-Weasker/niubigeo.git
cd niubigeo
npm ci
cp .env.example .env

Open .env and set OPENROUTER_API_KEY. The .env.example file also lists direct provider keys (OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, PERPLEXITY_API_KEY, DEEPSEEK_API_KEY) and notes that each is routed only to its own provider. Two optional server settings are there as well: PORT, defaulting to 8787, and RUNS_DIR.

npm run server

The server starts and the README says to open http://localhost:8787 to create your first project. In the browser you enter a domain, pick one or more models, set web search per model, save the configuration and start a test. The README advises starting with one model and adding more once you know what to look for. Reading the bundled cases costs nothing; testing your own project incurs model and search API charges on your OpenRouter account.

If you prefer a container, docker-compose.yml builds the image and publishes the port on loopback only:

ports:
  - "127.0.0.1:${PORT:-8787}:8787"

The same file mounts ./data into /app/data and sets PRODUCT_DATA_DIR to /app/data/product-v2. The README points to docs/deployment/docker.md for the container path and docs/upgrade.md for backups and upgrades.

The advisor card and the switch that hides it

The workbench shows a small advisor card by default. Clicking it opens an entry point that redirects to a video advisor hosted on a separate domain. This is the part of the project most likely to surprise a self-hoster, so the README addresses it directly: the local workbench loads no third-party script, iframe or video for the card, and the link carries no project data or model API keys. The README also states the card adds no payment requirement and does not change the Apache-2.0 license. If you would rather not see it, set NIUBIGEO_VIDEO_ADVISOR_ENABLED=false in .env and restart the server, or recreate the web container with docker compose up -d. The values 0 and off also hide it, and local diagnostics continue to work with the card disabled. Note that the paid services mentioned in the README, human AI testing and GEO optimization, are sold on the project's website and are separate from the code you run.

What NiubiGEO will not do for you

The first constraint is that the tool does not produce answers on its own. Without a working OpenRouter key, or a direct key for a specific provider, there is nothing to measure. Your cost scales with the number of models, the number of keywords and how often you schedule runs, and the README says plainly that testing your own project incurs model and search API charges. Second, results are per model and per configuration. A model with web search on and the same model offline are different conditions, and the README says results retain the actual execution conditions, which means you cannot treat a change in an answer as a change in the model unless the conditions match. Third, this is a local workbench, not a hosted service. There is no account system described, no multi-user sharing, and the data lives in the directory you mount. The README does not document rollback for a failed upgrade; it only points at docs/upgrade.md. Fourth, if your goal is to move the answer rather than read it, the repository is the wrong tool. The README sells GEO optimization as a paid service, not as a feature of the code. Finally, the version is young: v0.1.0-alpha arrived on 2026-09-03 and v0.2.0 on 2026-09-08, so expect the data layout under PRODUCT_DATA_DIR and the CLI surface to move.

NiubiGEO compared with commercial AI visibility platforms

The obvious alternative is a hosted AI visibility product, where you sign up, enter a domain and read a dashboard someone else operates. The difference is not only where the data sits. A hosted product decides which models to query, how often, and how to score the output; you get a number and a trend line. NiubiGEO does not score. It shows you the original answer, the text locations, the Provider citations and the ordinary answer URLs, and the README states that failures and uncertainty remain on record. That is more work to read and more honest to audit. The trade is operational: you supply the OpenRouter key, you run the server, you keep the data directory, and you own the upgrade path. If your team has nobody who will run npm run server or maintain a container, a hosted dashboard is the better fit. If your team needs to show a skeptical stakeholder the exact sentence a model produced, the stored evidence is the point.

License, maintenance and upgrade cost

NiubiGEO is licensed under Apache-2.0, and the LICENSE file sits at the repository root. The Dockerfile carries the same identifier in its image labels. Apache-2.0 permits commercial use and modification; it also includes a patent grant and requires that you keep the license and notice files when you redistribute. That is a description of the license text, not legal advice, and if you plan to redistribute a modified build you should read the LICENSE and SECURITY.md yourself. On maintenance: the repository is not archived, and the last push was on 2026-09-14, two days before this writing, with v0.2.0 released on 2026-09-08. The upgrade cost is real but bounded. The README directs existing users to docs/upgrade.md for backups and upgrades, and docker-compose.yml mounts ./data into /app/data, so the state you must preserve is that directory. The scheduled path adds a second process: the monitoring profile in docker-compose.yml runs the schedule worker with an argument of 60, and package.json exposes the same work through npm run schedule:worker and the monitor:* scripts. If you run scheduled monitoring, you are maintaining two things, not one.

Editorial conclusion

Adopt NiubiGEO if you want to see raw model answers and citations for your own domain, keep the records on your own disk, and are willing to pay OpenRouter for the calls. Do not adopt it if you need a hosted dashboard with no API key, or if you expect the repository to supply answers without a provider. Before you commit, check that Node.js 22 or Docker is available, that an OpenRouter key is in .env, and that the data directory you mount is one you are prepared to back up, since docs/upgrade.md is the only documented path for restoring it.

Frequently asked questions

Official sources

1. Albert-Weasker/niubigeo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases