In the field of security testing, the pain points of traditional penetration testing are real: professional testers are scarce, services often cost tens of thousands of yuan, and the cycle is measured in weeks; meanwhile, common Static Application Security Testing (SAST) tools generate a massive number of false positives, leaving development teams numb with "crying wolf" scenarios, while the real problems are drowned out by noise.
The emergence of AI-driven dynamic security testing platforms like Strix precisely addresses this pain point. It doesn't rely on fixed vulnerability signature databases to "guess" risks, but directly utilizes the reasoning capabilities of Large Language Models (LLM), allowing the AI agent to think, experiment, and verify like a human hacker. This is not merely an upgrade in tool form, but a paradigm shift in security testing.
This article will guide you step-by-step through how to privately deploy Strix on a Hong Kong VPS, avoiding pitfalls not mentioned in the documentation, and truly getting this "AI penetration testing team" running on your server.
I. Re-understanding Strix: It's Not a Scanner, But an AI Hacking Team
Many people, when first encountering Strix, tend to categorize it with traditional scanners like AWVS and Nessus, which is a fundamental cognitive bias.
Traditional scanners operate on a "rule-based matching" logic—sending a payload and checking if the response packet contains specific characteristics. Strix's core is autonomous decision-making based on large-scale model inference. When you give it a target, multiple specialized intelligent agents within it activate: a reconnaissance agent draws the attack surface, an injection testing agent attempts to construct malformed data streams, and an authorization verification agent simulates unauthorized behavior.
More importantly, these agents don't operate independently. When the reconnaissance agent discovers a suspicious API endpoint, it immediately notifies the authorization testing agent to follow up; if it finds an input point that might be exploitable, the injection testing agent attempts to construct a specific attack chain. The entire process resembles a real penetration testing team working, only at a completely different speed.
Strix's vulnerability verification logic also differs from traditional tools. It won't tell you "this page might be vulnerable to SQL injection," but rather it will actually execute an attack. If successful, it will include complete, reproducible proof-of-concept code in the report. This means that every reported vulnerability is verified in practice, not just a probabilistic guess.
From a technical architecture perspective, Strix comes with a complete set of hacking tools: HTTP proxy, browser automation environment, terminal shell, Python runtime, etc. These tools are not simple command-line calls, but are encapsulated into "hands and feet" that the AI agent can directly invoke. Furthermore, all testing is executed in an isolated Docker sandbox, so even if the AI suddenly does something dangerous, it won't affect the host environment.
II. Why Choose a Hong Kong VPS as the Deployment Environment?
Deploying Strix on a Hong Kong VPS is a compromise that balances network connectivity and cost efficiency.
Strix itself is just an orchestration layer; the real "brain" driving it is the large language model. If you use closed-source commercial models like OpenAI GPT-5 or Anthropic Claude Sonnet 4.6, the API interfaces are usually deployed overseas. Hong Kong VPSs generally offer ample international bandwidth, low latency communication with these API services, and virtually no risk of being mistakenly blocked.
However, if you choose to completely bypass API fees by deploying open-source models like Qwen or DeepSeek locally using Ollam, the hardware configuration of your Hong Kong VPS (especially GPU computing power) may be insufficient—running Qwen 2.5-32B requires at least 24GB of VRAM, far exceeding the capabilities of a typical VPS. Therefore, a more reasonable deployment path on a Hong Kong VPS is: the Strix orchestration layer runs on the VPS, while AI capabilities are implemented by calling cloud APIs, balancing cost and performance.
Of course, cloud service providers generally have more lenient management of outbound access to their Hong Kong nodes, making deployment and debugging smoother. When choosing VPS specifications, memory is the primary consideration—the official recommendation is at least 8GB, but in practice, starting with 16GB is much more efficient. Otherwise, when scanning large targets, the accumulation of AI agent states can easily fill up memory, forcibly terminating the process.
III. Step-by-Step Deployment Guide (Based on Ubuntu 22.04)
Environment Preparation Checklist Before Deployment:
- Hong Kong VPS: Recommended 4-core CPU, 16GB or more RAM, 50GB or more available disk space
- Python 3.12 or later
- Docker Engine (running)
- Valid LLM API Key (OpenAI format or compatible interface)
Step 1: Initialize Basic System Environment
After logging into your VPS, first update system packages and install necessary compilation tools:
sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl wget build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev libncursesw5-dev \
xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-devEnsure your Python version meets the requirements: If your version is lower than 3.12, you need to upgrade to 3.12 or higher using deadsnakes PPA or pyenv.
python3 --versionStep 2: Install Docker and Start the Service
Strix's sandbox mechanism relies on a Docker environment; ensure it is running.
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker $USERImportant Note: Many tutorials end here, but you must exit the current SSH session and log back in for group permissions to take effect. Otherwise, Strix will report a permission denied error when calling Docker later.
Step 3: Install Strix
The official recommendation is two installation methods; here, we choose pipx installation for clearer management:
# Install pipx
python3 -m pip install --user pipx
python3 -m pipx ensurepath
# Reload shell configuration
source ~/.bashrc
# Install Strix via pipx
pipx install strix-agentAfter installation, verify that the command-line tools are working properly:
strix --versionIf you prefer to install from source code (for easier secondary development or viewing logs), you can also clone the repository and install using Poetry:
git clone https://github.com/usestrix/strix.git
cd strix
pip install poetry
poetry install --no-devStep 4: Configure the AI model and key
Strix needs a "brain" to drive it. Here, we'll use the OpenAI API as an example (compatible with most domestic models such as DeepSeek and Tongyi Qianwen):
export STRIX_LLM="openai/gpt-5"
export LLM_API_KEY="sk-your actual key"If you are using a custom API proxy address (e.g., accessing via a relay service), you need to specify it separately:
export LLM_API_BASE="https://your proxy address/v1"This is where the advantages of Hong Kong VPS network lines become apparent: if you directly configure the official OpenAI key, the network latency of the Hong Kong node is typically significantly lower than a direct connection from mainland China, resulting in a noticeably smoother response time for Strix agents.
To avoid reconfiguring every time you log in, you can add these lines to ~/.bashrc or ~/.strix/cli-config.json, and Strix will automatically read them.
Step 5: Initial Run and Docker Image Pull
During the initial scan, Strix will automatically pull the Docker images required by the sandbox—this step takes time depending on your VPS bandwidth; just be patient.
strix --target https://example.com --instruction "Rapid security assessment"The `--target` parameter here is very flexible; it can point to a local code directory, a GitHub repository address, or an online URL, corresponding to white-box, gray-box, and black-box testing modes, respectively.
IV. Practical Testing and Report Interpretation
Basic Scanning Commands
After the initial mirror pull, subsequent scans are much smoother. The following command performs a full scan of the local code repository:
strix --target ./your project directoryIf the target is a web application deployed on the public internet:
strix --target https://your application domainStrix defaults to an interactive user interface (TUI), where you can see the thought process of each AI agent in real time, the attack methods being attempted, and the clues discovered. To integrate it into automation scripts, simply enable Headless Mode.
strix -n --target https://your application domainAdvanced Testing Scenarios
Strix's true power lies in its natural language commands—you can tell it the focus of the test as if you were giving it a task. For example, performing certified gray-box testing:
strix --target https://your application.com \
--instruction "Use the account admin:password for authentication testing, focusing on business logic defects and IDOR vulnerabilities."It's even possible to pass in more complex test scope specifications via file, such as specifying which paths can be tested and which paths need to be excluded:
strix --target api.yourapplication.com --instruction-file ./testscopedescription.mdResults Report Directory
After scanning, the results will be saved in the `strix_runs/` directory (source code installation path) or the `agent_runs/` directory (pipx installation path). Typical output includes:
Markdown format vulnerability details: Each vulnerability comes with complete attack steps and PoC code.
CSV format vulnerability summary table: Easy to import into a vulnerability tracking system.
Pay close attention to the PoC section—this is the core value that distinguishes Strix from traditional scanners. It doesn't just vaguely tell you "there may be a risk," but directly provides exploit code that proves the vulnerability actually exists. Developers can use this to directly reproduce and verify the effectiveness of the fix.
V. Operation and Maintenance Precautions and Pitfall Avoidance Guide
1. Memory Resource Management: Strix's AI agent accumulates a large amount of context state when performing complex tests. If the VPS only has 8GB of memory, it is recommended to avoid scanning multiple targets simultaneously and closely monitor the output of `htop` or `free -h` to prevent OOM (Out of Memory) errors that could force the process to be killed by the system.
2. API Cost Control: While Strix orchestration is free, each scan incurs a cost due to calls to the LLM API. The inference intensity of the model can be controlled via the `STRIX_REASONING_EFFORT` environment variable—use medium for testing and switch back to high for production deep scans.
3. Docker Image Updates: The sandbox environment periodically patches vulnerabilities and adds new tools. Remember to regularly run `docker pull` to update the base image to avoid lag in the test environment.
4. Expected Scan Duration: Based on real-world testing, the first deep scan of a complex web application by Strix may take several hours, especially when the target contains many dynamically interactive pages. It is recommended to run it during off-peak hours or perform a quick screening using `--scan-mode quick`.
Strix's value lies in transforming security testing from "periodic manual outsourcing" to "automated continuous processes." While AI may not be as adept as top human penetration testers when dealing with extremely complex business logic vulnerabilities, its efficiency and cost advantages as an automated security baseline are unmatched by traditional methods. For teams building DevSecOps processes, self-hosting Strix on a Hong Kong VPS is a technically feasible and highly cost-effective approach.
