What leaves your machine

Elicana's own servers never receive your documents, your queries, or your compiled notes. The model provider you choose does, at your direction, under your own key, unless you run models locally, in which case nothing leaves at all. Here is every request, either way.

Elicana is bring-your-own-key: it does not resell model access and it does not proxy your text through us. When you configure Anthropic or OpenAI, your document text is POSTed directly from your machine to that provider, on your API key, under your contract with them. It does not pass through api.elicana.ai and we never hold a copy. When you configure Ollama or the bundled local embedding model instead, that text never leaves your machine at all. The license check, telemetry, and the update check are the only requests that go to Elicana's own servers, and they carry no document, query, or corpus content, ever. The one exception is a support bundle, which is user-initiated, redacted by default, and documented in full below. Every request to Elicana's own servers goes over TLS, and there is no setting that downgrades it.

Elicana is not an offline or air-gapped product. Even with local models it reaches the network for the license check, on startup if the last successful check was over 24 hours old, and then roughly daily thereafter (at minimum monthly). If you need an air-gapped or compliance-audited deployment, that's a different conversation. Contact us rather than assume this tier covers it.

Specific to beta: telemetry (below) is always on while the beta is running. That's a deliberate, temporary trade: it's how a small team finds out what's breaking before customers have to tell us, and it ends when beta pricing does. It does not change what telemetry sends: counts only, documented in full below.

Every outbound request, in one table

This is the complete inventory of network calls the shipped binary can make. "Can carry your content" means document text, note text, query text, or titles, the things that actually matter. Everything marked yes goes to a destination you configured, not to us.

The model provider you choose

Compiling a document means asking a language model to read it. There is no way to do that without the model seeing the text. Elicana's design decision is about who that model belongs to: it is always yours, never ours. In the first-run wizard, Anthropic is labelled "Recommended, best compilation quality"; if you pick it, every document you compile and every question you ask is POSTed from your machine to api.anthropic.com under the API key you pasted. Same for OpenAI, same for Ollama Cloud, same for any custom base URL you set. You have a direct relationship with that provider: you pay them, and their terms govern what you send them, including whatever their retention and training policy is on your account tier. We are not in the middle of that request, and there is no copy of it on our servers.

If you choose the "Ollama, runs on your computer" option, that same text goes to localhost:11434 and nothing leaves your machine. Embeddings are local by default in both cases: the wizard only ever configures the bundled ONNX model or your local Ollama.

What does not change either way: Elicana's own servers receive none of it. The license check, telemetry, the update check, and the cohort call carry counts and identifiers, never content. That is the boundary this page exists to document, and the rest of it is the field-by-field proof.

The license check payload

Three requests carry the entire entitlement surface: activating a machine, the recurring check, and deactivating a machine. Nothing else about your account, your usage, or your machine rides along.

Activate a machine

POST /api/v1/license/activate, sent once per machine, when you first install or reinstall.

Recurring license check (the phone-home)

POST /api/v1/license/check, the complete payload, nothing else. Runs on startup if the last successful check was over 24 hours old, and then on a 24-hour timer while the app is running, so in practice, roughly daily, and at minimum monthly.

The response tells the app whether the subscription is active, in a 7-day grace period, or lapsed, plus the paid-through date and how many machines are active. If a check fails (no connectivity), the app keeps working for 14 days offline, and starts warning you from day 7, 14 days is the hard cutoff, not the warning threshold. That tolerance exists because the people this is built for travel and work from low-connectivity places.

Deactivate a machine

POST /api/v1/license/deactivate, sent from the Account page, or from the app, when you free up a machine slot.

Telemetry fields See status below

Beyond the license check, the beta build reports how much gets compiled, what a compile or query costs in tokens, and how often you query. None of it contains your document text, note text, query text, filenames, file paths, or note titles. Be aware of two things. Most of these numbers are exact rather than rounded, and one row is sent each time a document is compiled and each time you ask a question, with the time it happened. So the record shows when you were working, not just how much. And every row carries the same identifier for your installation, so the rows can be read together as one history. The list below is checked automatically against the bytes actually sent, so it cannot drift from what the app does.

