If you are committed to self-hosting your OpenClaw assistant, you are entering the world of system administration. It is a rewarding path, but it is not a hands-off one. To run an assistant that has access to your private data, your server must be hardened.
This checklist covers the essential steps for a professional-grade secure deployment. If you can't say "yes" to every item, your assistant is exposed.
1. Firewall Management (UFW)
Never leave ports open by default. You should explicitly allow only the traffic your assistant needs.
- The Command:
sudo ufw default deny incoming && sudo ufw default allow outgoing - The Specifics: Allow only port 22 (for SSH) and whatever ports your assistant uses (e.g., 443 for SSL).
2. SSH Hardening
Passwords are not enough. Use SSH keys.
- The Checklist: Disable password authentication, change the default SSH port, and disable root login.
- Config: In
/etc/ssh/sshd_config, ensurePasswordAuthentication noandPermitRootLogin no.
3. Intrusion Detection (fail2ban)
Bots are constantly scanning your server. fail2ban detects these attempts and automatically blocks them after a set number of failed logins.
- The Command:
sudo apt install fail2ban - Action: Configure the SSH jail to protect your server.
4. Automatic Updates
Unpatched systems are the primary vector for attacks.
- The Command:
sudo apt install unattended-upgrades - Configuration: Enable auto-updates for security packages in
/etc/apt/apt.conf.d/50unattended-upgrades.
5. SSL/TLS (Let's Encrypt)
Encrypting your data in transit is non-negotiable.
- The Tool: Use
certbotto manage your Let's Encrypt certificates. - Maintenance: Ensure that the automatic renewal cron job is running.
6. API Key Encryption
Never store keys in plain text inside your .env or config files.
- The Approach: Use a secret management tool or encrypted environment variables that are loaded into memory at runtime and not written to disk.
7. File Permissions
Only the service user should have access to the files it needs.
- Action: Audit your files. Ensure that configuration files with keys are owned by the service user and have
600permissions.
8. Monitoring and Alerting
If your assistant goes down or someone tries to access your server, you need to know immediately.
- The Stack: Set up a simple monitoring tool (like Uptime Kuma) and an alerting system (via email or Telegram) to notify you of downtime or failed login attempts.
9. Off-Site Backup Strategy
Backups stored on the same server as the data are not backups—they are a single point of failure.
- The Rule: Encrypt your backups and store them on a separate physical or cloud infrastructure.
- Validation: Test your restoration process at least once a month.
10. Rate Limiting
Prevent your services from being overwhelmed or abused.
- Action: Configure rate limiting at the reverse proxy level (e.g., Nginx) to protect your API endpoints from being hammered.
The Reality Check
This checklist isn't a one-time "set it and forget it" task. To implement these 10 points correctly, expect to spend at least 8-12 hours of initial setup. More importantly, maintaining this posture requires weekly check-ins to verify your backups, review logs, and audit your security.
If that sounds like a project you want to take on, follow the steps above. You'll learn a lot about security and infrastructure.
But if you want a private, secure, always-on AI assistant without the 12-hour setup and the weekly maintenance, then let KanaHost do it for you. We ship every server pre-hardened with this entire checklist.
You focus on the AI. We'll focus on the security.