Skip to content

[Feature Request] BYO computer host — enroll my own machines as bot computers (memoh-style agent / openmausbot-style docker-over-SSH) #1479

Open

Description

@WeiYiAcc

Summary

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):

```sh
npm install -g @memohai/cloud-runtime &&
memoh-cloud-runtime enroll --server https://app.memoh.net/api/memoh --key mrk_… --team-id … &&
memoh-cloud-runtime service install && memoh-cloud-runtime service start
```

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.

Activity

  1. jayfunkdown commented on Oct 22, 2026

    @jayfunkdown

    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

    1. Devices table and migration, plus pairing API (no UI).
    2. Device connection endpoint, plus routing so the worker can reach the API process holding the connection.
    3. Desktop client: pairing, outbound connection, reconnect, optional autostart.
    4. Device tools and approval wiring.
    5. Allowlists and audit log.
    6. Web and mobile Devices page (pair, list, revoke, history).
    7. Docs and tests.

    Questions

    • Is this something you'd accept upstream?
    • Websocket, or something already in the stack?
    • Should device tools sit beside the sandbox tools or behind the existing host-aware abstraction?
    • Any naming or placement you'd prefer?

    I'll keep each PR small and follow CONTRIBUTING. Thanks for Rakazo!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions