A durable computer for each agent project
Remote by FutrX solves a problem that appears after coding agents become part of daily work: the agent session, source tree, preview server, terminal, and browser all need somewhere dependable to live. A laptop terminal works until it sleeps, changes networks, or becomes the wrong device. Remote moves that working set to your own server and makes it available through one browser interface.
Each project gets an unprivileged LXC container with persistent workspace files and agent homes. Codex, Claude Code, Kimi, and Antigravity can work against the same project state. The interface combines chat, code-server, a root terminal inside the container, file uploads, Git history, listening-port previews, and a headed Chromium session. You can watch the agent browse, then take control of that same browser when a login or human decision is needed. Scheduled prompts can also run after you close the page.
This is the right product shape for a solo developer who regularly jumps among agent CLIs. Remote does not claim to make the models smarter. It gives them continuity, tools, and a place to run. That is less glamorous than a new model, but often more useful.
The interface is the strongest reason to use it
The best feature is the shared view of work. When an agent starts a web server, Remote discovers the listening port, creates a project URL, obtains HTTPS, and shows the result beside the conversation. If the output needs inspection, the same project opens in an IDE, terminal, file manager, or Git history without copying files to another machine. Multiple chats can move in parallel while sharing one project filesystem.
The Agent Browser also addresses a real handoff problem. Agents can drive Chromium through browser tooling, while the user sees the exact same session over noVNC. That makes sign-in and visual review practical. It also creates risk: the project documentation warns that an agent inherits authenticated sites in that browser. Treat it as a privileged session, not a disposable preview tab.
Remote keeps host controls outside the project container. Access, project membership, secrets, CPU, memory, lifecycle, routing, and recovery live in the host application. The containers are replaceable, while the workspace and supported agent homes are bind-mounted from durable host directories. This separation is understandable and well explained.
The easy installer still creates a serious system
The quick start is concise: point a hostname at a fresh Ubuntu or Debian server, confirm key-based SSH, open ports 80 and 443, then pipe the installer into a root shell. The script installs dependencies, builds the Go backend and Preact frontend, configures Caddy and LXD, creates a reusable workspace image, starts the systemd service, and arranges certificates. It also disables SSH password login, so testing the key first is essential.
That automation reduces typing, not responsibility. Each project defaults to a profile targeting 4 GiB of memory, six CPUs, and 2,000 processes, while the host has no default workspace disk quota. Projects and chat logs accumulate on one machine. There is no built-in backup or restore workflow. State is stored in JSON and append-only JSONL files without cross-store transactions, and the documentation recommends operator-managed snapshots or copies.
Updates need care too. The updater rebuilds the application and base image, then may replace project containers. Packages or configuration installed outside the mounted workspace and agent homes disappear during replacement. The documented active-run detector is unreliable, so the project recommends a maintenance window or skipping workspace recycling when interruption would be costly.
Isolation is useful, but not a tenant boundary
The containers reduce the blast radius of ordinary agent work, but Remote's own threat model identifies gaps that rule out casual multi-tenant use. All project containers share the host kernel and an unsegmented LXD bridge. Services such as code-server and noVNC rely on Caddy at the public edge, while sibling containers can reach bridge services more directly. The backend itself runs as root on the host.
Access control also has sharp edges. Any user invited to the platform can reach any project's IDE host, even without project membership. Members of a project can read and change its plaintext secrets and can add other registered users. Claude, Codex, and Kimi credentials are host-level identities shared across projects and copied into their containers. A project-less loose chat runs its agent CLI on the host rather than inside a container. These are documented design facts, not speculative concerns.
For a single operator, or a small group that already trusts one another with the server and provider accounts, those tradeoffs may be acceptable. For a company separating clients, contractors, or sensitive repositories, they are decisive reasons to wait or add controls outside Remote. Unprivileged LXC should not be read as complete isolation.
Young, active, and unusually honest
The repository was created on May 28, 2026, so it has little operating history. The last push was August 14, 2026, and release 0.2.7 shipped that day. Its five open GitHub items consisted of two issues and three pull requests, with other fixes merged on the same date. That is healthy current activity, but 225 stars and a few months of history do not establish long-term maintenance.
Documentation is the standout. Beyond a clear README, the repository includes architecture, operations, known-limitations, and threat-model documents with precise descriptions of failure modes and trust boundaries. Few young self-hosted projects tell operators this plainly where the system can lose state, expose secrets, interrupt runs, or cross an access boundary. The AGPLv3 license also keeps modified network deployments accountable to users.
Remote is already compelling as a dedicated personal agent server. The product experience is cohesive, the supported agents are useful, and browser access makes long-running work easier to supervise. Its present weak point is not ambition or documentation, but the gap between a convenient personal server and a production platform. Install it for trusted use, back it up, isolate the host, schedule updates, and keep valuable credentials out until you accept the threat model.