CyberStrikeAI deployment record: simple tool deployment also requires attention to details

Recently I have been working on CyberStrikeAI, an AI native security testing platform written in Go. I thought it was "one-click deployment", just clone it and run a script, but I ended up running into a few minor pitfalls. While your memory is still fresh, write down the entire process - many pitfalls are not actually a problem with the tools, but rather a lack of attention to the details.

Let’s first talk about what kind of tool this is

CyberStrikeAI is positioned as an "AI-native cybersecurity action system" and is written in Go. It integrates planning, execution, manual supervision, evidence retention, and playback into an auditable workbench. The core components include Eino-driven Agent, MCP native tools, RAG knowledge base, visual workflow and attack chain modeling analysis.

It has 100+ built-in tool recipes, covering the complete kill chain: network scans such as nmap, masscan, and rustscan; web scans such as sqlmap, nikto, gobuster, and ffuf; vulnerability scans such as nuclei, wpscan, and dalfox; as well as subdomain enumeration, API security, container security, cloud security, binary analysis, exploitation, password cracking, forensics, post-exploitation, and more. Basically everything you need to do authorized penetration testing is arranged for you.

There are also Burp Suite plug-ins and browser extensions, which can directly throw the captured traffic into the platform for AI-assisted analysis. This design is quite clever - no need to change your existing workflow.

Environment preparation before deployment

The official requires two prerequisites, please be careful not to cross the line in the version:

• Go 1.25+(The version explicitly required in go.mod. Compiling below this version will directly report an error)
• Python 3.10+(Required by some tools, such as api-fuzzer, http-framework-test)

Pitfall 1: Go version. The first time I used the old version of Go that came with the system, I only reported an error during the compilation stage. It is recommended to first go version Make sure it is not enough, go to the official website to install the new version first. This "precondition" is most easily ignored because the error occurs very late.

One-click deployment: What does the script do for you?

The official one-click deployment command is very simple:

git clone https://github.com/Ed1s0nZ/CyberStrikeAI.git
cd CyberStrikeAI
chmod +x run.sh && ./run.sh

But run.sh actually does more than you think, it executes in sequence:

• ✅ Check and verify Go and Python environments
• ✅ Create a Python virtual environment
• ✅ Install Python dependencies
• ✅ Download Go dependencies
• ✅ Build project
• ✅ Start service

Detail 1: venv is automatically managed by the script. The venv/ directory is automatically created and maintained by run.sh, and tools that require Python (api-fuzzer, http-framework-test, etc.) will automatically use this environment. Don't build one manually, it's easy to conflict.

Verification startup: several points that must be confirmed

After the script is finished running, don’t rush to open the browser, look at the terminal first:

• Confirm that the terminal displays ● ONLINE, followed by the actual Web UI address
• open that address: The default HTTPS mode uses a local self-signed certificate. The browser will warn you, just accept it once.
• New installations will have a one-time administrator password: The terminal is displayed under ADMIN SETUP REQUIRED. Change it immediately after logging in.

Detail 2: HTTPS or HTTP. run.sh is started with the –https parameter by default (local self-signed TLS, which officials say is more friendly to concurrent streams). If you want pure HTTP, you have to use it explicitly ./run.sh --http. To start manually, add –https or set CYBERSTRIKE_HTTPS=1 environment variable.

Do not use self-signed certificates in the production environment. Configure server.tls_cert_path and server.tls_key_path in config.yaml.

Pitfall 2: Error report of protocol mismatch. If you see "client sent an HTTP request to an HTTPS server" in the log, it means that a client is still using http:// to access the TLS port. Just change the URL, don't bother with server-side configuration.

First time configuration: AI channel is required

This step is not appropriate, and the platform is equal to not installed. After the first startup, visit https://127.0.0.1:8080/ (the port is subject to server.port in config.yaml), enter System Settings → Basic Settings → AI Channel Configuration, add the channel, fill in the provider, Base URL, API key, model and token upper limit.

You can also change config.yaml directly. The format is roughly like this:

