> ## Documentation Index
> Fetch the complete documentation index at: https://docs.roomote.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.

# Buildkite

> Inspect Buildkite pipelines, builds, jobs, and tests from Roomote tasks.

Connect Buildkite when tasks need CI pipeline, build, job, log, artifact, test,
cluster, agent, or queue context.

## How setup works

A deployment operator connects Buildkite once from **Settings > Integrations**
using OAuth. The built-in integration uses Buildkite's hosted
`/mcp/readonly` endpoint and requests its `read` scope. Buildkite's public OAuth
metadata supports dynamic client registration and PKCE, so self-hosted Roomote
deployments do not need a preconfigured Buildkite OAuth client.

The organization picker shown during authorization is a convenience, not an
access-control boundary. The connection can see organizations available to the
authorizing account, subject to Buildkite's permissions.

## Network restrictions

If a Buildkite organization uses an API IP allowlist, add Buildkite's published
MCP egress addresses to that allowlist. The hosted MCP server calls the
Buildkite API from Buildkite infrastructure.

## Verify the connection

Start by listing pipelines or inspecting a recent failed build. This built-in
connection is read-only; use a separately configured custom MCP server if a
different endpoint or token-backed toolset is required.