Two of these can contain words you chose. The count of documents per source is labelled with the name you gave that source, and the model name and provider are sent exactly as written in your configuration. Neither carries any document content, but if you name a source after a client, or run a model with an internal name, that name is what gets sent.

Support bundles

The license check and telemetry above happen automatically. Support bundles are different in every way that matters: user-initiated only, never automatic, and never sent without you seeing what's in them first and confirming.

Run elicana support-bundle (or use "Report a Problem" in the dashboard) and Elicana builds a zip containing the last 7 days of logs, crash reports, environment/doctor checks, note-population counts, and your config file with secret values blanked out. It never contains your document bodies. It is uploaded with the email address and message you type in, plus your app version, platform, and your installation UUID, the same UUID that identifies your telemetry. That means sending a support bundle does link your otherwise-pseudonymous telemetry to your email address.

Your logs can contain your query text and file paths, that's genuinely useful for diagnosing a bug, so it's what makes a support bundle different from telemetry. To keep that from being a privacy hole, redaction is on by default: query text and file paths are stripped from the structured fields of the app's own log lines, with paths replaced by a short hash plus the file extension (e.g. a3f912e4.pdf), so a recurring problem file is still recognizable to support without exposing directory names, usernames, client names, or the filename itself. You opt out of redaction with --include-queries, if support specifically asks for the unredacted version, the CLI prints a plain warning when you do.

The precise limits of that redaction, since a vague version would be worth nothing:

• Document titles are not redacted. Compiling a note logs its title, and a redacted bundle still ships those log lines. So a fully redacted bundle contains a list of your document titles, even though it contains none of their contents.
• Crash files are included in full, whatever their age, and are never redacted. The redaction pass covers the app's structured log files only.
• Redaction operates on known structured fields. A path or a query that appears inside a free-text error message is not caught.
• The config file in the bundle blanks API keys, tokens, and secrets, but deliberately preserves your source paths (sources.local_paths, sources.obsidian_paths) and your brief webhook URL, because a support case about ingestion is usually unanswerable without them. Those paths typically contain your username and your folder names.
• The path hash is an unsalted SHA-256 truncated to four bytes. It is not a secret against someone who can guess the path; it exists so support can tell "the same file failed twice" apart from "two different files failed".

Nothing here is a reason not to send a bundle when you need help. It is a reason to know what you are sending, and to use --no-upload and open the zip first if you work with sensitive client material.

On sending: the CLI writes the zip to disk, prints exactly what's in it and whether redaction is on, and asks Upload this bundle to Elicana support now? [y/N]: before sending anything. You can say no, open the zip yourself, and decide from there, or run with --no-upload up front to skip the network call entirely and just get the file, then email it to support@elicana.ai if you still want to send it. In a non-interactive session (a script, a CI job) it will not upload at all unless you pass --yes, which is the documented way to skip the prompt deliberately.

One honest caveat about the dashboard path. When you use "Report a Problem" in the admin UI, the review-and-confirm step is enforced by the dashboard page itself; the underlying POST /api/v1/support-bundle route builds and uploads in one call, with no second server-side confirmation. Anyone who can already reach your local API with your API token, which is to say, anyone who already has access to your machine and your config, could therefore trigger an upload without the dashboard's confirmation screen. Nothing uploads without some deliberate action, but "the confirmation is enforced in the server" would be a stronger statement than we can currently make, so we are not making it.

Machine identity, precisely

machine_id is a SHA-256 hash of a stable machine UUID (/etc/machine-id on Linux, the IOPlatformUUID on macOS, the MachineGuid on Windows), computed on your device before it's ever sent. If that platform identifier can't be read, some containers and hardened systems don't expose one, Elicana generates a random UUID instead, stores it in its own data directory, and hashes that. Either way the value is device-local and one-way before it leaves. hostname_hash is a SHA-256 hash of your hostname, also computed on your device. Elicana's server receives only the hashes.

Last updated 25 August 2026, describing Elicana v0.4.1. This revision re-checked the page against v0.4.1 and found nothing on it had changed: the source connectors gained new Google Drive API calls, but they go to the same destination, in the same direction, on the same trigger, using the same token you supplied. The previous revision removed internal field names in favour of plain descriptions and corrected when the reranker model is downloaded. No change to what is sent. If you find anything on this page missing or inaccurate, please tell us and we will fix it.