ai:
default_channel: openai-main
channels:
openai-main:
provider: openai_compatible
api_key: “${OPENAI_API_KEY}”
base_url: “https://api.openai.com/v1”
model: “gpt-4o”

Detail 3: The scope of the default channel. ai.default_channel is used for new sessions and tasks that do not explicitly select a channel; in the chat page, you can also select any saved channel individually by session. So when you have multiple models, you don’t have to use just one.

If you fill in openai_compatible as provider, you can connect to most services compatible with the OpenAI interface. You can also change base_url to https://api.deepseek.com/v1 and model to deepseek-chat. The same goes for qwen3-max. Domestic models can be picked up at will, which is very friendly.

⚠️Safety reminder:Do not submit the real key in config.yaml. The official stated clearly not to commit real credentials and use environment variables to inject them.

Upgrading also requires methods

The official provides a one-click upgrade script, but you must first grant execution permissions for the first time:

chmod +x upgrade.sh && ./upgrade.sh –yes

What it does: Back up config.yaml and data/ directory → Pull new code from GitHub Release → Update the version number of config.yaml → Restart the service.Local tools/, roles/, skills/ directories will always be retained——This is very important, your customized tool recipes will not be overwritten.

Pitfall 3: Upgrade script dependencies. It requires curl or wget to download the Release package, and rsync for secure code synchronization (officially recommended/required). If the GitHub API is restricted, first export GITHUB_TOKEN="..." Run again.

If something goes wrong, you can restore from .upgrade-backup/, or manually copy data and config.yaml back and run run.sh.

important principles: Be sure to read the release notes of the target version before upgrading. Be especially careful when it comes to configuration, database, and API changes. The official saying is true - "Backup is necessary, even if it is just a patch upgrade; the version number itself is not a guarantee of compatibility."

A quick look at the directory structure

Figure out what each directory does so that you won’t get lost in subsequent maintenance:

• cmd/ — Server, MCP stdio entrance, tools
• internal/ — Agent, MCP core, processor, C2, security executor
• web/ — Static SPA and templates
• tools/ — YAML tool recipes (100+ examples)
• roles/ — Role configuration (12+ preset security test roles)
• skills/ — Agent Skills directory (SKILL.md + optional files)
• agents/ — Multi-Agent Markdown (orchestrator.md + sub-Agent)
• config.yaml — Runtime configuration
• run.sh/upgrade.sh — startup/upgrade scripts

When it comes to safety, tools can’t do it for you.

This platform integrates high-risk capabilities such as WebShell management and built-in C2 (listeners, encrypted beacons, sessions, task queues). The official attitude is very clear:Only use on systems that you own or are expressly authorized to test.

Always read the security model and hardening guide before enabling high-risk tools in a shared or production environment. It also has built-in tool call interception - a configurable regular check before MCP execution, and government domain name protection is enabled by default.

In addition, it only listens to 127.0.0.1 by default. If you want to expose the service to the outside world, be sure to reinforce it first. This is not a polite word, it is a reminder that only those who have stepped in a bloody pit will write into the document.

write at the end

Looking back, there were no major problems with the deployment itself. The script had already done 90% of the work. What really made me stop and check the documentation were all the details that I "didn't notice": Go version lines, venv cannot be created manually, HTTPS is turned on by default, resulting in protocol mismatch, upgrades need to be backed up, and keys must not be written into the configuration.

It's not difficult to look at these details individually, but if you miss one, you may be stuck for half an hour. The more mature the tool, the higher the benefits of "reading the documentation" - it encapsulates the complexity into the script, and the remaining complexity is in the configuration details.

The project has joined knownsec 404Starlink and is open source under the Apache 2.0 protocol. Friends who do authorized security testing can try it.

One-click deployment does not mean one-click understanding. Details are the real key to saving time.

Project address: github.com/Ed1s0nZ/CyberStrikeAI (moved to github.com/AIPentest/CyberStrikeAI)
Environment requirements: Go 1.25+ / Python 3.10+
License: Apache License 2.0
⚠️ For authorized testing use only