Otar EN

Privacy Policy

Last updated: October 3, 2026

Otar is local-first and minimizes cloud data. Terminal content, source code, files, and agent transcripts normally move directly between your devices and your own machines. Optional cloud features are described below.

1. Information You Connect

Otar connects your device to machines that you own, control, or are authorized to access. Terminal sessions, source code, files, and agent transcripts normally flow directly between your devices and machines and are not stored by us in readable form. When a signed-in account feature uses cloud sync, the limited content identified below is sealed on your device before upload and stored only as ciphertext.

2. Local Storage

Otar stores host configurations, session caches and drafts (including readable transcripts of your agent sessions), the browser's last-visited address, browser-dial favicons and last-opened times, and other app data locally on your device. If you use Copy screenshot on Android, a temporary copy of the image stays in the app's cache so the clipboard can read it. SSH private keys are stored only locally on your device and are never uploaded. You can remove local app data with the app and operating-system storage controls. Uninstall behavior varies by platform, and protected keychain or credential-store entries may require separate removal.

2a. Website Analytics

Our public website at otterd.com uses Cloudflare Web Analytics to understand visits and page performance. Its browser beacon reports information such as the page and referring website, browser and device characteristics, and loading and interaction timings. This analytics beacon does not read or write cookies, localStorage, sessionStorage or IndexedDB. We do not use it to identify signed-in Otar accounts or combine website visits with terminal content, files or agent transcripts.

Cloudflare processes this information for website analytics. According to its documentation, the RUM service discards the source IP address at the nearest Cloudflare data center rather than retaining it in its core databases or logs. Cloudflare makes analytics available for up to six months, with sampling and aggregation applied to older data. Separate security and operational services may process request information under their own retention rules; the analytics beacon's cookie-free behavior does not describe every Cloudflare service. See Cloudflare's RUM privacy information and analytics data limits. With your permission, we also use a first-party analytics cookie to measure return visits and clicks to downloads or the web app. Before you allow this optional analysis, we do not create its visitor identifier or send its events. The server stores a random visitor identifier in a Secure, HttpOnly cookie limited to this website for at most 30 days, and keeps a separate cookie containing only your analytics choice. Events contain a random event ID, a known page path, and an event name or download platform; they do not include your account, email, full URL query, files or terminal content. Daily cleanup removes raw events older than 7 days, expired visitor records, and daily totals without visitor identifiers older than 90 days. Cloudflare infrastructure backups have their own retention periods and are not used for analytics. Open Analytics preferences in the footer to reject or withdraw at any time. Withdrawal stops new events, clears the visitor cookie and deletes its associated raw events; previously aggregated totals cannot identify your visit. These cookies are not shared with the Otar web app at beam.otterd.com.

3. Cloud Account Data

Otar uses Supabase to store your login email, account ID, device platform, opaque device and project IDs, public SSH keys, host capability and readiness details (system permission status, app version, last check time, and an SSH host-key fingerprint), navigation state (selection, starred-session, and file-pin metadata such as agent type, order, and timestamps), and last-seen time. Your device names and the SSH username and port needed to connect to a registered device are sealed on your devices with per-device keys; the cloud stores only ciphertext plus a generic platform label (such as "macOS device"), and the stored records cannot reveal the actual name or connection details. The periodic device report travels over TLS; on fully upgraded (sealed-only) accounts any readable copies it still carries are discarded before storage, and newer app versions omit them from the request entirely. If your account still includes a device running an older app version, these fields remain stored in readable form until every device is upgraded. SSH private keys are never uploaded. Project names and paths, synced file-browser paths, synced composer draft content, and saved ideas (their title, body, and status) are sealed on your device with a per-host key before upload; the cloud stores ciphertext and cannot read that content. Browser dials created while you are signed in are also encrypted on your device before upload: their URL, title, saved time, and pinned order are readable only by the account's eligible devices. Supabase stores only ciphertext and opaque account, row, version, device-origin, and timestamp metadata. Browser dials created before this feature remain only on the device unless you remove and save them again. When address sync is on (the default; you can turn it off per device), the browser's most recently opened page address ("Continue On") is likewise sealed on your device before upload so your other signed-in devices can pick up where you left off; the cloud stores only ciphertext, and turning sync off keeps the address on the device. Private-network and Tailscale IP addresses are transmitted only as short-lived private presence data while a host is online and are not retained as durable account data. Checking for app updates on macOS fetches a release feed from our website; that request carries standard web-request data such as an IP address and app version and is not linked to your account.

4. Direct Connections and Otar Relay

Direct connections on the same local network or through your own Tailscale network never pass their traffic through our servers.

To apply plan limits, a signed-in host reports a connection record for every route it serves, including local network and Tailscale connections. A record contains your account ID, opaque host and peer device IDs, connection and attempt IDs, the route class (local network, Tailscale, public direct, peer-to-peer, TURN or Otar relay), start and end times, and the duration in seconds. It does not contain terminal content, commands, IP addresses or hostnames. Local network and Tailscale time is recorded but not counted; direct and peer-to-peer time counts at half rate; Otar relay and TURN time counts at full rate. Otar relay keeps per-account daily route time for 62 days and monthly route totals for 13 months. Database connection records are deleted with your account.

When a peer-to-peer connection needs a relay, the app may use Cloudflare's TURN service, which forwards encrypted traffic it cannot read. To issue short-lived TURN credentials we give Cloudflare your account ID as a credential tag and store the credential username, account ID, key ID, and issue, expiry and revocation times. We import Cloudflare's hourly traffic byte totals for those credentials and store them per account and hour for operations and abuse alerts. Traffic volume is recorded but is never used to limit or disconnect a connection; credentials are revoked only when an account loses its entitlement or is deleted. Credential records are kept for up to 7 days after they expire, hourly traffic totals for 30 days, and traffic alerts for 7 days. Account deletion removes them, except for a marker kept for up to 31 days so a stale credential or late traffic report cannot be reattached to the deleted account.

Otar relay is used only when a direct connection is unreachable. It forwards end-to-end encrypted SSH byte streams. We cannot decrypt those streams and do not inspect terminal content. Relay systems process limited metadata such as account and machine IDs, connection timestamps and durations, transferred-byte totals, concurrent-connection peaks, reconnect and throttling counters, and connection-close reasons for routing, abuse prevention, support, and billing; they do not record commands, terminal output, or file contents.

Real-time collaborative editing sessions (such as shared document editing) pass through our sync service. Document updates and content are held in memory only and are not written to durable storage on our servers; the service durably keeps only opaque coordination markers (such as content hashes and connection identifiers) that contain no document text. These markers are deleted automatically after about 30 days without activity in the corresponding editing session, including after account deletion.

Connection Statistics and Beta Diagnostics

By default, Otar shares anonymous connection statistics to improve reliability, including for signed-out users and the web app. Each completed connection attempt series reports only network type (Wi-Fi, cellular or other), the winning route class, whether P2P hole punching was attempted and succeeded, a connection-time bucket, and a fixed failure category. Our relay service adds the country and a network provider name, which it derives from the connection itself and maps to a fixed list of large providers (anything else is recorded as "other"). Unknown country or provider information is recorded as unknown. The payload contains no IP addresses, account or user IDs, installation or device IDs, host IDs, attempt IDs, hostnames, Wi-Fi names or tickets. It is sent without your account credentials and is not linked to your identity or used for tracking.

