The OpenClaw Hardening Guide Nobody Wants to Write
Here's every step to harden OpenClaw for production.
Fair warning: there are 23 of them.
Most guides hand-wave through security. "Make sure to secure your instance," then move on to the fun stuff.
This isn't that guide. This is the actual checklist. Every step. No shortcuts.
If you get through all 23 and implement them, your OpenClaw will be production-grade. If you look at this list and think "no chance," there's a faster option at the end.
<a href="/checkout?plan=starter&utm_source=google&utm_medium=seo&utm_campaign=blog-openclaw-hardening-guide&utm_content=cta-top" data-umami-event="blog-cta-openclaw-hardening-guide-top">Or skip all 23 steps. Deploy securely in 60 seconds →</a>
What Is OpenClaw Hardening?
OpenClaw hardening is the process of securing a self-hosted OpenClaw deployment for production use. It covers network isolation, API key encryption, runtime sandboxing, audit logging, and ongoing maintenance. A fully hardened instance requires 23 configurations across 5 phases. Not sure where you stand now? Take the 3-minute security audit first.
Phase 1: Network (5 Steps)
Step 1: Bind to Localhost
Never expose OpenClaw directly to the internet. Bind it to 127.0.0.1.
# docker-compose.yml
ports:
- "127.0.0.1:3000:3000"
If your OpenClaw is on 0.0.0.0:3000, stop reading and fix this first.
Step 2: Reverse Proxy with Auth
Put NGINX or Caddy in front of OpenClaw. Add authentication at the proxy layer.
server {
listen 443 ssl;
server_name openclaw.yourdomain.com;
# SSL termination
ssl_certificate /etc/letsencrypt/live/openclaw.yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/openclaw.yourdomain.com/privkey.pem;
# Auth (basic auth at minimum, OAuth2 proxy preferred)
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Basic auth is the minimum. OAuth2 Proxy or Authelia is better.
Step 3: TLS Everywhere
No plain HTTP. Ever. Use Let's Encrypt with auto-renewal.
certbot --nginx -d openclaw.yourdomain.com
Add HSTS headers. Force HTTPS redirects.
Step 4: Egress Firewall Rules
Your agent should only reach domains you approve. Block everything else. Read our egress control deep-dive for the full picture.
# Allow only specific outbound destinations
iptables -A OUTPUT -d api.anthropic.com -j ACCEPT
iptables -A OUTPUT -d api.openai.com -j ACCEPT
iptables -A OUTPUT -j DROP # Block everything else
This is simplified. In practice, you need DNS resolution rules, established connection tracking, and careful testing. One wrong rule and your agent goes silent.
Step 5: Host Firewall
Lock down the server itself. Allow SSH, HTTPS, and nothing else inbound.
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 443/tcp
ufw enable
Check with ufw status. Then check again.
Phase 2: Auth & Secrets (5 Steps)
Step 6: Strong Auth Tokens
Generate 256-bit random tokens. Not passwords. Not "admin123."
openssl rand -hex 32
Use this as your gateway auth token. Rotate it quarterly.
Step 7: Encrypt API Keys at Rest
Your Anthropic and OpenAI keys should never touch disk in plaintext.
Options:
- HashiCorp Vault. Best. Also the most complex to set up.
- AWS Secrets Manager. Good if you're already on AWS.
- age encryption. Simple. Local.
age -e -r <public-key> < .env > .env.age
Whichever you choose, the keys in your .env file should be ciphertext, not cleartext.
Step 8: Secret Rotation Schedule
Set a calendar reminder. Rotate API keys every 90 days.
Sounds tedious? It is. But a compromised key with no rotation is a permanent breach. Our key rotation guide covers the full process.
Document which keys exist, where they're used, and when they were last rotated.
Step 9: Environment Isolation
Never share environment variables between production and development. Use separate keys, separate databases, separate everything.
.env.production # Production keys (encrypted)
.env.development # Dev keys (can be plaintext, lower risk)
.env.test # Test keys (mock or sandbox)
Step 10: No Secrets in Version Control
Add .env* to .gitignore. Check your git history. If a key was ever committed, it's compromised. Rotate it.
# Check if secrets were ever committed
git log --all --full-history -- .env
git log --all --full-history -- "*.pem"
Phase 3: Runtime (5 Steps)
Step 11: Sandbox Execution
Run OpenClaw in a container with no host access.
# docker-compose.yml
services:
openclaw:
security_opt:
- no-new-privileges:true
read_only: true
tmpfs:
- /tmp
cap_drop:
- ALL
Drop all Linux capabilities. Mount filesystem as read-only. No privilege escalation.
Step 12: Human Approval Workflows
High-risk actions should require human sign-off before execution.
This means building a queue system:
- Agent requests permission for a high-risk action
- Request goes to a notification channel (Slack, email, webhook)
- Human approves or denies
- Agent proceeds or stops
Building this from scratch takes days. Most people skip it. Most people regret skipping it. Learn about approval workflows for agents.
Step 13: Permission Controls
Don't give your agent access to everything. Define what it can and can't do. Our agent permissions guide covers this in detail.
- Which APIs can it call?
- Which file paths can it read?
- Can it execute shell commands? (Probably not.)
- Can it send emails? (Only with approval?)
Document every permission. Review quarterly.
Step 14: Kill Switch
Build an emergency stop that works in one action. Not "SSH in and find the container." See why kill switches are non-negotiable.
Options:
- API endpoint that stops the agent process
- Dashboard button that kills the container
- Monitoring alert that auto-stops on anomalous behavior
Test it monthly. A kill switch you've never tested isn't a kill switch.
Step 15: Update Strategy
OpenClaw releases patches. Some are security fixes. You need a plan:
- Watch the OpenClaw GitHub for releases
- Read changelogs for security patches
- Test updates in staging first
- Apply to production within 48 hours for critical fixes
Don't auto-update production. Don't ignore updates for months either. See what happens when you don't update.
<a href="/checkout?plan=starter&utm_source=google&utm_medium=seo&utm_campaign=blog-openclaw-hardening-guide&utm_content=cta-mid" data-umami-event="blog-cta-openclaw-hardening-guide-mid">Tired yet? We're on step 15 of 23. Or skip all of them →</a>
Phase 4: Monitoring (4 Steps)
Step 16: Structured Audit Logging
Log every agent action in a structured, searchable format. Our audit logging guide covers the full implementation.
{
"timestamp": "2026-02-16T14:30:00Z",
"agent_id": "agent-abc123",
"action": "api_call",
"target": "api.anthropic.com",
"tokens_used": 1500,
"cost_usd": 0.045,
"status": "success"
}
Ship logs to a centralized system. Not just stdout.
Step 17: Alerting
Set up alerts for:
- Agent errors above threshold
- Unusual API spend (>2x normal)
- Failed auth attempts
- Outbound connections to non-allowlisted domains
PagerDuty, OpsGenie, or even a Slack webhook. Something that wakes you up.
Step 18: Log Retention
How long do you keep logs? The answer depends on your compliance requirements:
- SOC 2: 1 year minimum
- GDPR: As short as possible (but you still need incident logs)
- HIPAA: 6 years
- Your auditor: Whatever they say
Default to 365 days. Store in an append-only system. Don't let anyone delete audit logs.
Step 19: Log Export
Your logs need to go somewhere queryable. Options:
- Elasticsearch + Kibana
- Grafana Loki
- Datadog
- Splunk
Pick one. Configure it. Check it more than once a quarter.
Phase 5: Ongoing (4 Steps)
Step 20: Patch Management
Subscribe to OpenClaw security advisories. Check dependencies weekly. Apply patches promptly.
# Check for outdated dependencies
npm audit
docker pull openclaw/openclaw:latest --dry-run
Step 21: Access Reviews
Quarterly, review:
- Who has SSH access to the server?
- Who knows the gateway auth token?
- Which API keys are still active?
- Are there any orphaned accounts?
Remove access for anyone who doesn't need it. Every quarter. No exceptions.
Step 22: Incident Response Plan
Write down what happens when things go wrong:
- Detection. How do you know something is wrong?
- Containment. Kill switch. Revoke keys. Isolate the server.
- Investigation. What happened? Check audit logs.
- Recovery. Rotate keys. Patch the vulnerability. Restore from backup.
- Post-mortem. What failed? How do you prevent it next time?
If this plan doesn't exist, your incident response is "panic." That's not a plan.
Step 23: Documentation
Document everything:
- Architecture diagram
- Security controls and where they're configured
- Key rotation schedule
- Access list
- Incident response plan
- Recovery procedures
If you get hit by a bus, can someone else maintain this? If not, your security has a bus factor of one.
The Scorecard
Count how many of these 23 steps you've completed:
- 20-23: Your OpenClaw is production-grade. You've invested serious time.
- 15-19: Good foundation. Gaps remain. Fix them before an incident forces you to.
- 10-14: Significant exposure. You're one bad day away from a breach.
- Below 10: Your OpenClaw is a liability. Stop adding features and start hardening.
Or: 60 Seconds with Clawctl
Every step on this list? Already done.
- Key encryption → AES-256, automatic
- Audit logging → Built-in, searchable, exportable
- Human approvals → One toggle
- Egress controls → Domain allowlist
- Kill switch → One button
- Sandboxing → Container isolation by default
- Updates → We handle it
- Monitoring → Included
- Compliance → SOC 2 ready
You just read a 23-step hardening guide. Or you could have been live 9 minutes ago. See how Clawctl compares to every alternative in our hosting provider comparison.
<a href="/checkout?plan=starter&utm_source=google&utm_medium=seo&utm_campaign=blog-openclaw-hardening-guide&utm_content=cta-bottom" data-umami-event="blog-cta-openclaw-hardening-guide-bottom">Skip all 23 steps. Deploy securely in 60 seconds →</a>