Pre-deployment checklist
OpenClaw self-hosted setup: what you need before you deploy
Prepare your VPS access, model API key and Telegram bot for OpenClaw with ClawKickstart. Learn what the installer handles and how to verify a working agent.
Before deploying OpenClaw through ClawKickstart, prepare three things: a server path, access to an AI model provider, and the messaging channel you want to use. You do not need to buy a domain for the guided setup. This checklist follows the ClawKickstart journey so you can distinguish what you must supply from what the installer prepares.
Choose your server path first. For a new Hetzner VPS, create a Hetzner Cloud account and project, then generate a Read & Write API token in that project’s Security area. In ClawKickstart, open Create Instance, choose Hetzner Cloud, paste the token and select Verify token before choosing a server. Hetzner bills the server to your own cloud account.
- New Hetzner server: have your project API token ready and choose a location and server size in the dashboard.
- Existing VPS: have the public IP address, SSH username and SSH port ready, and follow the dashboard’s SSH-key instructions.
- Use a server you control. Check access before deploying, especially if the host has a provider firewall or custom SSH settings.
- Keep the server separate from unrelated production applications where possible. The installer changes packages, firewall rules and the agent runtime.
For an existing VPS, the current OpenClaw bootstrap is Ubuntu-focused: its Docker installation uses the Ubuntu package repository. Do not assume that every Linux distribution is interchangeable. Check compatibility before using Debian or another distribution, and back up an existing server before running a bootstrap on it.
Server size depends on the work you ask the agent to do. The VPS runs the gateway and tools, while an external model provider handles inference when you configure a hosted model API. Browser automation, large downloads and concurrent tasks can require more memory and storage than light messaging. Avoid treating a single CPU/RAM figure as a universal OpenClaw minimum; choose capacity for your workload and monitor it after deployment.
- Allow room for the Docker image, updates, logs and agent-generated files, not just the initial installation.
- Check free disk space and available memory on an existing VPS before starting.
- Increase capacity if your tasks repeatedly exhaust memory or disk; a running gateway alone does not prove every workload will fit.
- If you plan to run a model locally, assess that model’s hardware requirements separately from this hosted-API setup.
Prepare your model credentials before hatching the agent. Choose the provider and exact model reference offered by your provider, then enter its API key in Agent Setup. The model API bill is separate from both the VPS bill and the one-time ClawKickstart setup purchase. Confirm the provider account has billing or credits enabled and that the key can access your selected model.
For Telegram, create your bot through BotFather and keep its bot token available for the messaging step. After hatch finishes, send a message to the bot and confirm that it replies. When you reconfigure an existing agent, the dashboard does not display the stored Telegram token: enter a token when you intend to change Telegram settings. Leaving that field blank preserves existing Telegram configuration.
Understand the network boundary before changing firewall rules. ClawKickstart needs SSH access to provision and configure the VPS, and the server needs outbound access to download software and contact your model and messaging providers. Use your configured SSH port, which may differ from port 22. Check both the provider firewall and the host firewall if SSH connections time out.
The current OpenClaw installer allows inbound ports 80 and 443 in its host firewall, but this does not mean it creates a public website or automatically configures a domain and TLS certificate. It restricts the published gateway ports to localhost. For direct gateway administration, plan private access such as an SSH tunnel rather than opening the gateway to the internet. A public domain and HTTPS endpoint are a separate configuration decision.
Follow the dashboard stages in order: choose your setup, create the instance, wait for provisioning to complete, then enter the provider, model and messaging settings and hatch the agent. Treat provisioning and hatch as separate checks. A server can be provisioned successfully while a model key, model reference or messaging configuration still prevents the agent from replying.
- Confirm that provisioning reaches its completed state before starting Agent Setup.
- Confirm hatch succeeds, then send a real test message through your configured messaging channel.
- If the agent does not reply, open Diagnostics and review gateway health, model configuration and messaging status.
- Before removing an instance, export anything you need and review the dashboard’s removal guidance. Dashboard removal, VPS deletion and optional Care billing have separate consequences.
Your final readiness check is a working conversation, not just an installed process. Keep access to your cloud account, model-provider account and recovery credentials so you can manage costs and recover the server later. Optional Care can add monitoring after deployment; it does not replace a successful first message or ownership of those accounts.