.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Getting ZeroClaw running is the easy part. Keeping it running reliably over weeks and months without babysitting it is where the actual work starts.
This guide covers the production fundamentals: systemd for process management, automated backups so you don't lose your assistant's memory to a disk failure, Prometheus metrics for monitoring, and the security settings you should configure before exposing anything to the network.
None of this is complicated individually. The value is in having it all set up from the start instead of scrambling to add it after something breaks at 2 AM on a Saturday.
systemd service configuration
ZeroClaw includes a built-in service installer:
zeroclaw service install
zeroclaw service startThis creates a systemd unit file that starts ZeroClaw on boot, restarts it on crash and logs output to the journal. For most setups, the defaults are fine. But if you want to customize the unit file (to set environment variables, change resource limits, or add dependencies), you can find it at /etc/systemd/system/zeroclaw.service after installation.
Useful systemd commands for day-to-day management:
zeroclaw service status # Quick health check
zeroclaw service restart # Apply config changes
journalctl -u zeroclaw -f # Live log tail
journalctl -u zeroclaw --since "1 hour ago" # Recent logsIf you need ZeroClaw to start after another service (like Docker or Ollama), add a dependency in the unit file:
[Unit]
After=docker.service ollama.serviceThen reload systemd:
systemctl daemon-reload
zeroclaw service restartAutomated backups
ZeroClaw's state lives in ~/.zeroclaw/. The two files you absolutely cannot afford to lose are config.toml (your entire configuration including provider keys, channel bindings and agent settings) and memory.db (the SQLite database containing all conversation history and vector embeddings). Losing config.toml is annoying. Losing memory.db means your assistant forgets everything it's ever learned about you.
Set up a daily backup with a cron job:
mkdir -p /root/backups/zeroclaw
cat > /etc/cron.d/zeroclaw-backup << 'EOF'
0 3 * * * root zeroclaw service stop && \
cp ~/.zeroclaw/config.toml ~/.zeroclaw/memory.db /root/backups/zeroclaw/ && \
tar czf /root/backups/zeroclaw/zeroclaw-$(date +\%Y\%m\%d).tar.gz \
-C /root/backups/zeroclaw config.toml memory.db && \
rm /root/backups/zeroclaw/config.toml /root/backups/zeroclaw/memory.db && \
zeroclaw service start
EOFThis stops the service briefly to ensure a clean SQLite copy, archives the files, then restarts. The downtime is a few seconds at 3 AM, which is an acceptable tradeoff for data consistency. If even a few seconds of downtime bothers you, SQLite's WAL mode means you can usually copy the database while it's running without corruption, but stopping the service is the safer option.
Add a retention policy to avoid filling your disk:
cat >> /etc/cron.d/zeroclaw-backup << 'EOF'
0 4 * * * root find /root/backups/zeroclaw/ -name "zeroclaw-*.tar.gz" -mtime +30 -delete
EOFThis keeps 30 days of backups. For offsite backup, rsync the backup directory to a separate server or an object storage service. If you want a comparison of backup strategies for self-hosted AI setups, the OpenClaw backup guide covers broader concepts that apply to any agent framework.
Prometheus metrics and monitoring
ZeroClaw exposes Prometheus-compatible metrics at the gateway's /metrics endpoint. If the gateway is running on the default port:
curl http://127.0.0.1:42617/metricsYou'll see metrics like zeroclaw_requests_total (broken down by channel and status) and zeroclaw_request_duration_seconds. These tell you how many messages your bot is processing, how fast it's responding and where failures are happening.
To collect these metrics over time, set up Prometheus to scrape the endpoint. Add a job to your Prometheus config:
scrape_configs:
- job_name: 'zeroclaw'
static_configs:
- targets: ['127.0.0.1:42617']Pair it with Grafana for dashboards. The ZeroClaw documentation includes a Promtail and Loki configuration for log aggregation alongside metrics, which is worth setting up if you're running ZeroClaw as a serious production service. Our OpenClaw monitoring tutorial covers Prometheus and Grafana setup on a VPS from scratch if you haven't deployed them before.
Security hardening
ZeroClaw's defaults are reasonably secure. The gateway binds to localhost only, which means it's not reachable from the internet. The config file gets 0600 permissions. Workspace paths are scoped to a specific directory. But there are additional steps worth taking for a production setup.
Firewall rules — If you're running any services that listen on public ports, configure UFW or iptables to only allow SSH and whatever else you explicitly need:
ufw allow ssh
ufw enable
ufw statusDon't open port 42617 to the public internet. If you need remote access to the ZeroClaw gateway or dashboard, use an SSH tunnel instead. This is the single most important security step and it costs nothing.
Non-root user — Running ZeroClaw as root works but isn't ideal for production. Create a dedicated user:
useradd -m -s /bin/bash zeroclaw
cp -r /root/.zeroclaw /home/zeroclaw/.zeroclaw
chown -R zeroclaw:zeroclaw /home/zeroclaw/.zeroclawUpdate the systemd unit file to run as this user instead of root. This limits the blast radius if something goes wrong.
Tunnel providers — If you need external services to reach your gateway (for webhook-based channel integrations), ZeroClaw supports tunnel providers including Cloudflare Tunnel, Tailscale and ngrok. These are safer than opening ports directly because the traffic is encrypted and routed through the tunnel service rather than hitting your VPS IP directly.
Keep ZeroClaw updated — New releases include security patches. The update process is straightforward:
curl -LsSf https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/master/install.sh | bash
zeroclaw doctorAlways run zeroclaw doctor after updating. And always check for known issues with the new version before updating a production system.
Health checks and alerting
For basic uptime monitoring, the gateway's health endpoint is your friend:
curl -sf http://127.0.0.1:42617/health || echo "ZeroClaw is down"You can wrap this in a cron job that sends you a notification (via a separate Telegram bot, email, or any alerting service) when the health check fails. ZeroClaw also has a zeroclaw self-test command (added in v0.5.0) that runs a more thorough diagnostic than the health endpoint:
zeroclaw self-test --quick # Fast check
zeroclaw self-test # Full diagnosticThe full self-test verifies provider connectivity, channel health, memory system integrity and tool availability. Run it periodically (weekly via cron is a reasonable cadence) to catch problems before they affect your users.
