You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature Request] BYO computer host — enroll my own machines as bot computers (memoh-style agent / openmausbot-style docker-over-SSH) #1479
Rakazo's remote computer options are all managed sandbox clouds (E2B, Daytona, CreateOS, Box) plus the local Docker supervisor and the Electron "This computer" host. There is no way to attach a machine I already own — a spare VPS, a home box, a cloud dev machine — as a bot computer. The supervisor's HTTP contract (`SANDBOX_SUPERVISOR_URL`) makes remote operation technically possible today, but it is a fully manual ops exercise: run the container yourself, secure the port yourself, point the URL yourself.
Two prior art models worth stealing:
1. memoh — outbound enroll agent. One paste-able line installs a persistent runtime that calls home, so the machine only needs outbound connectivity (NAT-friendly):
The UI issues a scoped key; the node registers itself and stays up via systemd. Great for laptops/NAT machines.
2. OpenMausBot — docker-over-SSH, zero install. The host app provisions a per-bot managed container on a remote machine purely through `docker -H ssh://`. The machine needs nothing installed beyond `dockerd` + SSH reachable; noVNC is bound to a random loopback port and tunneled, so nothing public is exposed. Great for a VPS you already have SSH into. (Its one hard requirement: the host must be inbound-reachable on SSH — opposite of memoh's outbound model.)
Rakazo could support either/both: a UI-issued enrollment token + one-command supervisor install (memoh mode), and/or a "give me an SSH alias and I'll provision it" flow (openmausbot mode). Behind either is the same supervisor that already exists — what's missing is enrollment, scoped auth, and UI surfacing.
My situation / why this matters
I self-host Rakazo on a small VPS (4 GB). The Docker computer works, but a 2 GB desktop per bot strains it. Meanwhile I already have idle compute I'd love to attach instead of renting E2B/Daytona:
several Linux VPSes (SSH + dockerd ready),
Devin Cloud machines (docker available, ephemeral but beefy),
a Grok-bot host and Cursor cloud machines in the same boat.
A one-line enroll command (or SSH-driven provisioning) would turn any of these into bot computers in a minute, keep heavyweight desktops off my tiny API host, and — with egress restriction already implemented — keep the sandbox safety story intact.
Acceptance sketch
Settings → Computers → "Add computer host" → emits an install command carrying a revocable, scoped token (supervisor validates on enroll, registers itself, heartbeats).
Alternatively: provide an SSH host alias → Rakazo provisions supervisor + computer image via docker-over-SSH (no local install).
Either path lands the host as a provider backend selectable per-bot/per-space, with screen streaming funneled through the supervisor's existing token-protected gateway.
I'd like to help build this and wanted to check the approach with you before writing any code.
Use case: Rakazo is self-hosted on a VPS and runs 24/7, and I want bots to reach my laptop (Windows now, Linux later) for commands and files without opening inbound ports or running a VPN.
Proposal: the desktop app dials out to the server
Pairing: in Settings → Devices, the user gets a short code and enters it in the desktop app. The app creates a device key pair, and the server stores only the public key, revocable per device.
Connection: the paired app holds an outbound websocket (or SSE plus POST, if you'd rather not add websockets) to /api/v1/devices/connect, with heartbeats and reconnect with back-off after sleep or wake.
Execution: requests reuse the existing host-computer-protocol and the host-computer.ts handlers (exec, read, write), so the laptop side is mostly existing code.
Tools: new device tools (device_run, device_read, device_write, device_send_file) route through host-aware-sandbox. Write and run calls use the strict approval class in action-approval.ts: no 'always allow', and never unattended from webhook or schedule runs.
Allowlists: per-device folder and command allowlists, enforced on the server and checked again on the device. Every call goes to an audit log.
Offline: when a device isn't connected, its tools return a clear 'device offline' result.
Suggested small PRs
Devices table and migration, plus pairing API (no UI).
Device connection endpoint, plus routing so the worker can reach the API process holding the connection.
Activity
jayfunkdown commentedon Oct 22, 2026
I'd like to help build this and wanted to check the approach with you before writing any code.
Use case: Rakazo is self-hosted on a VPS and runs 24/7, and I want bots to reach my laptop (Windows now, Linux later) for commands and files without opening inbound ports or running a VPN.
Proposal: the desktop app dials out to the server
/api/v1/devices/connect, with heartbeats and reconnect with back-off after sleep or wake.host-computer-protocoland thehost-computer.tshandlers (exec, read, write), so the laptop side is mostly existing code.device_run,device_read,device_write,device_send_file) route throughhost-aware-sandbox. Write and run calls use the strict approval class inaction-approval.ts: no 'always allow', and never unattended from webhook or schedule runs.Suggested small PRs
Questions
I'll keep each PR small and follow CONTRIBUTING. Thanks for Rakazo!