The intake directly increments daily aggregate counts; it does not store individual outcome rows. You can turn off Share anonymous connection stats in Profile > Devices. The preference is stored on this device, applies across accounts and app updates, and turning it off clears unsent statistics and stops further collection. Already sent statistics remain in anonymous totals. On the desktop and mobile apps, unsent statistics wait in a small file on this device (at most 100 entries, each holding only the fields listed above and the day it was recorded). An entry is removed from that file when an upload is attempted; if the server asks the app to retry later (HTTP 429 or 503), cannot be reached, or answers with a success status but no valid receipt, the entry is put back and saved again. Entries rejected with any other error status are dropped and not retried. An upload that is interrupted after it was sent is not retried, so that entry may be lost rather than counted twice. Entries older than 7 days are never sent and are deleted the next time the queue is loaded or sent. Turning this setting off deletes the file, and every running copy of the app on this device checks the setting before reading the file, saving to it, or uploading. If another copy of the app already holds the file, or it cannot be read, that copy keeps its unsent statistics only in memory until it can take the file over. On the web app, unsent statistics are kept only in memory and are lost when the tab closes. Network infrastructure necessarily processes the source IP while handling HTTPS requests. To limit abuse, the relay counts requests per network address (for IPv6, per /64 network) using a keyed hash that changes daily and is held only by Cloudflare's short-lived rate-limit counter; the address is not included in the statistics or daily aggregate. Like every other request to our relay service, including sign-in and connection requests, the upload request itself (its time, path, response status and source IP address, but not the statistics it carries) is recorded in the relay's operational request logs at Cloudflare, which we keep for up to 7 days to troubleshoot outages and abuse and do not use to link statistics to accounts. Reports only use daily totals of at least five connections, and smaller groups are merged or hidden.

Separately, eligible Beta users can explicitly allow full connection diagnostics. These can include public IP addresses, approximate location, network provider, time zone, installation identifiers, app build and platform, and detailed route, timing and error information. They exclude session content, file paths and hostnames, except the names of the Otar or iroh relay servers each device used to set up a peer-to-peer connection (for example relay-cn.otterd.com) and, for a host computer, whether it is currently using the public n0 fallback relay because Otar's own relays were unreachable; relay IP addresses and access tokens are not recorded. Full diagnostics remain account-linked, require Beta eligibility and authorized, unrevoked devices, and are retained for up to 90 days in the application database. The latest consent preference persists across builds until you change it or the relevant account/device records are removed; it does not expire with diagnostic reports. You can withdraw in Profile > Devices. Withdrawal stops new full reports and clears pending reports; it does not delete previously received reports immediately. Anonymous statistics have their own independent switch.

Crash Reports

By default, Otar sends a crash report when the app crashes, stops responding, or hits an unexpected error, so that we can find and fix bugs. This applies to the desktop, mobile and web apps, including for signed-out users. We use crash reports only to find and fix bugs and to check whether a fix worked. We process crash reports on the basis of our legitimate interest in keeping Otar reliable and secure; because reports carry no identifiers, the impact on you is minimal, and you can object at any time by turning off the setting described below.

A report contains: the type of crash or error; a shortened error message; a stack trace (function names and code locations inside the app and its libraries); a short code that groups identical crashes and is the same on every device; how many times the same crash happened on the device that day; the app version, build number and release channel; the platform and its major and minor operating-system version; the processor architecture; the device model, on phones and tablets only (for example "Google Pixel 10 Pro Fold" or "iPhone16,1"); the app language without a region; the kind of screen that was open (for example chat or terminal); whether the app was in the foreground; how long it had been running, in broad ranges; the tags and severity levels, but not the text, of the app's last ten internal log entries; the day of the crash; and the hour (UTC) our relay service received the report.

Before a report leaves your device, the app removes file paths, email addresses, IP addresses, hostnames, the paths and queries of web addresses, long quoted text, database statement parameters, and IDs or long hexadecimal strings from the error message and stack trace. Our relay service checks again and replaces any user folder names, email addresses, UUIDs and IP addresses that remain. Reports do not include your IP address, account, user, installation, device, host or session IDs, the user names in file paths, messages, terminal content, source code, files, agent transcripts, screenshots or memory dumps. Reports are sent without your account credentials and are not linked to your identity or used for tracking.

