> ## 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 > Start new users at /index to choose Roomote Cloud or self-hosting. Use /cloud for managed hosting and /self-hosting for an operator deployment, including home networks at /homelab. Both paths continue through /first-task. 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, prepare a stable public HTTPS domain before connecting providers. Use a named tunnel with internal origin TLS or public DNS with ports 80/443 forwarded to the Linux host. Cloudflare Quick Tunnels do not support the Server-Sent Events Roomote uses; do not use them for the complete setup path. > 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. Follow /first-task to verify sign-in, repository sync, and a real Roomote task that can clone and run a command. A saved environment is optional for a repository task. Verify branch or pull-request delivery and previews when configured; Slack and other communications providers are optional. # Integrations overview > Connect the tools that give Roomote the right context inside tasks. export function IntegrationName({href, icon, name}) { const manualIcons = { daytona: '/logo/integrations/daytona.svg', e2b: '/logo/integrations/e2b.svg', blaxel: '/logo/integrations/blaxel.svg', box: '/logo/integrations/box.svg', azure: '/logo/integrations/azure.svg', granola: '/logo/integrations/granola.svg', exa: '/logo/integrations/exa.svg', agentmail: '/logo/integrations/agentmail.svg', monday: '/logo/integrations/monday.svg', rippling: '/logo/integrations/rippling.svg', typesafe: '/logo/integrations/typesafe.svg', voice: '/logo/integrations/voice.svg' }; const iconSrc = manualIcons[icon] ?? (icon?.startsWith('/') ? icon : `https://api.iconify.design/simple-icons:${icon}.svg?color=currentColor`); return {name} ; } Integrations give Roomote more context inside a task: tickets, docs, monitoring, analytics, data systems, customer history, deployment state, and shared memory. This section does not list provider categories that have their own setup paths: communications providers, source-control providers, inference providers, and sandbox providers. Configure those from the provider-specific docs instead. Deployment operators can prevent every integration in this curated catalog from being configured or used by setting `R_CURATED_INTEGRATIONS_DISABLED=true` and restarting Roomote. Existing connections remain stored but inactive, so unsetting the value restores them. This policy does not affect the separate provider categories above or MCP servers defined on an environment. ## Connection patterns You will usually see one of these setup models: * **Admin connection once**: an admin connects the integration for the deployment from the **Integrations** page * **Enable first, then teammates link accounts**: an admin enables the integration, then each teammate links their own account from [Personal Settings](/personal-settings) when they need it * **Workspace plus user identity**: the deployment connects the integration, then individual users link their identity so Roomote can associate actions correctly You can also ask Roomote to connect any integration in this catalog from a session. Roomote starts the provider's OAuth flow when the integration supports OAuth, opens the existing secure configuration form when an admin-managed key or certificate is required, and enables keyless integrations directly. The same admin, ownership, and deployment availability rules apply as on the **Integrations** page. Credentials are never collected in chat. Most catalog integrations connect once for the whole deployment, so connecting one makes it available to everyone; a few connect for one person instead. If you ask Roomote to connect a provider just for yourself, it goes by which kind that provider is. A per-person integration it simply connects for you. A deployment-wide one it does not connect quietly: it tells you the integration would be shared with everyone, and offers the routes that can stay private instead, the provider's own remote MCP server added under [Personal Settings](/personal-settings) or a personal [integration key](/integration-keys). It connects the shared integration only if you say that is fine. Roomote can list the full built-in catalog and current connection status without starting setup. A connection starts only after you ask to connect a provider. If you explicitly request a remote MCP server or direct API access instead, Roomote keeps that choice separate from the built-in integration path. A denied or pending authorization, unavailable integration, or permission failure is not silently bypassed with another connection method. ## Manage available tools Some connected integrations expose a **Manage tools** action on the **Integrations** page. Admins use it to choose how Roomote can use each of the integration's tools. These per-tool choices are available without an Experimental opt-in: * **Always allow**: the tool runs without asking. This is also what a tool you have not made a choice about does. * **Always ask**: every call pauses until the session owner allows it once, allows it for the rest of that session, or denies it. A task asks the owner of its session the same way, and a task nobody can answer for, such as one an automation started, cannot run the tool. * **Disable**: the tool is hidden from Roomote and refused if called directly. Tools are grouped into read-only and write/delete tools when the integration describes them, and each group can be set in one click. Choices apply to the whole deployment from the next session turn. In a session, the owner can also ask to be asked about any tool for the rest of that session from the tool's call in the transcript. When an approval is pending, it can be decided from the session; Slack, Discord, and Telegram also show approval buttons in the conversation. Microsoft Teams keeps the approval action in the linked web session. Members manage the same choices for their own private MCP servers from [Personal Settings](/personal-settings); those apply to their own sessions only. Some integrations can only list tools after the first user links their account from [Personal Settings](/personal-settings). ## Supported integrations | Integration | Best for | Connection model | | - | - | - | | | Project and task context from Asana | Admin connection once | | | Monitoring and incident context | Admin connection once | | | Read-only CI pipeline and build context | Admin connection once | | | Prompts, runs, and evaluation context | Enable first, then teammates link accounts | | | Cloud infrastructure and API operations | Admin connection once | | | Voice narration for feature-demo videos | Admin connection once | | | Keyless web search; optional Agent research | Admin enables; API key optional | | | Dashboards, alerting, and monitoring context | Admin connection once | | | Meeting notes, transcripts, and decisions | Admin connection once | | | Issues, projects, and JQL-backed issue context | Admin connection once | | | Turning issues into Roomote work | Workspace plus user identity | | | Board, item, and workspace context | Enable first, then teammates link accounts | | | Database inspection in Neon | Enable first, then teammates link accounts | | | Shared docs and database context | Admin connection once | | | Product analytics, experiments, and error context | Admin connection once | | | Customer issue and account context | Admin connection once | | | Project and service context from Railway | Admin connection once | | | Email delivery and infrastructure management | Admin connection once | | | Authoritative employee and reporting context | Admin connection once | | | Error and performance investigation | Admin connection once | | | Data warehouse exploration | Admin connection once | | | Read-only database access in Supabase | Enable first, then teammates link accounts | | | Shared memory across tasks and sessions | Admin connection once | | | Deployments, logs, and domain availability | Admin connection once | | | Voice calls with Roomote in sessions | Admin connection once | | | Public X posts, users, trends, and news | Admin connection once | | | Paid external capabilities via Zero | Admin connection once | ## HTTP APIs without an MCP server Deployment operators can configure [HTTP integrations](/integrations/http-integrations) for approved HTTPS APIs. Sessions and sandbox agents use the same actor access rules, while Roomote keeps credentials server-side and attaches them to authorized requests. This opt-in feature does not change sandbox networking. ## Custom MCP servers Beyond the built-in catalog, you can connect your own MCP servers at two scopes: * **Deployment-wide**, on the **Integrations** page (see [Custom MCP servers](/integrations/custom-mcp-servers)): remote servers (with header or OAuth authentication, credentials held server-side) and local stdio servers, available to agents in every task. * **Per-environment**, in the YAML view of the environment editor. See [Environments](/environments). An environment entry with the same name as a deployment-wide server takes precedence in that environment. Use deployment or user-linked integrations when the tool is broadly useful across teams. Use an environment-level MCP server when the tool only makes sense for one workspace, repository set, or self-hosted service. To use Roomote itself from an external OAuth-capable MCP client, connect the [Roomote MCP](/integrations/roomote-mcp). It can inspect Roomote and connected chat context, search and read tasks, list launch environments, launch or cancel tasks, and send follow-up messages. Its browser-issued credential does not grant general API or admin access. ## A practical order For most teams, this order works well: 1. the required providers: [Comms](/communications), [Source Control](/source-control), [Inference](/models), and [Sandboxes](/compute) 2. one task-tracking integration, such as Linear, Jira, or Asana, if your team already works there 3. one monitoring or deployment integration, such as Sentry, Grafana, Railway, Better Stack, or Vercel, when investigations need it 4. one knowledge-base integration, such as Notion, to get tasks done directly from specs and runbooks 5. one data integration, such as Snowflake, Supabase, or Neon, when tasks need database or warehouse context 6. Supermemory when you want durable team context to carry across tasks and sessions After each connection, run a small task that uses the new context. For example, ask Roomote to summarize a linked issue, inspect a monitoring alert, or explain which environment a support thread belongs to. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.