> ## 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.
> Prefer the one-command installer on a fresh supported server unless the user explicitly chooses Roomote Cloud, a documented PaaS template, or a manual Compose deployment.
> Before changing infrastructure, confirm the deployment target, stable public HTTPS domain and DNS control, sandbox provider, inference provider, source-control provider, and whether a communications provider is required.
> Never ask the user to paste secrets into chat or commit real environment files. Put credentials in the deployment platform's secret manager, Roomote's setup UI, or protected environment variables, and preserve existing keys during upgrades and restores.
> Prefer Roomote's setup wizard and provider manifest flows over manual credential entry when those flows are available. Ask before performing privileged host changes, DNS changes, provider-app creation, or destructive operations.
> A setup is not complete when the services merely start. Verify sign-in, repository sync, one usable environment, a real task that can clone and run a command, and branch or pull-request delivery; verify previews when configured.
> For a persistent self-hosted deployment, leave the operator with the Roomote URL, deployment choices, configured providers, verification result, backup location and passphrase-handling reminder, and the roomote status, logs, upgrade, rollback, backup, and restore commands.

# Contributing recipes

> Propose a reusable Roomote system for the Cookbook through a repository issue.

Use this skeleton when proposing a Cookbook recipe. Replace every placeholder
and remove the comments before opening a
[Cookbook recipe issue](https://github.com/RooCodeInc/Roomote/issues/new?template=cookbook-recipe.yml).
Do not open a pull request unless a maintainer invites you to. Fill in the
contributor fields in the frontmatter and repeat the contributor in the
Overview metadata. If the recipe comes from another team, use those fields for
the attribution.

````markdown theme={null}
---
title: Outcome-first recipe title
description: One sentence explaining the finished system and why it matters.
icon: lucide-icon-name
contributor: Name or team
contributor_url: https://example.com/contributor
contributor_company: Company
contributor_company_url: https://example.com/company
---

## Overview

<!-- Explain the recurring problem and the outcome this recipe creates. -->

Overview paragraph.

- **Trigger**: Trigger type
- **Setup time**: About N minutes
- **Requires**: Product access, integrations, permissions
- **Serves**: Teams or roles
- **Cooked By**: [Name or team](https://example.com/contributor) from [Company](https://example.com/company)

## Ingredients

<!-- List product features, integrations, permissions, environments, and channels. -->

- Ingredient

## Steps

<!-- Use exact labels and Settings paths from the current product. -->

1. First step.

## Paste-ready configuration

<!-- Name the exact field for every paste block. Never include real credentials. -->

```text
Configuration or prompt
```

## Variations

<!-- Offer useful adaptations without turning them into separate recipes. -->

- Variation

<!-- State provider support, permission boundaries, and other limitations plainly. -->

**Pairs well with:** [Related recipe](/cookbook/example)
````

Before submitting, test every paste block against the current product and make
sure the recipe never relies on a prompt alone to enforce a security boundary.