loading
Pick the right open personal-agent runtime, boot it cleanly, put it on a VPS without opening a liability hole, and turn it into a useful daily assistant instead of a fragile demo.
Best personal continuity
The strongest fit when the product is a real personal assistant: chat from CLI or messaging, keep skills and memories, run jobs, and grow reusable procedures over time.
Best for: Always-on personal operator that learns from repeated work.
Best explicit persona workspace
Best when you want a configurable personal assistant shell with visible workspace files, channel routing, Control UI, and per-agent state.
Best for: Personal assistant workspace with explicit identity files and channel control.
Best coding sandbox
The open competitor to include when the mission is software work: mount a repo, run a Docker-backed sandbox, and use a GUI or Agent Canvas backend for coding tasks.
Best for: Open-source coding agent and self-hosted software-work backend.
Scores are Boostor implementation estimates from the current official docs, weighted for one person trying to run a useful personal agent this week.
Daily phone assistant
Hermes or OpenClaw
Repo-changing coding agent
OpenHands
File-backed persona
OpenClaw
Self-improving skills loop
Hermes
One-user VM backend
OpenHands Agent Canvas
| Axis | |||
|---|---|---|---|
| Best first build | Phone-first personal operator | Personal assistant gateway | Coding workbench |
| Identity model | Profile + skills + memories | AGENTS/SOUL/TOOLS/USER files | Project settings + workspace |
| Primary UI | CLI/Desktop/dashboard/channels | Control UI/gateway/channels | GUI/Agent Canvas |
| Execution boundary | Local, Docker, SSH, Modal | Local, Docker/VPS, per-agent state | Docker sandbox, VM backend |
| VPS posture | Gateway service + remote dashboard | Hardened Gateway + durable state | Agent Canvas backend/full UI |
| Watch-out | Review self-improved skills | Do not expose dashboard casually | Mounted repos can be modified |
Do not start with three assistants. Boot one, prove one workflow, then add channels and autonomy after the safety loop works.
Use Hermes when the desired product is an assistant that keeps getting better at your recurring life/work routines.
Install, run setup, choose one provider, and ask a simple task. Do not add gateway, cron, voice, or skills until normal chat works.
Write a short profile: name, timezone, working hours, risk tolerance, preferred tone, no-go actions, and daily recurring jobs. Keep it terse enough to stay useful.
When a workflow repeats twice, capture the inputs, exact steps, verification command, output format, and failure mode as a skill. Review before trusting it.
Connect Telegram, Discord, Slack, or another gateway only after CLI proof. Keep owner IDs, bot tokens, and API keys out of repo files.
Run the gateway as a service, ship logs, enable updates, keep the dashboard private or OAuth-protected, and write a one-page recovery note.
$ curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
$ source ~/.zshrc
$ hermes setup
$ hermes model
$ hermes gateway setup
$ hermes dashboard
Use OpenClaw when you want a file-backed personal assistant workspace with visible persona, tool notes, and channel controls.
Install the CLI, complete onboarding, open the dashboard, and confirm the model responds before installing daemon or channel paths.
Use AGENTS.md for operating rules, SOUL.md for persona and boundaries, TOOLS.md for tool notes, USER.md for user preferences, and IDENTITY.md for the assistant identity.
For phone-first use, start with one allowlisted channel. Verify dashboard auth and gateway logs before adding a second channel.
Use separate agents for personal life, business ops, code execution, and web browsing. Each can keep separate state, sessions, and skill allowlists.
Harden SSH or Tailscale first, persist `~/.openclaw`, keep dashboard access private, and do not expose gateway ports without auth.
$ npm install -g openclaw@latest
$ openclaw onboard --install-daemon
$ openclaw dashboard
$ openclaw channels login
$ openclaw gateway --port 18789
Use OpenHands when the assistant's main job is coding, repo maintenance, test loops, or backend-like software tasks.
For local repo work, start with `openhands serve --mount-cwd`. For an always-on backend/UI, use Agent Canvas and the VM guide.
The mounted directory is what the agent can modify. Start with a disposable repo or a branch/worktree until trust is earned.
Use the settings UI or environment variables. Keep secrets in OpenHands settings/persistence, not inside prompts or committed repo files.
Require `git diff`, targeted tests, build/lint, and a final summary before accepting edits. Do not let auto-approve touch production repos.
Use 2 vCPU/4 GB RAM for one user, set `LOCAL_BACKEND_API_KEY`, keep port 8000 closed unless tunneled/proxied, and use tmux or a service manager.
$ uv tool install openhands --python 3.12
$ openhands serve --mount-cwd
$ npm install -g @openhands/agent-canvas
$ agent-canvas
$ LOCAL_BACKEND_API_KEY=<strong-secret> agent-canvas --public
| Tier | Shape | |||
|---|---|---|---|---|
| Local laptop | Developer machine with Docker | Best for first chat, model config, skills review, and desktop use. | Best for first onboarding and Control UI before channel exposure. | Best for repo work through `openhands serve --mount-cwd`. |
| Tiny API-backed VPS | 1-2 vCPU, 1-2 GB RAM, no local model | Works for light gateways if API models do the heavy lifting. | Avoid 1 GB Docker builds; docs call out 2 GB RAM minimum for image build. | Too tight for comfortable Agent Canvas; use only for experiments. |
| Standard personal VPS | 2 vCPU, 4 GB RAM, Ubuntu 22.04/24.04 | Strong default for one always-on personal gateway and dashboard. | Strong default for gateway plus durable `~/.openclaw` state. | Matches Agent Canvas VM guidance for one user. |
| Hardened public host | VPS plus Tailscale/SSH tunnel, TLS proxy, auth, logs | Use OAuth-backed dashboard, allowlists, system service, and log review. | Harden admin access first; bind gateway privately when possible. | Use `LOCAL_BACKEND_API_KEY`, closed ports, tunnel or reverse proxy. |
| Local model box | GPU or Apple Silicon memory pool | Point Hermes at the local or self-hosted model endpoint after base chat works. | Use provider config and scale context only after gateway is stable. | Local LLM workflows need materially more memory/VRAM than API-backed use. |
If it talks to the internet, it gets auth, allowlists, closed ports, logs, updates, and a restore note. A personal agent is not just an app process; it has credentials, tools, and memory.
Pros
Cons
Pros
Cons
Pros
Cons
A useful personal agent is a loop: instruction, execution, evidence, reflection, memory promotion, and re-test. Skip the receipt and you get a confident chat surface with hidden state.
One owner identity and one recovery path are documented.
Every channel has an allowlist and a test message receipt.
The agent can explain where secrets live without printing them.
Tool execution has a boundary: Docker, SSH, worktree, VM, or no command tools.
Memory writes are reviewable; promoted skills have source, purpose, and rollback notes.
A weekly receipt records tasks run, files changed, failures, costs, and next actions.
# date, agent, model, version
# requested workflow
# tools used and files touched
# proof commands and outputs
# memory or skill changes
# rollback and next action
This page intentionally links to official docs rather than third-party blog summaries. Pricing and hosted product limits can change, so use provider pages before buying infrastructure.