GitHub 100k Star Hit! OpenClaw Redefines "Personal AI": Beyond Chatting, It Controls Your WeChat and Computer.

With its breakthrough "computer operation" and "browser operation" capabilities, OpenClaw has quickly become a phenomenal project in the AI Agent field, marking the shift of AI from mere text generation to substantial system control and task execution. However, this leap leads to an exponential increase in architectural complexity: OpenClaw is not a single script tool but a sophisticated system integrating NodeJS, Swift, Kotlin, and other runtime environments, demanding high environmental consistency in server deployment tutorials. For developers building private intelligent assistants, a lack of clear architectural planning risks trapping them in a quagmire of deployment error troubleshooting amidst complex dependency chains, preventing successful project implementation. Building a high-availability, maintainable AI agent requires abandoning fragile source compilation in favor of an industrial-grade Docker container deployment solution. This approach solves cross-language compatibility issues through standardized image encapsulation and enables rapid environment replication and migration via one-click deployment scripts, offering the most robust "happy path" for build from scratch tutorials. This guide will analyze key selection logic for cloud server environment configuration and detail how to mask underlying operating system differences through a standardized automated deployment process, ensuring OpenClaw runs as stably as commercial software. By mastering this production-grade deployment methodology, developers can avoid tedious debugging and establish a comprehensive project launch and maintenance mechanism, truly unlocking OpenClaw's core value in controlling WeChat, office automation, and complex task processing, transforming it into a powerful digital employee at your command.

Core Decisions Before Deployment: Environment Selection and Solution Comparison

As an AI Agent capable of "Computer Use" and "Browser Use," OpenClaw's architectural complexity far exceeds that of a typical chatbot. It is not just a simple Python script but a complex system integrating multiple language environments such as NodeJS, Swift, and Kotlin. Therefore, before executing any installation commands, selecting the correct environment is key to ensuring the long-term stable operation of the system.

1. Hardware Resource Requirements Assessment

OpenClaw's resource consumption mainly depends on whether you run large models locally and the Agent's concurrent task volume. For most users connecting to large models via API (such as Claude 3.5 Sonnet or OpenAI GPT-4o), the server mainly handles logic processing and environment interaction, but even so, the memory usage of Java and Node.js runtimes cannot be ignored.

• Recommended Configuration (Production/Long-term Run):
• • CPU: 2 vCPU or more (handling concurrent WebSocket connections and local automation tasks).
  • RAM: 4GB RAM (Strongly recommended). Although 2GB is barely enough to start, it is very easy to trigger OOM (Out of Memory) when processing complex task chains or compiling dependencies.
  • Disk: 40GB+ SSD (Docker images and log files will grow over time).
