Cloudroom core: a Rust service that runs coding agents on your own Linux machine

The agent runs on your machine, the room is the abstraction

Cloudroom core is described as an open source, self-hostable Rust runtime that runs Claude Code, Codex and Pi in the cloud, and the README's framing line is that your agents get their own room in the cloud. The concrete mechanism is simpler than the marketing suggests: it runs coding agents on your own Linux machine and saves their chat history. The architecture diagram referenced in the README shows one cloud sandbox per agent, each running Cloudroom core and the agent, which is the shape of the hosted product. The core itself is the part you can run yourself, and the point of running it yourself is that the machine, the credentials and the transcripts stay under your control rather than in someone else's account. The supported agents are listed as Claude Code, Codex, Pi, OpenCode, Hermes, Cursor and Devin, and the model calls use your own logins, so the cost and the quota sit with the provider account you already have.

One service per machine, no account and no database

Two design choices narrow the scope considerably. There is one Rust service per machine, and no Cloudroom account is needed. The installation guide is written for Ubuntu 24.04 with a single script, aimed at a VPS, a home server or a spare laptop, and the README states that no database is required. That last point is the one that changes how you think about operating it. There is no Postgres to migrate, no connection string to manage and no server-side state to reconcile, because the history lives in files on the disk of the machine running the agents. The trade is that querying and analysing your history is now a filesystem problem rather than a SQL problem, and if you want several machines to share one view of the same transcripts you have to build that yourself. The docs directory names the pieces you would need to read for that, with separate pages for storage, harnesses, session lifecycle, observability and the dashboard API.

The HTTP API is the whole interface, and the desktop app is optional

Everything is driven through an HTTP API, and the README links a page that documents every endpoint, event and error code. There is also a desktop app, described as running Claude Code, Codex and Pi on your Mac or in the cloud, and the core is what powers the cloud side of it. The core also works without the desktop app, which matters if you plan to drive it from a terminal or another tool. The app is downloadable for Apple Silicon Macs with a Linux alpha, and you connect it to your own core with a URL and a token, with no account involved. The reach-it-from-your-laptop section of the setup guide describes using Tailscale for that, and the upgrade section describes updating in place, so the intended deployment is a long-lived box you attach to remotely rather than something you start per session.

Agents run as an unprivileged user, and the token and history are out of their reach

The security section is the most useful part of the README for anyone running this on a machine that holds real work. Agents run as a separate Linux user with no admin rights and no sudo. Agents cannot read the core's token or history files. Every API request needs a secret token, and the API listens only on localhost unless you put it behind HTTPS. History stays on the machine's own disk, and the instruction is to back it up like any other folder. There is also a Command Guard that blocks a few disastrous commands, with wiping a home directory given as the example. The threat model this implies is honest and worth stating plainly: agents run without approval prompts, so the README says to give each trusted user their own machine. The sandboxing reduces the blast radius of a misbehaving agent, it does not supervise it.

The dependency list shows an HTTP service with file-based storage, not a database

The Cargo manifest makes the shape of the implementation concrete. The package is named cloudroom at version 0.1.65, on edition 2024 with a minimum Rust version of 1.89, and it is marked publish = false, which is consistent with it being distributed as binaries rather than as a library. The web layer is axum 0.8 with default features off and an explicit feature list covering http1, tokio, json, query and matched-path, running on tokio with the process, io-util and signal features, the last of which is what makes the Ctrl+C handling work for a service managing child processes. Serialisation is serde with derive and serde_json. Storage and transport deserve a note: reqwest is configured with rustls-tls rather than the platform TLS stack, flate2 is present because the comment in the manifest says history files are gzip, and tokio-stream and hyper are there because named preview tunnels need HTTP upgrades. Comments in the manifest also point at architecture decision records, with ADR 0232 covering history, diagnostics and feedback going to the website over HTTPS, and ADR 0237 covering the gzip history files.

Building from source is two cargo commands and a set of prerequisites

You need Rust 1.89 or newer, Git, and the agent CLIs you actually want to run, which is the point of the harnesses documentation. The build itself is:

cargo build --locked --release

and the tests are:

cargo test --locked --all-targets

Both use the locked flag, so the Cargo.lock in the repository pins the dependency versions and the build is reproducible from that lock file. That is the right choice for a service that will hold your agent transcripts. Prebuilt binaries are also published for each Linux release, with the release page described as tested binaries for each release, so you can skip compiling if you want. The repository also carries an install directory, an integrations directory, an adr folder for the decision records, and its own AGENTS.md and SECURITY.md files.

Hosted Cloudroom exists, but it is invite-only and the core does not need it

The README makes the hosted option a single paragraph. If you do not want to host it yourself, hosted Cloudroom is invite-only for now, with a waitlist link on the website. That framing is worth reading carefully, because it tells you where the project expects most users to be. The self-hosted core is the self-sufficient path, and the hosted service is an additional convenience with a queue in front of it. The core's own selling point is that no Cloudroom account is needed, so nothing about running the core requires any of the hosted infrastructure. The version numbering tells you where the project is in its life. Releases are tagged core-v0.1.65, core-v0.1.64 and core-v0.1.63, the first two published within a day of each other in October 2026, with the last push on 2026-10-22. The README says plainly that this is pre-release software, and the version is still below 0.2.0, so the API surface described in the HTTP API page can move.

Where this is the wrong tool

Two boundaries stand out. The first is the one the README states itself: because agents run without approval prompts, giving each trusted user their own machine is the recommendation. That rules out a shared team box where several people reach the same service, and it rules out the pattern of pointing a hosted agent at a shared repository. The second is that the security model is a local single-user model. There is a secret token, one service per machine, and a local user boundary, and while the API can be reached over Tailscale or behind HTTPS, the project does not describe multi-tenancy, per-agent quotas, or an audit trail of who did what across a set of users. If you are running this for yourself, on a box you own, with agents doing work in your own repositories, that is exactly the shape it is built for. If you are trying to build an internal agent platform with access control and cost attribution per team, this is a component you would put underneath something else rather than a platform in itself.

Editorial conclusion

Cloudroom core suits a developer who wants to run several coding agents on hardware they own, keep the transcripts on their own disk, and reach them from a laptop through a private network, and the security model of a separate unprivileged Linux user per agent is the reason to choose it over a hosted agent service. It does not suit a team that wants unattended agents sharing one machine with other users, because agents run without approval prompts and the README says to give each trusted user their own machine. Before you deploy it, read the security notes on the secret token and the localhost-only listener, decide how you will reach the service, since exposing it needs HTTPS in front, and check the storage documentation, since history stays on local disk and becomes your backup problem.

Frequently asked questions

Official sources

1. davidondrej/cloudroom-core on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases