Roomote: a chat-driven coding agent that clones your repo per task and reviews as a pull request

The task arrives in chat and leaves as a pull request

The workflow is worth describing precisely because it is narrower than the word agent usually implies. You send a sentence from a chat application, something like a request to fix a specific error on a specific route for one plan type. The service picks the task up, provisions a sandbox containing a full clone of your repository, locates the fault, writes a change, runs the test suite, captures a screenshot of the page, and opens a pull request carrying that screenshot. You then review a diff the way you would from any colleague and merge it. Nothing runs on your local machine, every task gets its own sandbox, and the agent cleans up after itself, so there is no daemon to babysit and no editor plugin to keep in sync. The readme also lists the chores it is aimed at, which are dependency upgrades, linter fixes, configuration changes, migration files and boilerplate, and it is explicit that answering a codebase question by reading the code is a supported task rather than a side effect.

Source available, free to ten users, and a paid licence above that

The licensing is the first thing to get right, because the word used is source available and not open source. The package manifest carries a functional copyleft style licence identifier rather than a permissive one, and there is a separate trademark document in the tree, so both the code terms and the name are governed. The pricing model is unusual and stated plainly. There is no per seat SaaS charge: the software is free for up to ten users, and if you need more than that you buy a self-hosted licence from the vendor's own cloud product. The arguments offered for running it yourself are the usual ones and they are specific. No repository access leaves your network. You can read every line and extend or fork it. There is no markup on tokens, and you can switch models per task. The hosted path is offered as the alternative, with a seven day trial and no credit card, and it is described as the same single tenant product, so the trial is a real deployment of the same software rather than a shared sandbox.

A chat subscription works as inference, with no API key at all

There are two ways to supply a model and the first one surprises people. If you already pay for a chat subscription, you connect that account directly and Roomote uses the models included in it, with no API key and no separate billing line. The second path is a bring your own key, and the list of providers is long enough to be a feature: a gateway, the major model labs, a hardware cloud, two Asian model providers named separately, a coding plan product, an open source serving project, and a coding assistant subscription. That breadth is a double edged thing. It means you are not locked to one vendor and you can route a cheap task to one model and a hard one to another, but it also means the integration surface is wide and the readme does not say which of these paths support which features, so a capability difference between providers is plausible and undocumented. The other two provider categories are narrower: sandbox compute lists a serverless platform, two hosted development environments and local Docker, and source control lists the major hosts plus a self hosted one and a cloud DevOps service.

Self hosting is one curl command over SSH, and it installs Docker for you

The self hosted path is the shortest instruction in the readme. You SSH into a fresh Debian or Ubuntu machine, four gigabytes of memory recommended, and run a single command that pipes a remote script into a shell with elevated rights. The installer is described as handling Docker, the secrets and the Compose stack, and it prints a setup link when it finishes, which you then open and follow on screen before sending a test message. For production you point DNS at the machine and pass a domain flag. Two details are worth pausing on. First, the install pattern pipes a script from the vendor's domain straight into a privileged shell, so the trust decision is entirely in that URL, and a self hosted install of a source available product is a decision about whether you would rather run that script or read it first. Second, separate deployment guides exist for two other platforms in the deploy directory, so if you already run one of those, read its document rather than the curl path. The whole command is one line:

curl -fsSL https://get.roomote.dev | sudo bash

Datastores publish to loopback, and the production overlay closes them

The compose file contains the most careful piece of engineering in the repository, and it is a comment. The database, the cache and the object store are all published to addresses bound to the loopback interface rather than to all interfaces, and the comment explains the reasoning: they must never be reachable from another host, the production reverse proxy overlay resets those publications to none, and if you genuinely need remote access you should use an SSH tunnel or a proxy. Every image is pinned by digest rather than by tag, including the database image, which carries the vector extension as a Postgres 17 build, so the extension is baked in rather than added by an init script. The object store runs with a default root user and a default password that both come from environment variables with local defaults, which is fine on a loopback bound port and a problem the moment that port is not. The database service creates two separate databases, one for development and one for tests, because the test command pushes schema to the test database first.

Five compose files, a reverse proxy, an object store and a service manager

The deployment surface is broad, and the top level shows why. There are five compose files rather than one: a default stack, a production variant, a self host variant, and one that appears to wire the local Docker sandbox compute path, plus a platform render file. Alongside them sits a service manager configuration in the ecosystem file format, which is the process supervisor convention rather than a container one. The stack in the default compose file is a Postgres with the vector extension, a cache, an object store with a companion initialisation service, and a reverse proxy, and the package scripts bring that subset up on its own for local work, along with a separately profiled service the scripts call the brain, which is started detached and waited on. A file listing for dead code is wired into the check script, and a lock file for skills sits at the top level, so the agent's own capabilities are pinned the same way the toolchain is. The environment files are split into a local example and a production example rather than one template, which is the right shape for secrets that differ by target.

Node 22 or 24, pnpm pinned, and a formatter that is not the usual one

The toolchain in the package manifest is specific enough to reproduce. The package manager is pinned to an exact version, and the engine constraint allows Node 22 or 24 with pnpm on the 10 line, so the project is explicit that it supports two Node majors rather than the current one only. Formatting and linting are not the common choices: a dedicated formatter replaces the usual one, and the linter is invoked with warnings denied, so a warning is a failure rather than noise. Nearly every task runs through a task runner with grouped log ordering and new output only, which is why linting, type checking, testing and building all share the same flags, and why a full check chains the four of them. Two details are worth noting. The test script pushes the database schema to the test database before running anything, and runs the task runner at concurrency one, which serialises suites and slows them deliberately. And a pre-push hook runs a separate script rather than the same commands, so what runs before a push is not identical to what continuous integration runs.

Editorial conclusion

This is worth evaluating if your team already reviews pull requests and wants a second pair of hands on chores rather than on design, because the output is a diff you already know how to read, every task runs in its own sandbox that cleans up after itself, and the audit trail records which model ran, which tools were called and what code was written. It is the wrong tool for a repository where you cannot let an autonomous process read the source, since self hosting is the only way to keep repo access inside your network and the hosted path is somebody else's cloud. It is also the wrong tool if you need an open source dependency you can vendor, because the licence is source available with a self hosted seat count and a paid licence above it, not a permissive grant. Before you deploy, check three things: which inference path you will use, because connecting a chat subscription avoids an API key entirely and a bring your own key path means you are choosing a provider from a long list with no abstraction above it; which sandbox provider you trust with a full clone of your repository, since local Docker is one of the options and that is the one you control; and what the datastores are exposed to, because the development stack publishes its database, cache and object store to loopback addresses only and resets those publications to none in production.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes