mirror of
https://github.com/openclaw/openclaw.git
synced 2026-03-12 23:40:45 +00:00
38da2d076c
* CLI argv: add strict root help invocation guard * Entry: add root help fast-path bootstrap bypass * CLI context: lazily resolve channel options * CLI context tests: cover lazy channel option resolution * CLI argv tests: cover root help invocation detection * Changelog: note additional startup path optimizations * Changelog: split startup follow-up into #30975 entry * CLI channel options: load precomputed startup metadata * CLI channel options tests: cover precomputed metadata path * Build: generate CLI startup metadata during build * Build script: invoke CLI startup metadata generator * CLI routes: preload plugins for routed health * CLI routes tests: assert health plugin preload * CLI: add experimental bundled entry and snapshot helper * Tools: compare CLI startup entries in benchmark script * Docs: add startup tuning notes for Pi and VM hosts * CLI: drop bundled entry runtime toggle * Build: remove bundled and snapshot scripts * Tools: remove bundled-entry benchmark shortcut * Docs: remove bundled startup bench examples * Docs: remove Pi bundled entry mention * Docs: remove VM bundled entry mention * Changelog: remove bundled startup follow-up claims * Build: remove snapshot helper script * Build: remove CLI bundle tsdown config * Doctor: add low-power startup optimization hints * Doctor: run startup optimization hint checks * Doctor tests: cover startup optimization host targeting * Doctor tests: mock startup optimization note export * CLI argv: require strict root-only help fast path * CLI argv tests: cover mixed root-help invocations * CLI channel options: merge metadata with runtime catalog * CLI channel options tests: assert dynamic catalog merge * Changelog: align #30975 startup follow-up scope * Docs tests: remove secondary-entry startup bench note * Docs Pi: add systemd recovery reference link * Docs VPS: add systemd recovery reference link
103 lines
3.7 KiB
Markdown
103 lines
3.7 KiB
Markdown
---
|
||
summary: "VPS hosting hub for OpenClaw (Oracle/Fly/Hetzner/GCP/exe.dev)"
|
||
read_when:
|
||
- You want to run the Gateway in the cloud
|
||
- You need a quick map of VPS/hosting guides
|
||
title: "VPS Hosting"
|
||
---
|
||
|
||
# VPS hosting
|
||
|
||
This hub links to the supported VPS/hosting guides and explains how cloud
|
||
deployments work at a high level.
|
||
|
||
## Pick a provider
|
||
|
||
- **Railway** (one‑click + browser setup): [Railway](/install/railway)
|
||
- **Northflank** (one‑click + browser setup): [Northflank](/install/northflank)
|
||
- **Oracle Cloud (Always Free)**: [Oracle](/platforms/oracle) — $0/month (Always Free, ARM; capacity/signup can be finicky)
|
||
- **Fly.io**: [Fly.io](/install/fly)
|
||
- **Hetzner (Docker)**: [Hetzner](/install/hetzner)
|
||
- **GCP (Compute Engine)**: [GCP](/install/gcp)
|
||
- **exe.dev** (VM + HTTPS proxy): [exe.dev](/install/exe-dev)
|
||
- **AWS (EC2/Lightsail/free tier)**: works well too. Video guide:
|
||
[https://x.com/techfrenAJ/status/2014934471095812547](https://x.com/techfrenAJ/status/2014934471095812547)
|
||
|
||
## How cloud setups work
|
||
|
||
- The **Gateway runs on the VPS** and owns state + workspace.
|
||
- You connect from your laptop/phone via the **Control UI** or **Tailscale/SSH**.
|
||
- Treat the VPS as the source of truth and **back up** the state + workspace.
|
||
- Secure default: keep the Gateway on loopback and access it via SSH tunnel or Tailscale Serve.
|
||
If you bind to `lan`/`tailnet`, require `gateway.auth.token` or `gateway.auth.password`.
|
||
|
||
Remote access: [Gateway remote](/gateway/remote)
|
||
Platforms hub: [Platforms](/platforms)
|
||
|
||
## Shared company agent on a VPS
|
||
|
||
This is a valid setup when the users are in one trust boundary (for example one company team), and the agent is business-only.
|
||
|
||
- Keep it on a dedicated runtime (VPS/VM/container + dedicated OS user/accounts).
|
||
- Do not sign that runtime into personal Apple/Google accounts or personal browser/password-manager profiles.
|
||
- If users are adversarial to each other, split by gateway/host/OS user.
|
||
|
||
Security model details: [Security](/gateway/security)
|
||
|
||
## Using nodes with a VPS
|
||
|
||
You can keep the Gateway in the cloud and pair **nodes** on your local devices
|
||
(Mac/iOS/Android/headless). Nodes provide local screen/camera/canvas and `system.run`
|
||
capabilities while the Gateway stays in the cloud.
|
||
|
||
Docs: [Nodes](/nodes), [Nodes CLI](/cli/nodes)
|
||
|
||
## Startup tuning for small VMs and ARM hosts
|
||
|
||
If CLI commands feel slow on low-power VMs (or ARM hosts), enable Node's module compile cache:
|
||
|
||
```bash
|
||
grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'
|
||
export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
|
||
mkdir -p /var/tmp/openclaw-compile-cache
|
||
export OPENCLAW_NO_RESPAWN=1
|
||
EOF
|
||
source ~/.bashrc
|
||
```
|
||
|
||
- `NODE_COMPILE_CACHE` improves repeated command startup times.
|
||
- `OPENCLAW_NO_RESPAWN=1` avoids extra startup overhead from a self-respawn path.
|
||
- First command run warms cache; subsequent runs are faster.
|
||
- For Raspberry Pi specifics, see [Raspberry Pi](/platforms/raspberry-pi).
|
||
|
||
### systemd tuning checklist (optional)
|
||
|
||
For VM hosts using `systemd`, consider:
|
||
|
||
- Add service env for stable startup path:
|
||
- `OPENCLAW_NO_RESPAWN=1`
|
||
- `NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache`
|
||
- Keep restart behavior explicit:
|
||
- `Restart=always`
|
||
- `RestartSec=2`
|
||
- `TimeoutStartSec=90`
|
||
- Prefer SSD-backed disks for state/cache paths to reduce random-I/O cold-start penalties.
|
||
|
||
Example:
|
||
|
||
```bash
|
||
sudo systemctl edit openclaw
|
||
```
|
||
|
||
```ini
|
||
[Service]
|
||
Environment=OPENCLAW_NO_RESPAWN=1
|
||
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
|
||
Restart=always
|
||
RestartSec=2
|
||
TimeoutStartSec=90
|
||
```
|
||
|
||
How `Restart=` policies help automated recovery:
|
||
[systemd can automate service recovery](https://www.redhat.com/en/blog/systemd-automate-recovery).
|