Skip to main content
Roomote is the cloud coding agent you actually own. It runs your development environment in isolated sandboxes, uses your repositories and tools, verifies its work, and returns reviewable pull requests with previews when they apply. Run the same single-tenant product on Roomote Cloud or infrastructure you control. Choose the fastest path for your team. In every deployment, you connect a ChatGPT subscription or inference provider API key, plus source control and a sandbox provider. Connect communications providers and other tools when your team needs them.
Deploy on Roomote CloudDeploy on RailwayDeploy to Render

​
Choose your deployment

  • Roomote Cloud is the fastest way to get started. Your deployment remains isolated while Roomote manages hosting, networking, sandboxes, and upgrades.
  • Railway and Render provision the application, PostgreSQL, and Redis from a template so you can run Roomote on managed infrastructure you control.
  • Your own server gives you the most infrastructure control with the one-command installer below.
Running Roomote on Proxmox or another server at home? Follow the Homelab deployment guide for VM sizing, Tailscale administration, public ingress, and a prompt that a local agent can follow. By the end of setup, you should have a reachable Roomote URL, sign-in, a source-control provider, a ChatGPT subscription or inference provider, at least one environment, and a first reviewable Roomote task. The canonical, always up-to-date guide for operating your own server lives in SELF_HOSTING.md in the repository.

​
One-command install

SSH into a fresh Ubuntu or Debian server (x86_64 or arm64, 4 GB+ RAM) and run:
The installer brings up the full stack from published images and prints a setup link. Open it in a browser and the wizard walks you through the rest: sign-in provider, source-control provider, a ChatGPT subscription or inference provider API key, communications provider, repositories, and a first task. No DNS setup is needed to try it out; pass --domain roomote.example.com for a production install on your own domain. Prefer to read what you are about to run as root? Download, inspect, then run the same script:

​
Setup checklist

Have these ready before the wizard asks for them:
  • a public HTTPS URL for the deployment, especially when source-control or chat callbacks need to reach it
  • a sign-in provider for the people who will use the deployment
  • a source-control provider account with permission to install or configure the app for the repositories Roomote should reach
  • a ChatGPT subscription or inference provider API key, such as OpenRouter, Anthropic, or OpenAI
  • a communications provider workspace, such as Slack, Microsoft Teams, Telegram, or Discord, if your team wants to start work from chat
  • at least one repository that can become the first Roomote environment

​
Day-2 operations

The installer also sets up the roomote host CLI for common operations:
roomote backup prompts for a passphrase and writes a versioned .roomote bundle under /opt/roomote/backups. The bundle contains PostgreSQL, the deployment configuration and encryption/signing keys, local MinIO artifacts, schema metadata, and the exact deployed image identities. Store the passphrase separately in your secret manager; the backup cannot be restored without it. Use roomote backup --include-redis when queued work, BullMQ schedules, sessions, and other transient Redis state must survive. Backups briefly stop application writers (and active Docker task workers) so the included stores share a documented consistency point. If object storage is external, the bundle records its endpoint and bucket but does not copy its objects; keep a provider-level backup of that bucket. Restore only after installing Roomote on the replacement host:
Restore verifies the encrypted bundle and checksums before replacing any state, restores the original .env (including ENCRYPTION_KEY), repopulates empty PostgreSQL/MinIO/Redis volumes, and starts the recorded Roomote release.

​
Upgrades and rollback

roomote upgrade is designed so a bad release cannot strand your deployment:
  • A backup comes first. Every upgrade creates an encrypted pre-upgrade bundle under /opt/roomote/backups before anything changes. Pass a passphrase with --backup-passphrase-file (or ROOMOTE_BACKUP_PASSPHRASE); otherwise one is generated and stored next to the bundle. Use --skip-backup to opt out.
  • Migrations run before services are replaced. Database migrations apply in a single transaction while the previous release keeps serving. If a migration fails, the schema rolls back, the previous configuration is restored, and the previous release stays up.
  • Rollback is one command. Every release’s schema keeps the previous release working, so roomote rollback re-deploys the prior release without touching the database. roomote upgrade <tag> does the same for any retained tag, and restoring the pre-upgrade bundle is the last-resort path that also rewinds data.
Use roomote upgrade instead of updating application image references alone. The command refreshes the release’s Compose and Caddy configuration together; mixing newer application images with an older Caddyfile can leave routes used by the new controller unavailable until the deployment configuration is also updated. The supported rollback target is the release immediately before the current one. Check the running application version and applied schema migration at any time under Settings → Deployment → Diagnostics; both are also recorded in every backup bundle’s manifest. After you upgrade, Roomote can surface the new release in the web app:
  • Admins on self-hosted deployments see an update notice in the sidenav when a newer GitHub release is available, with release notes and a link back to GitHub. Use roomote upgrade (or your image roll-forward process) to install it.
  • Everyone sees a short “what’s new” notice once after the app is upgraded to a new version, pulled from the same GitHub release notes as the changelog.

​
Deployment modes

  • One-command install — deploy/install.sh on an existing server, using published GHCR images.
  • Railway — deploy the managed Railway template with hosted sandboxes. New Railway signups get $20 in credit through our referral link.
  • Local development — pnpm dev runs the services from your checkout with PM2 for fast source edits.
  • Production Compose with Caddy — docker-compose.production.yml adds a Caddy container as the HTTPS entrypoint for your app and preview domains, and runs the containerized stack in production mode with per-install secrets (locally or on a server).

​
Requirements

  • A ChatGPT subscription or inference provider API key (OpenRouter, Anthropic, OpenAI, and others).
  • An account with a supported source-control provider. For GitHub, the setup wizard creates the GitHub App; other providers use their documented OAuth or credential flow.
  • For Slack, Microsoft Teams, Telegram, and Discord: a workspace or server where you can install an app or bot; the setup wizard prefills the Slack app manifest and creates Discord’s installation link for you.

​
Verify the deployment

After setup, run a small task that uses the first environment. A healthy deployment should let you:
  • sign in from the public Roomote URL
  • connect source control and see the expected repositories
  • create or select an environment
  • start a task from the dashboard or chat
  • inspect the task transcript, logs, and any generated diff or artifact
  • open a preview when the task starts a web app

​
Common issues

  • Callbacks fail. For providers that use callbacks or webhooks, confirm the deployment has a public HTTPS URL and that the provider is using that exact URL. Discord uses its Gateway service instead of a public callback.
  • The first task cannot clone a repository. Workers authenticate git with a short-lived GitHub App installation token created when the run starts — they do not read a GH_TOKEN/GITHUB_TOKEN from the container environment. If a task fails with “No GitHub credentials are available”, verify the GitHub App is installed for the repository owner, the installation covers the repository, and the repository appears in the source-control settings after a sync.
  • The agent cannot run useful commands. Add missing services, environment variables, setup commands, or tool versions to the environment.
  • Chat messages do not reach Roomote. Confirm the app is installed, invited to the channel, and using the current callback URL.
  • Memory climbs for hours, or a service is OOM-killed under a container memory limit. Node sizes its heap from the memory it can see (the host’s, not the container’s), so it defers garbage collection and lets memory drift well above what the service needs; a container memory cap then kills the process before Node ever feels pressure. Current app images cap each Node service’s heap by default (768 MB for web and api, 512 MB for controller and bullmq, reduced to ~75% of the container’s memory when a cgroup limit is set). Set NODE_OPTIONS=--max-old-space-size=<MB> on a service to override the default, or on older images to add the cap manually.