Deploy an Agent on Hetzner or Vultr
Use RunClaw's cloud provisioning flow to launch an AI agent on Hetzner or Vultr.
Use this guide if you want RunClaw to create a new cloud server for you.
- Choose Provision on Hetzner for the easiest path
- Choose Provision on Vultr if you prefer Vultr as your cloud provider
If you already have an Ubuntu server, use the SSH path guide instead.
Step 1: Log in to RunClaw
Go to runclaw.run and log in. If you don't have an account yet, click Sign Up — it takes 30 seconds.
Step 2: Choose your cloud path
From onboarding, choose the cloud path that fits you:
Provision on Hetzner
The easiest cloud path. Best default if you want the quickest start.
Provision on Vultr
The alternative cloud path. Same RunClaw flow, different provider account.
If you are onboarding for the first time, the wizard starts with this choice. If you are already inside the dashboard, click Add Server and pick the same path there.
Step 3: Pick your agent
Pick your agent
RunClaw supports three agent types. Choose the one that fits your use case:
OpenClaw
A messaging-first AI agent. Connects to Telegram, Discord, WhatsApp, and more. Great for building AI assistants that communicate through chat platforms.
Agent Zero
An autonomous coding and research agent. Can browse the web, write code, and execute tasks on your server. Ideal for developers and power users.
Goose
A general-purpose AI agent for a wide range of automation tasks. Good for experimentation and exploration.
Not sure which to pick? Start with OpenClaw if you want a chat assistant, or Agent Zero if you want a coding/research agent. You can deploy multiple agents on different servers.
Choose a server size
Pick a starter size that matches the workload. The exact plan names differ by provider, but the same sizing logic applies:
| Path | Starter size | Good for |
|---|---|---|
| Hetzner | CX22 (2 vCPU / 4 GB) | Single agent, light usage |
| Vultr | vc2-2c-4gb (2 vCPU / 4 GB) | Single agent, light usage |
Start small. A 2 vCPU / 4 GB server handles most workloads well. You can always choose a larger size if you expect heavier automation or more tools.
Infrastructure charges are separate from RunClaw. Hetzner or Vultr bills you directly each month.
Add your provider credentials
Enter the API credential for the provider you chose:
- Hetzner: paste the API token from your Hetzner project
- Vultr: paste the API key from your Vultr account settings
RunClaw uses that credential to create the new server inside your provider account.
Step 4: Watch it deploy
After you click Deploy, here's what happens:
- RunClaw creates a new VPS in your Hetzner or Vultr account
- RunClaw sets up DNS so your agent gets a URL (
{slug}.runclaw.run) - Cloud-init installs everything on the server: Docker, Caddy (reverse proxy), your agent, and a management sidecar
You'll see a progress indicator on your dashboard. The whole process takes about 2 minutes.
Step 5: Access your agent
Once deployment completes, your agent is live at:
https://{slug}.runclaw.runThe slug is a short identifier shown on your dashboard. Click Open My Agent to go directly to your agent's interface.
Your agent needs an LLM key before it can respond. It's deployed and running, but without an AI provider key, it has no model to generate responses. See Configure LLM Keys for the next step.
What you just got
- A dedicated cloud VPS in your own provider account
- Full root SSH access (your SSH key is added during setup)
- Automatic TLS via Let's Encrypt (HTTPS works immediately)
- Real-time monitoring on your RunClaw dashboard (CPU, memory, disk, network)
- One-click updates when new agent versions are released
- Access gate — your agent is protected by a token so only you can access it
What is the access gate?
When you visit your agent's URL, you'll see a gate page asking for an access token. This token was shown in the setup wizard and is also available on your dashboard.
The gate ensures only you can access your agent. When you enter the token, it is validated in your browser using SHA-256 hashing against an embedded hash -- the plaintext token is not sent to RunClaw during validation.
During initial provisioning, the access gate token is sent to RunClaw so it can be injected into your server's setup script. After that, gate validation happens client-side.
After entering the token once, a cookie is set and you won't be asked again on that device.
Next: Configure LLM Keys