Privacy Policy

Last updated: 19 September 2026

Contextator is self-hosted software. It has no analytics and no telemetry: it never reports anything back to its authors, and the people who wrote it have no access to any data in your installation. It does manage user accounts — but those exist only inside your own installation, and nothing about them leaves it.

1. Two different things

This policy covers the Contextator software — the server and dashboard you are looking at — and the product website at contextator.com. It does not cover the installation you are using if somebody else runs it: in that case the operator of this instance decides what is stored, for how long and who may see it. Ask them, not us.

2. What the software stores

Everything below is written to the database and disks of the machine running this instance, and nowhere else:

• Projects and sources — names, paths, repository URLs, branches, Notion root ids, file-type and content-type settings.
• Indexed documents and their embeddings — the text of every file that was indexed, split into chunks, plus the vector of each chunk.
• Materialised sources — uploaded files and archives, git checkouts and Notion pulls, kept in the data directory so that runs can be incremental.
• Index run history — start and finish times, file and chunk counts, and the error message of a failed run.
• Search queries — for each search of a project, whether it came from a connected agent or from the dashboard: the text of the question as it was typed, the time, how many excerpts were asked for and returned, the file path, heading and score of each excerpt that came back, how long it took, which embedding model answered, and the MCP token the agent presented if it presented one. The question is stored in the clear and not as a hash, because the whole purpose is to be able to read back what people are asking, and a hash cannot be read. It is what lets an operator see that forty agents asked about something their documentation does not cover. This is user content — see Search queries in section 4 for who can read it, how long it is kept and how to turn it off.
• Gap reports from agents — when an agent calls report_gap, the question it could not find an answer to and an optional note of up to 1,000 characters, in the clear, with the time and the MCP token it presented if it presented one. It is user content under the same terms as the search queries above: see section 4.
• Access tokens for private git repositories and Notion integrations — encrypted at rest with AES-256-GCM using the deployment's SECRET_KEY, never returned by the API and never displayed again after they are saved. Credentials pasted into a repository URL are stripped before the URL is stored.
• Webhook secrets, one per git source, used to verify that a push notification really came from the provider.
• User accounts — a username, an optional display name and e-mail address, the role (root, admin or member), whether the account is active, when it was created and when it last signed in.
• Password hashes — passwords themselves are never stored. Only a salted scrypt hash is kept, and it cannot be turned back into the password. Passwords never appear in the logs, and the API never returns one.
• Sessions — one row per signed-in browser: a hash of the session token (not the token), the browser's user-agent string, the IP address the session was opened from, when it started and when it was last used.
• Project memberships — which account may read, and which may change, which project.
• MCP tokens — for each project, a hash of every token that was issued for its MCP endpoint (never the token), the label it was given, who created it, and when it was created, last used and revoked. The token itself is shown once, when it is created, and is not recoverable afterwards.

Deleting a project or a source deletes its documents, chunks, embeddings and materialised files. Deleting a user account deletes its sessions and memberships immediately; documents that person uploaded belong to the project and stay with it. Signing out, changing a password and "sign out everywhere" each delete the sessions they end. The database and the data directory are ordinary volumes: backups, retention and access control are the operator's responsibility.

3. What your browser stores

After you sign in, the dashboard sets one cookie, contextator_session. It holds an opaque session id, is HttpOnly and SameSite=Lax, and is deleted when you sign out. Nothing else is kept in the browser: the localStorage key that older versions used for the admin token is gone, and the dashboard clears any leftover automatically. Details are on the Cookie Policy page.

4. Logs and the search query log

The server writes operational logs to standard output: startup information, index run progress and errors. Per-request HTTP logging is off unless the log level is set to debug or trace. Where those logs go and how long they are kept is decided by whoever runs the container.

Failed sign-in attempts are logged with the username that was tried and the address it came from, so an operator can see an attack in progress; account creation, password resets and deletions are logged with the administrator who did them. Passwords, password hashes and session tokens never reach the log. A search that the server declines to answer, because nothing scored well enough, is written to this log with the question that was asked.

Search queries

Every search of a project is also recorded in the database, with the question as it was typed and the excerpts that came back. It is not an operational log line that rotates away: it is a table, it is queryable, and it is meant to be read — that is the point of it. Without it this software cannot tell an operator that their documentation fails to answer something, because a single search cannot: a question about a feature that does not exist scores about as well as one the documentation answers, and only the same question arriving forty times in a week says anything.

• Who can read it. Anyone who can read the project: root, admin, and any member added to it, as a viewer or an editor. Since 2026-09-19 they read it on the project's own page in the dashboard, and can download the questions as a file; before that it took database access, which changed who found it convenient rather than who was allowed. Agents cannot read it — there is no MCP tool that returns it, and one agent can never see another's questions.
• How long it is kept. SEARCH_QUERY_LOG_RETENTION_DAYS, 30 days by default. Older rows are deleted automatically, a few times an hour. Deleting a project deletes its queries with it.
• How to turn it off. Per project, with a setting that stays with the project; or for the whole instance with SEARCH_QUERY_LOG=0, which records nothing whatever any project says. Both are the operator's decision, and turning it off does not delete what is already there.
• Reports an agent writes belong to the same policy. The report_gap tool lets an agent tell the project's maintainers that the documentation did not answer something. Those reports are kept in a table of their own, are readable by the same people, are deleted after the same SEARCH_QUERY_LOG_RETENTION_DAYS (also while the log is switched off) and stop being written when the log is switched off, for the instance or for the project. At most 2,000 are kept per project, and each credential may add a limited number per hour (MCP_REPORT_GAP_PER_HOUR). An agent never gets a report back, its own or anyone's.
• It is in the backups. A database dump carries this table like any other, so a backup of this instance contains the questions that were asked of it. Keep backups accordingly.
• What it does not record. No IP address, no browser, no account name, and nothing that identifies an agent beyond which of the project's MCP tokens it presented. A dashboard search is marked as one and carries nothing about who ran it.

Whoever types a question into an agent decides what that question contains. If the people using this instance would put something confidential into a search box, that is a reason to shorten the retention or to switch the log off — and a reason to say so to them, which is the operator's job and not this page's.

5. When data leaves the machine

A default installation makes exactly one kind of outbound call, and only once. The rest happen only if you configure them:

• Embedding model download. On first start the local embedding model (~470 MB) is downloaded from the Hugging Face CDN. Set EMBEDDING_OFFLINE=1 with a pre-populated model cache to avoid it entirely.
• OpenAI embeddings — optional. If the deployment sets the embedding provider to OpenAI, the text of every chunk that is indexed and every search query is sent to the OpenAI API under your own API key and their terms. The local provider sends nothing.
• Your own sources. Git hosts you add are contacted to clone and fetch; Notion is contacted to read the pages shared with your integration. Both use the credentials you provided.
• Scheduled checks of those sources — only where one is configured. A source can carry a sync interval, and the server then asks it on that schedule whether anything changed: one git ls-remote for the branch, or one Notion search for the newest edit. Nothing of yours is sent — the question is has this moved, and the answer decides whether a real sync follows. It is off for every source that existed before this feature was added, it is per source, and SYNC_DEFAULT_INTERVAL_MINUTES=0 switches it off for new ones too.
• Web fonts. The dashboard and these pages load typefaces from Google Fonts, so your browser contacts fonts.googleapis.com and fonts.gstatic.com, which receive your IP address and user agent. Self-host the fonts if you would rather it did not.

There is no usage tracking, no crash reporting and no update check.

6. Who can see what

An account is one of three roles. root and admin reach every project and manage accounts; a member reaches only the projects it has been added to, as a viewer that reads or an editor that can add sources, upload files and re-index. Every one of those rules is enforced on the server, not in the browser.

Accounts do not reach the MCP endpoints; those have their own door. A project's /mcp/<project> endpoint is open unless the operator closes it, and while it is open anyone who can reach that URL can read that project's indexed documents — whatever their role here, or without an account at all. An operator can require a bearer token on any project, after which only a client holding one of that project's tokens is answered. A token carries no identity: whoever holds it reads everything indexed in that project. Either way, keeping the server on a private network or behind an authenticating proxy remains the operator's decision.

7. MCP clients

An AI agent connected to /mcp/<project> receives the excerpts and documents it searches for, and whatever the agent does with them is governed by that client's own privacy policy. Whether the agent needs a token to connect at all is the operator's choice, per project; see Who can see what above.

What the server records about a connected agent is what it asked. Every search_docs call is written to the search query log described in section 4 — the question in the clear, the excerpts returned, and which of the project's MCP tokens the agent presented, if any. It records nothing else about the agent: no address, no client name, no identity, because a token carries none. An open project verifies no token, so its queries are recorded with no attribution at all.

The token itself is still stored only as a hash, with the time it was last used, and is still not recoverable. What changed is that the questions asked through it are now kept beside it, for as long as SEARCH_QUERY_LOG_RETENTION_DAYS says, and can be switched off per project or instance-wide with SEARCH_QUERY_LOG=0.

The one other thing an agent can write is a report_gap report, the question it could not find an answer to and an optional note. It is stored and kept like the questions above and goes off with the same switch; see section 4.

8. Personal data

Contextator is a documentation indexer; it does not profile anyone. The names and e-mail addresses of the people you give accounts to are personal data, and so is anything personal inside the documents you index. In both cases you are the controller and this software is a processor running on your own hardware — the usual duties (lawful basis, retention, deletion, access requests) stay with you.

9. The product website

contextator.com is a separate, static product site. It is served with no advertising and no cross-site tracking; any server-side request logs it keeps are used only to operate the site and to keep it available.

10. Changes and contact

This policy may change as the software changes; the date at the top always says when it was last revised, and a revision applies from the moment it is published. Questions about the software or this policy go to contextator.com. Questions about the data in this installation go to whoever operates it.