Getcito: a self-hosted AI visibility tracker for AEO and GEO

What Getcito tracks and who the data is for

Answer engines increasingly describe brands without sending a click. Getcito exists to measure that. The README describes it as a self-hosted platform for tracking and optimizing AI visibility, and lists the acronyms it covers: AEO (Answer Engine Optimization), GEO (Generative Engine Optimization) and LLMO (LLM Optimization). The job it does is narrower than a general analytics tool. It schedules prompts, records how AI engines answer them over time, and extracts which brands, domains and sources each response cites. That citation extraction is the core output. A visibility number without the cited sources is not actionable, so the product pairs prompt tracking with mention and citation analysis and lets you place competitors on the same prompt set.

The audience is whoever already cares about organic search but cannot see inside the answer box: SEO and content teams, agencies running visibility reports for clients, and growth engineers who want the raw data rather than a dashboard screenshot. The README positions it as a free alternative to hosted tools like Profound, Peec and Otterly. That framing matters, because the reason to self-host here is not cost alone. It is that the README states you can audit exactly how every metric is calculated. For a metric that will be quoted in a board deck, that auditability is the actual feature.

Architecture: a web app, a worker and a Postgres queue

Getcito is a pnpm and Turborepo monorepo with two applications backed by shared packages. The web app serves the dashboard and a REST API under `/api/v1`. The worker runs scheduled scraping, analysis and report jobs. Both talk to the same PostgreSQL database, and the queue between them is `pg-boss`, which stores jobs in Postgres rather than in a separate broker. That is a deliberate simplification: one datastore to back up, one connection string, no Redis to operate. It also means queue throughput is bounded by the database you already have.

The README's architecture diagram shows the flow. A user hits the web app over HTTP. The web app reads and writes the Drizzle schema and enqueues jobs into Postgres. The worker polls queues, calls scraper providers (BrightData, Oxylabs, Olostep, Cloro, DataForSEO) or LLM providers directly (OpenRouter, Anthropic, OpenAI, Mistral, Azure AI Foundry), and writes results back. A `schedule-maintenance` job runs on a `*/5` cron and feeds a `process-prompt` job, which is where a single prompt actually gets answered and analysed. The provider layer is pluggable, so the same prompt can be collected through a scraping vendor or through a direct API call depending on configuration. That choice is the main lever on both cost and result quality, and the README does not rank the providers for you.

Installing Getcito with Docker Compose

The README gives two installation paths. Option A is Docker Compose and is marked recommended; Option B is local development. The Compose file is written to build from source, so the first step is copying the environment template and filling in real values. You need Node 24.x and pnpm 11.10.0 if you are working outside the containers, since both are declared in package.json.

From the repository root, the documented sequence is:

cp .env.example .env   # then fill in real values
docker compose build
docker compose up -d

The Compose stack starts PostgreSQL on host port 5433, Adminer on 8081 for browsing the database, a one-shot `db-migrate` container that applies the Drizzle schema, and the web app on port 3001. The web container bakes `VITE_*` values into the client bundle at build time, so changing `VITE_APP_TIMEZONE` or `VITE_APP_LOCALE` later requires a rebuild, not a restart. That is a common source of confusion with Vite-based deployments and the Compose comments say so explicitly.

The minimum viable configuration is small. You need a database URL, a Better Auth secret, and at least one provider key:

POSTGRES_IMAGE_TAG=18-alpine
DATABASE_URL=postgres://postgres:postgres@postgres:5432/getcito
BETTER_AUTH_SECRET=replace-with-random-hex
APP_URL=http://localhost:3001
SCRAPE_TARGETS=chatgpt:openai-api
OPENAI_API_KEY=replace-me

The `SCRAPE_TARGETS` value follows a `model:provider[:version][:online]` format, and the example routes ChatGPT prompts through the OpenAI API rather than a scraping vendor. Once the stack is up, the documented entry point is the dashboard on port 3001, where you add a brand and prompts. The README also points to a live demo at demo.getcito.com for seeing prompt tracking and citation analysis before you commit to a deployment.

The Postgres 16 to 18 upgrade trap

The single most concrete warning in the repository is in docker-compose.yml and repeated in .env.example. New deployments default to `postgres:18-alpine`. Existing PostgreSQL 16 data directories are not compatible. If you already run Getcito on 16, you must set `POSTGRES_IMAGE_TAG=16-alpine` before upgrading, and only remove that pin after a dump and restore into PostgreSQL 18. This is stated as a requirement, not a suggestion.

It is worth taking seriously because the failure mode is not a clean error. A volume created by one major Postgres version and mounted by another is a data directory mismatch, and the practical recovery path is restoring from a dump you should have taken beforehand. Anyone running Getcito in production needs that dump step in their upgrade runbook before they pull a new image. The project does not document an automated migration path between the two versions, so the burden sits with the operator. Teams that treat `docker compose pull` as a safe routine should not do so here without reading the pin comment first.

Where the documentation is thin

Several areas are named in the README but not explained. The REST API is described as Bearer-authenticated under `/api/v1` with endpoints for brands, competitors, prompts and reports, but the README's API Documentation section is a heading without visible detail, so you cannot judge the response shapes or rate limits from the README alone. The Database section is likewise a heading. Report generation is listed as a feature (background generation over collected data) without a description of what a report contains or how long generation takes.

The provider matrix is the bigger gap. The README lists five scraping vendors and five LLM providers, and describes the target syntax, but it does not say which combination produces comparable results, how each provider's answers differ, or what happens when a provider returns an error mid-run. `pg-boss` gives durable scheduling and retries, which covers the mechanics, but the README does not document rollback behaviour for a partially collected prompt set. If you plan to compare visibility month over month, the consistency of your provider configuration is something you have to reason about yourself. That is the cost of a young self-hosted tool, and it is a real one.

Getcito against hosted AI visibility platforms

The README names Profound, Peec and Otterly as the hosted alternatives Getcito is a free replacement for. The difference is not only price. A hosted platform owns the collection pipeline, the provider relationships and the metric definitions, and you consume the result through their interface. Getcito inverts that: you supply the API keys, you run the worker, you own the database, and the metric calculations are in code you can read. For an agency that needs to explain to a client why a visibility score moved, that is a meaningful difference. For a solo marketer who wants a number and no infrastructure, it is a worse deal, because you now operate PostgreSQL, a queue and a set of provider accounts.

The other honest comparison is against doing nothing but manual spot checks. Pasting a prompt into ChatGPT once a week is free and takes a minute. Getcito is worth the setup only when you need history, competitor comparison on identical prompts, and citation extraction at a volume a human will not do by hand. The README's feature list maps directly onto those three needs, and if you do not have them, the manual check is the better tool.

Licence, maintenance and upgrade cost

The repository metadata reports the licence as NOASSERTION, which means the automated classifier could not identify a standard licence file. The README badge and package.json both say MIT, and the repository contains a LICENSE.md and a CLA.md. That inconsistency is worth resolving by reading LICENSE.md before you build a commercial product on top of Getcito. This is a description of what the files say, not legal advice; if the licence matters to your business, have someone qualified read it.

On maintenance, the last push to the default branch was on 2026-09-14, and the most recent release listed is v9.1.0 on 2026-08-22, following v9.0 on 2026-08-02. The repository is not archived. The project uses Changesets for versioning, with `pnpm changeset` and `pnpm version-packages` scripts, and Biome for lint and format. Upgrade cost is dominated by the database, not the application code: the Postgres 16 to 18 pin exists precisely because a routine image bump can strand your data. Budget for a dump and restore, not just a rebuild.

Editorial conclusion

Adopt Getcito if you want AI visibility data on your own infrastructure and are willing to read the code to understand how each metric is computed; the README states the project is a free alternative to hosted tools like Profound, Peec and Otterly. Skip it if you need a hosted service with vendor support, or if you cannot run PostgreSQL and a background worker. Before committing, verify the licence text in LICENSE.md, since the repository metadata reports NOASSERTION while the README badge and package.json both say MIT, and confirm that your chosen scraper provider credentials work with the SCRAPE_TARGETS format described in .env.example.

Frequently asked questions

Official sources

1. ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tool on GitHub
2. Issues
3. Project website
4. README
5. Releases