• Minimum Configuration (For Testing Only):
• • CPU: 1 vCPU
  • RAM: 2GB (Must configure at least 2GB of Swap partition, otherwise the process will be killed by the Linux kernel's OOM Killer).

Expert Advice: If you plan to let OpenClaw perform local browser automation tasks (Browser Use), memory requirements will increase significantly; it is recommended to start directly with 4GB.

2. Operating System Selection: Why Ubuntu is the First Choice

Although OpenClaw theoretically supports multiple Linux distributions, Ubuntu 20.04 LTS or Ubuntu 22.04 LTS is the best choice when deploying on the server side.

• Kernel Compatibility: Some of OpenClaw's underlying capabilities rely on newer Linux kernel features. Old system kernels like CentOS 7 are too low in version, which can easily lead to Docker container network anomalies or file system mounting failures.
• Clean Environment: It is recommended to use the "clean version" system image provided by the service provider and avoid using images with pre-installed Baota panels or LAMP stacks. Pre-installed software often occupies key ports such as 80/443 or 18789, leading to OpenClaw startup conflicts.

3. Deployment Solution Comparison: Docker vs. Source Code Compilation

This is the most important decision before deployment. According to community feedback and technical document analysis, OpenClaw's source code deployment involves an extremely tedious cross-language dependency chain.

Here is a deep comparison of the two mainstream solutions:

As related tutorials point out, manually configuring the environment is very easy to fall into "Dependency Hell," especially since configuring Swift and Kotlin environments on a standard Linux VPS is extremely time-consuming. Therefore, unless you have core requirements for secondary development, the Docker solution is currently the only recommended production-grade deployment path. It can shield underlying system differences and ensure your OpenClaw runs as stably as the official demo.

Option 1: Docker Containerized One-Click Deployment (Recommended)

For the vast majority of users, using Docker containerized deployment for OpenClaw is currently the safest and most efficient "Happy Path". As a modern AI Agent system, OpenClaw's backend architecture involves a Node.js environment, vector database connections, and complex API gateway configurations. If source code compilation and installation are adopted, users can easily fall into "Dependency Hell" triggered by Python version incompatibilities or dependency package conflicts.

In contrast, the Docker solution encapsulates the entire runtime environment within a standard image, ensuring the consistency of "Build once, run anywhere". Whether your server is running Ubuntu, Debian, or CentOS, containerized deployment shields you from underlying system differences, allowing you to skip tedious compilation steps and dive directly into configuring and using core features.

In this chapter, we will guide you through the deployment using a standardized process. The entire process is broken down into three clear stages: first is the preparation of the basic environment, ensuring the host machine has the capability to run containers; second is the generation and adjustment of configuration files, which is the key to making the AI understand your instructions; and finally, the startup and verification of the service, ensuring all components work together. By following this verified process, you can possess a fully private and controllable AI assistant within minutes.

Step 1: Basic Environment Setup and Docker Installation

Before starting the deployment of OpenClaw, you must ensure the host machine has a clean and modern container runtime environment. Although many cloud providers offer images with Docker pre-installed, to avoid compatibility issues caused by old versions (especially regarding Docker Compose V2 support), it is recommended to manually execute the following standardized installation process on a clean Ubuntu 20.04/22.04 LTS or Debian 10+ system.

1. Install Docker Engine and Docker Compose

We will use the installation script provided by Docker officially or standard software repositories, which is the most robust solution. Please execute the following commands in the server terminal in order:

Update the system and install necessary tools:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg

One-click installation of Docker (Recommended for rapid deployment):
The convenience script provided by the official team can automatically detect the system version and configure stable sources, making it suitable for most deployment scenarios.

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

Note: This script will automatically install docker-ce, docker-ce-cli, containerd.io, and the latest docker-compose-plugin.

2. Resolve "Permission Denied" Issues

By default, the Docker daemon binds to a Unix socket rather than a TCP port, and that socket belongs to the root user. If you run Docker commands directly as a non-root user (such as ubuntu or admin), you will typically encounter a permission denied error.

Be sure to execute the following commands to add the current user to the Docker user group to avoid frequent use of sudo later:

# Create the docker group (if it already exists, it will prompt, can be ignored)
sudo groupadd docker

# Add the current user to the docker group
sudo usermod -aG docker $USER

# Activate changes (or directly disconnect SSH and reconnect)
newgrp docker

3. Verify the Installation Environment

After the environment setup is complete, you must verify that the Docker Engine and Compose plugin are working correctly. OpenClaw's orchestration files rely on newer Compose features, so version checking is crucial.

Execute the following commands:

docker --version
docker compose version

Expected Output Example:

Docker version 24.0.x (or higher), build ...
Docker Compose version v2.20.x (or higher)

If you can see the above version number output, it means the basic environment is ready. If you encounter docker-compose: command not found, please check if the old Python version of docker-compose is installed. It is recommended to remove it and ensure you use the command docker compose (without a hyphen in between) to invoke the official plugin.

Tip: For domestic servers (such as Tencent Cloud, Alibaba Cloud), if the download speed is too slow, you can refer to relevant tutorials to configure domestic mirror acceleration sources (such as Tencent Cloud mirror source) to improve image pulling efficiency.

Step 2: Pulling the Image and Compose Configuration

To completely avoid the "dependency hell" potentially encountered when manually installing multi-language environments like NodeJS, Swift, and Kotlin (as pointed out by Chi Zhe Gong Liang in the deployment tutorial, manual configuration is extremely tedious), we recommend using Docker Compose for containerized deployment. This method encapsulates all runtime environments required by OpenClaw into a single image, achieving true "out-of-the-box" usability.

Please create a deployment directory on your server (e.g., ~/openclaw) and create a new docker-compose.yml file inside it. Below is a standard configuration template optimized for production environments, in which we have pre-configured key data persistence parameters:

version: '3.8'

services:
  openclaw:
    # Use the official latest stable image
    image: openclaw/openclaw:latest
    containername: openclawcore
    restart: unless-stopped
    # Port mapping: Host port on the left, container port on the right
    ports:
      - "3000:3000"  # Web console port
      - "8080:8080"  # API interaction port

# Core configuration: Environment variables
    environment:
      - TZ=Asia/Shanghai
      # Basic model configuration (supports OpenAI, Moonshot, Claude, etc.)
      - LLMPROVIDER=openai 
      - LLMBASEURL=https://api.openai.com/v1
      - LLMAPIKEY=sk-your-api-key-here
      # WeChat/Feishu control switch (set to true to enable automated takeover)
      - ENABLEWECHATPUPPET=true
      - LOGLEVEL=info

# Data persistence: Prevent "amnesia" after restart
    volumes:
      # Map configuration files for easy manual fine-tuning later
      - ./config:/app/config
      # Map core database to save conversation history and skill memories
      - ./data:/app/data
      # Map log directory for troubleshooting startup errors
      - ./logs:/app/logs

# Resource limits (optional, prevents AI processes from consuming too much memory and freezing the server)
    deploy:
      resources:
        limits:
          memory: 4G

Analysis of Key Configuration Items

1. Data Persistence (Volumes):
   The most important part of the configuration is the volumes mapping. During operation, OpenClaw generates a large number of session indexes and Skill Configs. If /app/data is not mapped to the host, all your "tuning" data and memories will be lost once the container restarts or the image is updated. Be sure to ensure that the host directory ./data has read/write permissions.
2. Model Integration (Environment):
   Although OpenClaw provides an interactive onboard command-line tool to guide configuration, injecting the LLMAPIKEY directly via environment variables is a more efficient approach in Docker mode. If you are using domestic models (such as Kimi/Moonshot), please ensure that LLMBASEURL is filled in correctly to avoid subsequent connection timeout issues.
3. Network Ports (Ports):
   The default exposed port 3000 is used to access the Web UI. If your server manages access via Nginx reverse proxy or cloud service firewalls, please ensure that this port is allowed in the security group, or modify the mapped port on the left side of ports as needed (e.g., "80:3000").

After creating the file, your deployment environment is ready. The next step is to start the service and perform a health check.

Step 3: Service Startup and Status Verification

Once the configuration files are ready, the next step is to officially launch the OpenClaw container service and confirm its running status. Although Docker greatly simplifies the deployment process, performing a strict health check upon the first startup is essential. This helps you quickly rule out common issues such as port conflicts or environment variable configuration errors.

1. Start the Container Service

In the directory containing docker-compose.yml, execute the following command to start the service in "Detached Mode". This ensures that OpenClaw continues running in the background, even if you close the SSH terminal window.

docker-compose up -d

The system will automatically pull the image (if not yet downloaded) and create the container. When the terminal displays a Started or Running status, it indicates that the container has been successfully created.

2. Running Status Checklist

Container startup does not necessarily mean the service is available. It is recommended to follow the "Three-Step Method" below to verify if OpenClaw has truly entered a healthy working state:

A. Check Container Status
Execute docker-compose ps or docker ps to view the container list.

• Normal Status: The STATUS column shows Up x seconds or Up x minutes.
• Abnormal Status: If it shows Restarting (1) or Exited, it means the container is repeatedly crashing (Crash Loop), usually due to configuration file format errors or port occupation.

B. Real-time Log Diagnosis
This is the most accurate way to judge whether the service is ready. Execute the following command to view the real-time log stream:

docker-compose logs -f

• Healthy Startup Logs: You will see prompts like Server listening on port 3000, Database connected, or Ready to accept connections. This indicates that core processes have fully loaded.
• Watch for Error Signals: If keywords like ECONNREFUSED (connection refused), API Key missing, or Panic appear in the logs, please immediately press Ctrl+C to exit the log view and check if the environment variables in docker-compose.yml are filled in correctly.

C. Access the Web Interface
Enter http://<Server IP>:<Port> in the browser address bar (the default port is usually 3000, depending on your configuration in the Compose file).

• If you can see the OpenClaw login page or initialization wizard, congratulations, the service setup is successful.
• Note: For some cloud servers, if access is not possible, please be sure to check the cloud provider's console (such as Tencent Cloud or Alibaba Cloud security group settings) to ensure that the corresponding port (e.g., 3000) is open in the firewall rules.

Tip: Based on some users' deployment experience, you may need to run a configuration wizard inside the container after the first startup. If the page indicates it is not configured, you can use docker exec -it openclaw-container-name openclaw onboard to enter the interactive configuration mode. Please refer to the subsequent advanced configuration chapters for details.

Option 2: Source Compilation and Manual Setup (Advanced)

This option is suitable for advanced users who cannot use a Docker environment, need to perform secondary development on OpenClaw, or must deploy on specific non-containerized architectures (such as physical machines or legacy Linux distributions).

⚠️ WARNING: Source deployment requires users to have strong environment troubleshooting skills. OpenClaw involves multi-language runtimes (Node.js, Python, Go, and even Swift/Kotlin), and manual configuration can easily lead to "Dependency Hell." Please strictly adhere to version isolation principles.

1. Environment Dependencies and Version Isolation

To avoid polluting the host environment, it is strongly recommended to use version management tools (such as nvm, pyenv) to lock runtime versions. According to community feedback and Chizhegongliang's deployment experience, OpenClaw is very sensitive to runtime versions, and version mismatch is the primary reason for startup failures.

Recommended Baseline Environment:

Environment Isolation Example:

# 1. Use nvm to lock Node version
nvm install 18
nvm use 18

# 2. Create Python virtual environment
python3 -m venv venv
source venv/bin/activate

2. Source Code Acquisition and Build Process

Please execute the following steps in order; do not skip the dependency installation phase.

Step 1: Clone Repository

Obtain the official source code and checkout to the latest stable tag to avoid using unstable development branches.

git clone https://github.com/openclaw/openclaw.git
cd openclaw
# Recommended to checkout the latest Tag, for example:
# git checkout v1.2.0

Step 2: Install Mixed Dependencies

OpenClaw adopts a separated frontend-backend architecture, requiring dependencies to be installed separately.

# Install backend/core dependencies
pip install -r requirements.txt

# Install frontend/Node module dependencies
# Note: This step may trigger C++ extension compilation; please ensure gcc/g++ is installed on the system
npm install

Step 3: Compile and Build

Execute build commands to generate static resources and executable files.

# Build frontend resources
npm run build

# Compile backend service (if Go modules are included)
go build -o openclaw-server ./cmd/server

3. Initialization Configuration and Startup

Source deployment lacks Docker's automatic environment variable injection, so configuration files must be generated manually. OpenClaw provides an interactive configuration wizard, onboard, to guide users through API Key setup, model selection, and permission confirmation.

# Start configuration wizard
./openclaw-server onboard

During configuration, the system will ask whether to enable "Onboarding mode". According to relevant deployment tutorials, first-time users should select QuickStart mode to skip unnecessary complex settings and quickly complete the basic deployment.

Verify Installation:
After configuration is complete, use the following commands to start the service:

# Start service
npm start
# Or directly run the compiled binary file
./openclaw-server start

If the console outputs Server is running at http://localhost:3000 without error stacks, the environment setup is successful. If you encounter Module not found or Segmentation fault errors, please first check if node -v and python --version match the recommended baseline mentioned above.

Core Feature Configuration: WeChat Integration and Local Control

The reason OpenClaw has garnered high stars on GitHub lies in its ability to break the limitations of the "dialog box." Most AIs just chat with you, but OpenClaw, through a combination of Adapters and Capabilities, truly achieves "not just listening, but acting." This section will break down how to configure its two most core scenarios: issuing commands remotely via WeChat, and authorizing the AI to directly control the local computer.

1. WeChat Integration: Creating a Portable Command Terminal

OpenClaw's architecture allows connection to chat software via different Adapters. After integrating WeChat, your WeChat window becomes the AI's remote console; whether checking server status or triggering automation scripts, everything can be done via a single WeChat message.

Configuration Mechanism and Steps:

Usually, there are two mainstream integration methods, depending on the OpenClaw version you deploy and the middleware used (such as Wechaty or a specific Bridge):

1. Modify Configuration File (openclaw.json):
   In OpenClaw's core configuration file (usually located at ~/.openclaw/openclaw.json or in a Docker mapped volume), find the adapters field. You need to enable the WeChat adapter and fill in the corresponding protocol configuration.

    "adapters": {
      "wechat": {
        "enabled": true,
        "mode": "puppet", // or other bridge modes
        "allowList": ["YOURWXID"] // Security critical: only respond to commands from specific users
      }
    }

Note: Be sure to configure the allowList, otherwise your AI might respond to commands from others in group chats, causing security risks.

1. Scan Code Login and Callback Configuration:
   After starting the service, check the logs (docker logs openclaw or terminal output). The system will generate a QR code or login link. After scanning the code with WeChat, OpenClaw will obtain a login credential (Token). Some advanced configurations may require you to set a callback address (Webhook) to push messages received by WeChat to OpenClaw's processing port.

2. Local Control: Granting AI Permission to "Operate the Computer"

This is OpenClaw's most powerful and also most dangerous feature. Enabling "Computer Control" means the AI can execute Shell commands, read/write files, and even install software just like a human user.

Permissions and Isolation Strategies:

• Docker Deployment (Recommended, Security Restricted):
  By default, OpenClaw inside a Docker container can only "control" the environment inside the container. This is a natural sandbox protection. If you want it to handle host files (e.g., organizing the Downloads folder), you need to explicitly authorize it via Volume Mounting:

    # docker-compose.yml example
    volumes:
      - /Users/yourname/Downloads:/home/openclaw/downloads # Only expose the downloads directory
      - ./config:/root/.openclaw # Map configuration directory

This method follows the "principle of least privilege"; even if the AI goes crazy, it can only delete files within the mounted directories.

• Local Binary Run (High Power, High Risk):
  If you run the OpenClaw binary file directly on the host machine, it will inherit all permissions of the current user (excluding sudo permissions, unless you configure passwordless access). In this mode, the AI has the strongest capabilities and can call system-level APIs, but this also means a single line of erroneous code could accidentally delete important data. It is recommended to try this mode only on a virtual machine or a dedicated development machine.

3. Configuration Troubleshooting: Common Issues and Solutions

In the process of connecting WeChat and local control, environmental differences often lead to various errors. The following is a "Symptom-Solution" reference table for core configurations:

Expert Tip: When configuring the "Local Control" feature for the first time, it is recommended to first enable dry-run mode (if the version supports it) or explicitly limit it in the Prompt: "Before executing any command to delete or modify files, you must ask me first." This effectively prevents the AI from "doing bad things with good intentions."

Deployment Troubleshooting Guide (Troubleshooting)

In the actual deployment process of OpenClaw, due to operating system differences, network environment restrictions, and different dependency versions, encountering errors is the norm rather than the exception. Most tutorials usually only show the "Happy Path," but in a production environment, being able to quickly locate and resolve exceptions is the key to ensuring stable service operation. This section compiles the three most frequent "roadblocks" in OpenClaw deployment and provides deep troubleshooting ideas based on log analysis.

Core Log Analysis: The "Stethoscope" for Locating Problems

Before blindly attempting to restart the service, you first need to obtain the accurate error stack.

• Docker Deployment (Recommended):
  If the container fails to start, do not delete and rebuild it immediately. Use the following command to view real-time logs:

    docker logs -f openclaw --tail 100

Focus on lines in the log starting with Error, Exception, or Caused by.

• Local Source Startup:
  If running directly via Python or Node.js, please check the console output. If the service fails silently, it is recommended to redirect standard error output to a file for analysis:

    nohup python3 main.py > output.log 2>&1 &
    tail -f output.log

Common Error Cheat Sheet (Symptom -> Cause -> Fix)

The following table summarizes several categories of blocking issues with the highest proportion in community feedback:

Deep Dive: "Container Exits Immediately"

This is a problem that causes many beginners to break down: after executing docker run or docker-compose up -d, the container status shows Exited (0) or Exited (1) and cannot remain running.

1. Misconception about Foreground and Background Processes
The design principle of Docker containers is to "run a single foreground process." If OpenClaw's startup script exits after executing initialization commands (for example, using a background daemon command like systemctl start), the container will think the task is finished and automatically close.

• Troubleshooting: Check the CMD or ENTRYPOINT in the Dockerfile to ensure the main program (such as python app.py or npm start) is running in the foreground, not as a background service.

2. Configuration File Format Errors (YAML Hell)
OpenClaw relies on config.yaml or docker-compose.yml for parameter injection. YAML files are extremely sensitive to indentation.

• Symptom: ScannerError or mapping values are not allowed here appears in the logs.
• Solution: Use an online YAML validation tool to check the configuration file. Pay special attention to whether the API Key contains special characters; it is recommended to wrap the Key value in double quotes.

3. Out of Memory (OOM Killed - Exit Code 137)
If the container suddenly dies after running for a while with exit code 137, it is usually due to insufficient memory (OOM). OpenClaw's memory consumption can surge when processing long contexts or loading local vector libraries.

• Diagnosis: Use docker inspect [container_id] to check if State.OOMKilled is true.
• Solution:
• • If using Alibaba Cloud Lightweight Application Server, it is recommended to configure at least 4GB of memory or increase the Swap partition.
  • Add resource limits (deploy.resources.limits) in Docker Compose, but this only prevents the host from crashing; the root cause still needs to be resolved by upgrading the configuration or optimizing concurrency.

Long-term Maintenance: Updates, Backups, and Security Hardening

After successfully deploying OpenClaw, the real challenge lies in ensuring the long-term stable operation of the service. For an AI Agent that carries personal WeChat control rights and sensitive data, "Day 2 operations" (updates, backups, and security) are even more important than the initial deployment. Below is a standardized maintenance guide for production environments.

Smooth Update Workflow

OpenClaw is a rapidly iterating open-source project, so frequent updates are the norm. To avoid service interruptions caused by version updates, it is recommended to use a standard update process based on Docker Compose, rather than unstable code overwriting directly on the host machine.

Option A: Update based on Docker Image (Recommended for stable version users)
If you are using the officially released Docker image, the update process is the simplest and has the lowest risk:

# 1. Pull the latest image
docker compose pull

# 2. Recreate and start containers (only rebuilds services with updates)
docker compose up -d

# 3. Clean up old unused images to release disk space
docker image prune -f

Option B: Update based on Source Build (Suitable for trying the latest features)
If you need to use the latest features on GitHub, or have compiled the image yourself by referring to the community build guide, you need to update the code repository first and then rebuild:

cd ~/openclaw
# Pull the latest code and switch to the latest Tag
git pull
LATESTTAG=$(git tag --sort=-creatordate | head -1)
git checkout$LATESTTAG

# Rebuild the image and restart
docker compose build --no-cache
docker compose up -d

Note: Before performing a major version update, be sure to check the Breaking Changes description in the Release Notes.

Automated Backup Strategy

The core value of OpenClaw lies in its configuration data (Prompt settings, knowledge base indexes) and runtime data (chat history). Based on deployment experience, this data is usually mounted in the openclaw-docker/config and openclaw-docker/data directories.

Implementing the 3-2-1 Backup Rule
Do not rely on a single server snapshot. It is recommended to write a simple Shell script and use Crontab to achieve daily automatic backups:

#!/bin/bash
BACKUPDIR="/var/backups/openclaw"
DATADIR="/root/openclaw-docker"
DATE=$(date +
mkdir -p$BACKUPDIR

# Package configuration and data directories
tar -czf $BACKUPDIR/openclawbackup$DATE.tar.gz -C$DATADIR config data

# Keep backups for the last 7 days, delete expired files
find $BACKUPDIR -type f -name "*.tar.gz" -mtime +7 -exec rm {} \;

Add the above script to crontab -e and set it to execute every morning. For critical data, it is recommended to combine it with the cloud provider's automatic snapshot policy for full machine backup to deal with system-level failures.

Security Hardening Defense Line

Since OpenClaw has the ability to "control WeChat" and "execute computer commands," its security risk level is much higher than that of ordinary Web services. Once the management port is exposed, attackers may hijack your WeChat account via the API.

1. Strictly Forbid Exposed Ports, Configure Reverse Proxy
Never expose OpenClaw's backend ports (such as 9000 or 8080) directly to the public internet.

• Wrong Practice: Allowing port 9000 in the security group and accessing via http://IP:9000.
• Correct Practice: Use Nginx as a reverse proxy, only open ports 80/443, and configure SSL certificate encryption for communication. This not only hides the backend architecture but also prevents Man-in-the-Middle attacks from stealing API Keys.

2. Enable System-level Firewall (UFW)
Inside the server, strict restrictions on inbound traffic should be enforced via UFW (Uncomplicated Firewall), allowing only SSH and Web traffic:

# Deny all unnecessary inbound connections
ufw default deny incoming
# Allow SSH (adjust accordingly if port is modified)
ufw allow 22/tcp
# Allow HTTP/HTTPS
ufw allow 80/tcp
ufw allow 443/tcp
# Enable firewall
ufw enable

3. SSH Security Hardening
As the last line of defense for infrastructure, SSH security is crucial. It is recommended to disable password login and enable key authentication, which can effectively defend against brute force attacks targeting the root password. Hackers' automated scripts scan public IPs around the clock, and servers with weak passwords are often compromised within hours of going online.

Through the above "Update-Backup-Harden" trinity maintenance system, you can transform OpenClaw from a mere "toy" into a reliable "personal productivity foundation."