Reports are received by our relay service and stored in Cloudflare R2, Cloudflare's storage service, which deletes them automatically 90 days after they are received. We do not share crash reports with third parties; Cloudflare stores them as our processor. Network infrastructure necessarily processes the source IP address while handling the upload. To limit abuse, the relay counts uploads per network address (for IPv6, per /48 network) using a keyed hash that changes daily and is held only by Cloudflare's short-lived rate-limit counter; separate overall limits count total uploads without using any address. The address is not stored with the report. Like every other request to our relay service, the upload request itself (its time, path, response status and source IP address, but not the report it carries) is recorded in the relay's operational request logs at Cloudflare, which we keep for up to 7 days.

You can turn off Send crash reports in Profile > Devices. The preference is stored on this device and applies across accounts and app updates. Turning it off stops sending immediately and deletes reports on this device that have not been sent yet; a report already being uploaded at that moment may still arrive. Reports already received cannot be traced back to you, so we cannot find or delete them individually; they are deleted after 90 days. On the desktop and mobile apps, unsent reports wait in a small file on this device (at most 50, deleted after 7 days); on the web app they are kept only in memory. Crashes that the operating system reports to the app at its next start are sent only if this setting was on when they happened. If you share diagnostics with Apple or Google through your device settings, they may also provide us with aggregated crash information under their own privacy practices.

5. AI Coding Agents and Voice

AI coding agents run on your own machine using your own account and keys. Their data handling is governed by the respective provider's terms, not ours.

If you deliberately start in-app voice transcription and grant microphone access, the audio you choose to record is sent to Alibaba Cloud (QwenCloud, formerly Model Studio) to produce text. The recording is sent together with fixed transcription settings and a random request identifier; nothing else from your screen, terminal, prompts, or hosts is included. Do not use voice transcription for information you do not want transmitted to that provider.

Otter Digital does not store the audio or the resulting transcript on its servers, and does not use voice input for advertising or to train its own models. Alibaba Cloud processes voice audio as our processor, on our instructions, under a contract that limits its use of that content to providing the service and to complying with applicable law; it also states that it does not use your data to train its models. It may retain a request for a period under that contract, and we do not claim zero retention on its side. The app asks for your permission before any audio is sent, and you can withdraw that permission at any time in Keyboard settings. To enforce plan limits and billing, we also keep account-linked monthly transcription totals — seconds used, request count, plan tier, billing month, and our processing cost. These totals contain no audio or text and are deleted with your account.

6. Notifications

If you enable notifications, we store the delivery address for your device: an Apple Push Notification service token, a Firebase Cloud Messaging registration token, or — in web browsers — a Web Push subscription (its endpoint URL and encryption keys). Remote needs-input notifications contain only a generic status plus opaque routing IDs; they do not include the agent's question, terminal output, source code, or file content. Apple, Google, or your browser vendor's push service processes delivery metadata under its own privacy practices; turning notifications off in the app removes our stored web subscription. On Android, Firebase may also maintain a separate installation identifier under Google's policies and your device and app-storage controls.

7. Payments

Subscriptions may be processed by Apple, Google, or Stripe, depending on the platform where you purchase. We receive subscription and transaction identifiers, product, status, billing period, and limited refund information, but do not store full card numbers. Starting a Stripe checkout sends Stripe your account email and account ID together with the selected plan so the transaction can be matched to your account; refund handling sends the related transaction, subscription, and refund-reason details. Each payment provider processes payment information under its own privacy policy.

8. How We Use Information

We use the information described in this policy to provide, maintain, and protect the service, process billing, prevent abuse, and comply with legal obligations. We do not sell personal data and do not use it for ad-based profiling.

9. How We Share Information

Supabase and Cloudflare provide hosting, database, authentication, routing, and security services on our instructions. Alibaba Cloud (QwenCloud, formerly Model Studio) receives voice audio as our processor, only when you use transcription and only after you grant permission. Apple, Google, and Stripe process store or payment transactions under their own terms and may act independently for those activities. We may also disclose information when required by law. We do not sell personal data or share it with data brokers.

