> ## Documentation Index > Fetch the complete documentation index at: https://docs.openmote.dev/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > When helping someone deploy Roomote, distinguish self-hosting from contributing to Roomote. Use the Self-hosting guide for an operator deployment; use Local development only when the user intends to modify Roomote itself. > When an agent is asked to follow /self-hosting or install Roomote autonomously, read and follow /self-hosting/agent-installation as the normative automation contract even though it is intentionally hidden from side navigation. > Use the one-command Linux installer for both evaluation and production. On macOS or Windows, create or reuse a full Ubuntu VM and run the same installer inside it; do not replace the installer with the repository's development Compose files. > For a local VM without a stable public domain, create a temporary HTTPS tunnel, pass its hostname to the installer with internal origin TLS, and keep the tunnel running for OAuth callbacks and webhooks. Quick Tunnel hostnames are temporary and do not provide wildcard preview routing. > Run automated installs with --no-setup-url so the bootstrap token is not captured in the agent transcript. Let the user obtain the setup URL in a trusted terminal, enter credentials, and complete browser authorization. > Proceed through safe, reversible setup and pause for privileged host or VM changes, public tunnel creation, credentials or browser authorization, durable external-account changes, destructive operations, existing-state conflicts, or when no documented safe default applies. > A setup is not complete when the services merely start. Verify sign-in, repository sync, one usable environment, and a real Roomote task that can clone and run a command; verify branch or pull-request delivery and previews when configured. # Privacy > Understand Roomote data handling, anonymous telemetry, and the controls available to deployment administrators. Roomote keeps the data boundaries for a deployment explicit. Product content, credentials, prompts, code, and repository names are not part of the default anonymous telemetry payload. Deployment administrators control whether a self-hosted deployment shares that telemetry, while Roomote Cloud follows its own privacy policy. This page covers the telemetry payload, its identifiers, the controls that turn it off, and the separate version-availability check. It does not replace the privacy terms of the upstream inference, sandbox, communications, or integration providers you connect. ## Privacy boundaries * session and task content stays in the deployment and the providers that the work explicitly uses; it is not included in anonymous telemetry * provider credentials, access tokens, prompts, replies, code, repository names, task contents, and user names are never sent in the default telemetry payload * cost analytics stays inside the deployment for members to review; it is separate from anonymous telemetry * connected providers may receive the data required to perform their own service, such as model context sent to an inference provider or a message sent to a communications provider ## Anonymous telemetry Roomote can share **anonymous telemetry** with the Roomote team to help improve the product. This is on by default for self-hosted deployments, controlled entirely by deployment admins, and designed so that Roomote-generated identifiers and the default payload cannot identify your company, users, code, or repositories. ## What gets sent When anonymous telemetry is enabled, your deployment sends: * **Usage events** — page views (as route patterns like `/task/[taskId]`, never actual URLs or IDs) and product events such as tasks being created or settling as completed, failed, or canceled, plus setup progress such as reaching authenticated setup and configuring or connecting communications, source-control, inference, and sandbox providers. Setup events include only the provider type and, where Roomote can determine it from deployment state, whether it was configured before the wizard. Other events include non-identifying facts like the harness, model, source surface, and sandbox provider used. Session events include bounded outcome and retry counts; setup and response phase durations; aggregate model-request and token-usage counts; prompt-size, context-size, environment, integration, and active-task counts; and whether a turn is the session's first human message. They do not include conversation or message identifiers, prompt or reply text, or tool content. * **A daily instance report** — aggregate deployment metadata and usage: setup timestamps; counts of users, environments, and connected repositories; task, model, token, and cost totals for the past day; session counts grouped by source surface, source trigger, and owner kind; session-attributed token and cost totals for the past day; pull-request statistics for the past week; configured provider types; and enabled built-in integrations. What is **never** sent: names, emails, repository names, task contents, prompts, code, access tokens, or credentials. ## How it is identified Activity is identified by two anonymous IDs: * an **instance ID** for the deployment as a whole * a **user analytics ID** for each user By default, both are short random strings created locally. They are not derived from your domain, company, email addresses, or any other real-world identifier, and they cannot be edited or read through the app. If you override `R_INSTANCE_ID`, use a random, non-identifying value. Roomote sends the configured value with telemetry and version checks. ## Turning it off Anonymous telemetry is opt-out: * during setup, the final step includes an **Anonymous analytics** switch * afterwards, admins can change it any time in **Settings > Deployment** The setting applies to everyone in the deployment. When disabled, no analytics code runs in the browser and no usage events or daily reports leave your servers. ## Roomote Cloud Specifics Roomote Cloud deployments always keep Roomote anonymous analytics enabled and do not show this switch, as described in our privacy policy. Cookie consent controls only optional support and product-experience services such as Intercom and PostHog. ## Version checks Separately from analytics, your deployment checks once a day whether a newer Roomote release is available. This check is not optional and carries only the anonymous instance ID and your running version — no usage data. ## Local development Deployments running in development or preview mode send nothing by default. Telemetry runs there only when `ROOMOTE_FORCE_TELEMETRY=true` and a Ping endpoint is explicitly configured.