Scope
This notice applies to the public Firekeep website operated by Omnicron, LLC. It does not govern a Firekeep server that you or your organization self-hosts; the operator of that deployment controls its data and configured integrations. It also covers the two telemetry channels the installed Firekeep client can send to this site — the opt-in doctor report and the consented failure reports — which are documented in full below.
Information the website handles
- Hosting requests. Hostinger may process ordinary request data such as IP address, browser details, requested paths and timestamps to deliver and secure the site.
- Email you choose to send. If you contact support, sales or security, we receive your address and the contents of your message.
- Site assets. Fonts, scripts and styles are served from firekeep.ai; loading the site does not send a font request to Google.
- Software download counts. Fetching a branded Firekeep installer—including
firekeep.ai/latest/installand the Studio download buttons—logs a timestamp, which download, a coarse client type (curl, PowerShell, browser, or other) derived from the User-Agent, and eitherdirector a short campaign label from the publicsrcquery parameter. Firekeep accepts only a fixed list of labels such asshowhn,selfhst,github, orclaude-plugin; it discards arbitrary values. It never stores the raw User-Agent string, raw referring URL, or an IP address. - Anonymous install-health reports, only if you ask. Running
firekeep doctorchecks your installation locally; nothing is sent unless you have separately enabled failure reporting (below) — a failed connectivity check then sends its category codes — or you type the --report flag. Runningfirekeep doctor --reportadditionally sends a redacted summary — the name and pass/warn/fail status of each check, plus your client version — to firekeep.ai. The messages doctor prints locally, file paths, hostnames, and any other detail are never included, and we do not assign or store any device, account, or session identifier. The doctor report itself never happens unless you type the flag. (Which checks are present on your machine — for example, whether a particular dex is connected — is itself information, so a report is not necessarily indistinguishable from every other machine's; it is simply never linked to one by anything we store.) - Anonymous failure reports, only if you said yes. If you enabled failure reporting (a one-time install or doctor question, or
--report-failures; off if never answered), the Firekeep client sends a report when an install step, a connection to your own Keep, or a background task fails. A report contains only fixed category codes: what failed (e.g.create-venv), the error class (e.g.permission-denied), OS family, CPU architecture, client and Python versions, and — for specific event kinds — which runtime adapter, dex, or backend service was involved, or the install step's exit code: all fixed category values, never free text. Plus a random per-event delivery code that exists only so a resent report is not double-counted. Never paths, messages, addresses, tracebacks, or any persistent device, account or session identifier. The collector records a server-side timestamp per report. Turn it off any time with[report] failures = falsein~/.firekeep/config(theFIREKEEP_NO_FAILURE_REPORTenvironment variable also disables it for a session). As with the collectors above, this is a statement about what our application code stores — no IP address, cookie, or identifier that ties separate reports together — not about the hosting layer, which processes ordinary request data as described above. The category combination is low-cardinality, not necessarily indistinguishable from every other machine's; it is simply never linked to one by anything we store.
The site contains no advertising tags, behavioral analytics or first-party tracking cookies. None of the download counter, the install-health report, or the failure-report collector writes an IP address, cookie, or identifier that ties separate requests together — that is a statement about what our application code logs, not about the hosting layer described above, which does record ordinary request data like any web server.
How information is used
Request data is used to operate, protect and troubleshoot the website. Email is used to answer your request or handle a security report. We do not sell personal information or use it for behavioral advertising.
Service providers and retention
Hostinger provides website and email infrastructure and processes requests under its own terms. We retain email and operational records only as long as reasonably needed for the request, security, recordkeeping or legal obligations.
Your choices
You can block remote fonts in your browser without losing site content. You may ask about, correct or delete information you sent by emailing support@firekeep.ai. Legal exceptions may require some records to be retained.
Changes and contact
Material changes will be reflected on this page with a revised effective date. Questions about this notice can be sent to support@firekeep.ai.