Privacy Policy

Last updated: October 1, 2026

1. Who operates dollama

dollama.net, the hosted relay at api.dollama.net and this website are operated by Lia Pool, an individual. There is no company behind the project. Lia is the person responsible for the account data and usage records described here.

Privacy questions and deletion requests: privacy@dollama.net. Security reports: security@dollama.net (see §10).

This policy covers the dollama CLI and dashboard, the hosted relay, personal hosting at *.host.dollama.net, chat.dollama.net and this website. It does not cover machines run by other contributors, which dollama does not control (see §7).

2. Modes: where your requests can run

You choose a mode in the CLI, the tray icon or the dashboard. The mode decides which machines may run your requests and whether your machine runs other people's. It does not change the path your content takes: in every mode it goes through the relay.

Mode	Command	Your requests can run on	Your machine serves	If no eligible machine is available
Private	dollama private	Machines signed in to your own account	Only your own requests	The request waits up to about two minutes, then fails. It never falls back to anyone else's machine.
Group	dollama group	Your own machines, plus machines belonging to members of groups you have joined	Your requests and your groups' requests (not yet: today only yours, see §12)	Same as Private: waits, then fails. Never falls back to the open network.
Open Network	dollama network	Your own machines first, then group machines, then any volunteer's machine	Anyone's requests, when your machine is idle	The request waits in the queue, then fails.

There is no offline mode. Every mode needs the relay to match the request and carry it, including when the machine that runs it is your own. You can run a model on the same machine without the network by asking for local:<model>, which goes straight to your local Ollama.

Before you choose a mode, the app is idle: it sends no requests and serves nobody. The places where the software does not yet follow the mode you chose are listed under §12.

3. The path your content takes, and who can read it

A request goes from your machine to the relay over TLS, and from the relay to the serving machine over a TLS WebSocket. The response streams back the same way. Each hop is encrypted in transit, but TLS ends at the relay's hosting provider (Fly.io), so the relay can read your content. Requests are not yet encrypted client to client (between your machine and the serving machine).

Party	Can it read your prompt and response?
Your machine	Yes. It assembles the request and keeps the conversation.
The relay (and, technically, its hosting providers)	Yes, in every mode. The relay handles the content in order to route it, holds the request for a few minutes (see §5), and does not write it to logs or to its database. It is able to read it; the operator's commitment is not to.
The machine that runs the request	Yes. It needs the plaintext to run the model. In Private mode that is your machine; in Group mode it may be a group member's; in Open Network mode it may be a stranger's.
Other contributors	No. Only the machine the request is assigned to receives it.

If you turn on direct links between your own machines (dollama peer enable), some content can travel straight between them over an authenticated, encrypted connection instead of through the relay. If a direct link fails, dollama falls back to the relay without telling you, so do not treat a direct link as a guarantee.

4. What a request contains

dollama does not upload your files or your repository. But a coding tool reads files and runs commands on your machine, and puts what it finds into the conversation. Whatever is in the conversation is sent with the request. In practice a request can contain:

• Your messages and the earlier turns of the conversation, including the model's earlier replies.
• The system prompt and project instructions your tool adds (for example a CLAUDE.md file or a git status summary).
• Tool calls and their results: the contents of files your tool read, file paths, shell commands and their output, search results.
• Images, documents and audio you attach.
• Metadata: a pseudonymous account ID, a session ID, the model name, token counts and timing.

dollama does not scan for or remove secrets. If a file your tool reads contains a password or an API key, it is sent like any other text. The serving machine receives the whole conversation so far with each request, not only your latest message.

5. What is kept, where, and for how long

Data	Where	Why	Kept for	Your control
The request as sent: conversation text, system prompt, tool definitions and tool-call arguments	Relay cache (Redis)	To serve and retry the request	At most 10 minutes while the request is being processed, 5 minutes after it completes, 30 seconds after delivery is confirmed	Choose what you send
Tool results and large attachments	Your machine. The serving machine fetches them through the relay, which passes them along in memory and does not store them	To give the model the content it needs	Not stored by the relay	Local session settings (below)
Planning notes and sub-task text the network generates for a request	Relay cache (Redis), with the request	To coordinate planner, worker and helper steps	Same as the request	—
Usage records: request ID, your account ID, the serving machine's ID, model, token counts, timings, outcome	Relay database (Postgres)	Routing, contribution balances, reliability statistics	Indefinitely. There is no automatic deletion yet	Deletion request (§11)
Account: a SHA-256 hash of each API key, your GitHub login and numeric ID if you sign in with GitHub, contribution balance, group memberships	Relay database	Authentication, priority, groups	Until the account is deleted. Unused anonymous accounts with no history are pruned automatically	Revoke keys, deletion request
Machine record (if your machine joins the network): its hostname (shown as the machine's name in your account), hardware description and a hashed hardware fingerprint, benchmark results (including benchmarks of other models you ran by hand), evaluation results you submit, software version, connection status, reputation	Relay database and cache	Deciding what each machine can serve	Until the machine is removed	Remove the machine, deletion request
Evaluation transcripts, only if you opt in to letting the network evaluate models on your idle machine (eval_assist_enabled, off by default): the model's runs of dollama's built-in test scenarios, with your machine's hardware, operating system version and resource readings during the run. Not your own conversations or files	Relay database	So a submitted result can be checked	Indefinitely. There is no automatic deletion yet	Leave the setting off; deletion request (§11)
IP address	Relay memory and cache; the hosting provider's own logs	Rate limiting and abuse prevention	Minutes in the cache. Not written to the database	—
Relay logs: request, account and machine IDs, timings, errors. No prompt or response content	Fly.io log stream	Operating and debugging the relay	Fly.io's log retention	—
Your conversation history	Your machine, in ~/.dollama/sessions	The requester's machine is the store of record for content	30 days or 1 GB by default, whichever comes first	dollama session delete, dollama session gc, config

The relay has a debug setting that logs content. It refuses to start with that setting outside a development environment, so it cannot be switched on for the hosted relay.

6. What happens on your machine

• Tools run locally. Reading files, editing code and running commands happen on your machine, under your coding tool's own permission prompts. A serving machine can ask for a tool call; it cannot run one or reach your filesystem.
• dollama adjusts model output before your tool sees it. To make small models usable, the local proxy and the serving machine repair malformed tool calls, correct file paths that do not exist, and sometimes withhold or retry a step. Your coding tool's approval prompt is still the last check before anything runs. If you set your tool to approve actions automatically, nothing stands between a model's output and your machine. That matters most on the Open Network, where the output comes from a machine you do not control.
• Web search and fetch run from your machine. When the model searches the web or fetches a page, your own machine makes the request, so the search provider or website sees your IP address and the query. dollama runs these itself, without your coding tool's permission prompt, and feeds the results back to the model.
• Local file reads for sub-tasks. When a request runs on a model on your own machine, dollama may read and search files in your project to answer a sub-task, again without a permission prompt. The files stay on your machine unless their content ends up in a request sent elsewhere.
• No telemetry. The CLI has no analytics or crash reporting. Optional capture and debug flags write full requests to local files only.

7. If your machine serves other people

In Group and Open Network modes your machine runs other people's requests. It receives their prompt in plaintext, runs the model, and returns the response. dollama keeps this in memory for the length of the request and does not write it to disk. The model runtime you use (Ollama by default) has its own logging, which dollama does not control.

The same is true in reverse. Contributors are asked not to log or inspect what they process, but that is a rule of participation, not something that can be enforced on someone else's computer. A contributor can run modified software, record what it receives, or return altered output. Health checks confirm that a machine is responsive and running compatible software. They cannot detect a machine that misbehaves selectively.

8. Other capabilities

• Speech-to-text. Audio is fetched from your machine by the serving machine through the relay; the transcript returns through the relay. dollama transcribe uses your own machines unless you pass --public (with a current limit, see §12).
• Embeddings. The text to embed is sent in the request itself and is held in the relay cache like any other request.
• Personal hosting. Sites you publish at *.host.dollama.net are served from your machine through the relay and an ingress server, behind Cloudflare. TLS ends at the ingress, so the ingress and the relay can read the files as they pass through. Public sites are cached at the edge for 5 minutes, so a site switched from public to private can remain reachable from cache for up to 5 minutes. Viewers of private and group sites sign in with GitHub. The ingress uses visitor IP addresses for rate limiting only.
• chat.dollama.net. Chats and your API key are stored in your browser, not on a dollama server. Requests from the web chat always use the Open Network.

9. This website

dollama.net sets no cookies and runs no analytics or advertising. Fonts and scripts are served from dollama.net itself. The site is hosted on Cloudflare Pages, and downloads are served from Cloudflare storage, so Cloudflare processes your IP address and request like any web host. The homepage loads live network statistics from api.dollama.net, which is hosted on Fly.io.

10. Security

• Connections between the CLI, the relay, serving machines and the relay's database and cache use TLS.
• API keys are 256-bit random values. The relay stores only a SHA-256 hash of each key. The key itself is shown once, when it is created.
• By default the local proxy listens only on your loopback interface (127.0.0.1). The one port dollama opens to other machines is UDP 4256, and only if you enable direct links between your own machines.
• A serving machine can fetch only the content items its assigned request lists, using a short-lived token that is valid for that request alone. It cannot browse your session history.

No system is perfectly secure, and this one is experimental. If you find a vulnerability, please email security@dollama.net with what you found and how to reproduce it, and give us a chance to fix it before you publish. Please do not test against other people's accounts or machines.

11. Your choices

• Delete local history: dollama session delete removes a session; dollama session gc applies the retention limits now.
• Revoke credentials: you can revoke an API key and remove a machine from your account at any time.
• Delete your account: there is no self-service deletion yet; it is being built. Until then, email privacy@dollama.net. You will be asked to prove the account is yours (for an account linked to GitHub, by confirming through GitHub). Your account, keys, machines and group memberships are deleted. Usage records are stripped of your identity rather than removed, because other people's contribution balances depend on them.
• Ask what is held: the same address handles requests for a copy of, or corrections to, the data tied to your account.

12. Known gaps

These are places where the software does not yet behave the way the mode you chose suggests. They are listed here because you should know about them before they are fixed.

• dollama ask, dollama chat and dollama embed always use the Open Network in CLI v0.72.0 and earlier, whatever mode the app is in. A fix that makes them follow your chosen mode is in progress.
• A local:<model> request falls back to the network in CLI v0.72.0 and earlier if Ollama is not running. A fix that makes it fail instead is in progress.
• The web chat has no mode. chat.dollama.net always uses the Open Network.
• A machine in Group mode serves only its owner. In CLI v0.72.0 and earlier, a machine running dollama group does not serve its group members' requests. Group requests reach only members' machines that run dollama network. Nothing is exposed that should not be; the mode shares less than it says. A fix is in progress and needs a relay update and a CLI release.
• Speech-to-text and embeddings are served only by machines in Open Network mode. A machine in Private or Group mode does not serve these, even to its owner. A private dollama transcribe therefore needs one of your own machines to be running dollama network; otherwise it fails rather than going elsewhere.

13. Infrastructure providers

The hosted relay depends on providers that process data on the operator's behalf: Fly.io (relay and hosting ingress, Sydney), Neon (Postgres database, Sydney), Upstash (Redis cache), Cloudflare (this website, downloads, and the edge in front of hosted sites) and GitHub (sign-in, if you use it). Request content passes through Fly.io and is held briefly in Upstash, as described in §3 and §5. Neon holds account data and usage records, not content.

14. What dollama does not do

• It does not use your prompts or responses to train models.
• It does not sell or share your data for advertising.
• It does not charge or accept payment for network access. Contribution balances exist only to order the queue when the network is busy. They are not a currency and cannot be traded.

15. Children

dollama is a developer tool and is not directed at children. We do not knowingly collect information from anyone under 13, or the minimum age in your jurisdiction.

16. Changes to this policy

dollama is under active development and this policy will change with it, for example when client-to-client encryption ships or when a known gap is closed. The date at the top shows the last change. Changes that affect how your content is handled will also appear in the notices shown when you choose a mode.

Read the Terms of Service →