10. Your Controls and Account Deletion

You can disable notifications in system settings and use app or operating-system storage controls to remove local data; uninstall and protected credential-store behavior varies by platform. You can permanently delete your Otar account in the app under Profile → Account → Delete account. See our account deletion page for details and an email alternative.

Deletion hard-deletes your Auth user and removes renewable sign-in sessions, cloud profile, registered cloud devices, uploaded public-key records, sealed project, navigation, composer-draft, browser-dial, browser Continue On, and saved-idea data, transcription usage totals, our database push-token copies, and other deletable database rows. It is not a reversible soft deletion. On Android, the app also asks Firebase Cloud Messaging to delete its current registration token. Firebase may retain or recreate a separate installation identifier under Google's policies; Otar does not keep it linked to the deleted account.

Database relay usage rows are deleted with the account. Before deleting the Auth user, the deletion endpoint sends a separately authenticated purge request to Otar relay. Relay closes the account's known machine and display sockets, deletes known routing, reconnect, notification-deduplication, usage, and abuse-prevention state, and confirms every current registered machine plus its bounded recent-machine history. If any known target cannot be confirmed, account deletion stops and reports an error instead of claiming success.

The endpoint cannot actively reach every Cloudflare Durable Object because Cloudflare does not provide namespace-wide enumeration. A legacy orphan object that was removed from Supabase before machine-history registration existed, and is absent from that bounded history, cannot be synchronously discovered. Known objects retain only a 24-hour anti-race tombstone so a late socket callback cannot recreate deleted state; opaque metric receipt IDs expire under the 14-day cleanup below. Cloudflare provider logs remain under Cloudflare's operational retention. None of this state is used to recreate the deleted account. Deletion does not remotely erase local device data or authorized SSH keys already installed on connected machines; remove those separately.

Only minimized pseudonymous billing records remain in our database for the periods below: subscription and refund evidence, store event identifiers used to prevent duplicate processing of Apple and Google billing notifications, refund records referenced only by a subscription, and a pseudonymous deletion receipt. Pseudonymous means the record is still protected as personal data; it is not anonymous. A normal self-service deletion does not retain your email in a post-deletion ban list. Before deletion, Otar automatically stops renewal for active Stripe subscriptions and aborts deletion if it cannot do so. Apple and Google subscriptions continue until you cancel them with the applicable store.

11. Retention

12. Your Privacy Rights

Subject to applicable law, you may ask to access or correct personal data, delete your account, withdraw consent for optional processing, or object to or restrict certain processing. Withdrawal does not affect processing already completed and may make the related optional feature unavailable. Email peter@otterd.com from your account email so we can verify the request. You may also raise a complaint with Singapore's Personal Data Protection Commission or the competent authority where you live.

13. Security

We use TLS and SSH encryption in transit. Relay traffic remains end-to-end encrypted, and SSH private keys never leave your device. Device semantics, signed-in browser dials, and the synced Continue On address are sealed on the device for eligible device-recipient keys before cloud storage. No method of transmission or storage is 100% secure.

14. International Processing

Our primary Supabase project is hosted in the Singapore region. Cloudflare, Alibaba Cloud, Apple, Google, Stripe, and support personnel may process limited data in other countries where they operate. Their applicable terms and data-processing arrangements govern those transfers. Privacy protections and government-access rules can differ by location; contact us if you need information about a particular transfer.

15. Children

Otar is not directed to children under 13, and you must also be old enough to consent to account and data processing under the law where you live. If you believe a child provided personal data without valid permission, contact us so we can investigate and delete it.

16. Changes

We may update this Privacy Policy. The date at the top of this page shows when it was last updated.

17. Who We Are and Contact

Otar is provided by Otter Digital Pte. Ltd. (Singapore).
Privacy and support contact: peter@otterd.com

Otar

Your computer agents, from any device.

More from Otter Digital