The ITOps Agent Platform README tells you not to pull the images yet

The second paragraph of the README says do not pull the image yet

It is unusual to find that sentence that high on a front page. Under the language switcher, the project says it is undergoing a full refactor on a 4A architecture framework with DDD domain-driven design, aimed at decoupling business logic from technical implementation and giving the system more room to extend.

Then it qualifies itself. The refactoring workload is large and the project is in a progressive replacement phase. The recent pushes and the Docker images built from them are a transitional state with unverified, mixed dependencies, and the text says plainly that pulling and using them is not recommended. It splits the audience in two: ordinary users should wait for a stable release, while developers who can debug and modify source are invited to fork and are asked to help fix temporary defects.

The tag history agrees with that caution. There is exactly one published release, v3.1.0 on 2026-06-27, titled container virtualisation upgrade plus README rewrite. The main branch was pushed to on 2026-09-28, so the branch sits about three months past the only tag, and the README is telling you that what is on it now is mid-refactor.

Version 3.0.5 in package.json, v3.1.0 as the only published tag

The manifest opens with two lines that settle several arguments at once:

  "version": "3.0.5",
  "private": true,

and closes its identity block with two more:

  "author": "",
  "license": "MPL-2.0",

The version field reads 3.0.5 while the newest tag is v3.1.0. The tree you clone is therefore not the tree that release was cut from, and any tooling that reports the version out of package.json will print a number older than the one on the releases page. Nothing in the scripts corrects for this; there is no step that derives the version from a tag.

The private flag is unremarkable for an application, and it also means the project is not meant to be consumed as a published npm package. The empty author field is the odd one. The docker-compose.yml header credits a named author instead, and the README links a first-person note published on WeChat. The person behind the project is named in two places, and the canonical package manifest is not one of them.

MIT before 2026-05-27, MPL-2.0 after, and a metadata field that names neither

The licensing is the most tangled corner of this repository. The README carries a dated notice: every line committed before 2026-05-27 stays under MIT, and from that date forward all added or modified code is released under Mozilla Public License 2.0. The package.json licence field says MPL-2.0 flatly, with no reference to the earlier MIT period. The docker-compose.yml header also says MPL-2.0. The root holds both a LICENSE file and a NOTICE.txt. The platform's own licence metadata for the repository reads NOASSERTION, the value recorded when a licence cannot be classified, so it matches neither of the two the project names for itself.

The README then adds its own conditions on top of that grant. Distributing a binary, image or deployer containing modified code requires opening every modified source file and keeping the original copyright and licence notices, with no passing the result off as self-developed. Private deployment inside an enterprise network and paid consulting, deployment and custom development on top of the project are both allowed.

Two things are forbidden by name: closing the source into a standalone commercial product or image for sale, and building a competing SaaS platform of the same kind. Those two are conditions this README states. They are not something the licence name on its own tells you, and a compliance review should be based on the notice, not the SPDX field.

The recommended install pulls its script from Gitee, not from GitHub

The deployment instruction is a single chained command, labelled as the recommended path for Linux and Mac:

# Linux/Mac 一键脚本部署（推荐）
curl -sL https://gitee.com/IT_Oline/itops-agent-platform/raw/main/deploy.sh -o deploy.sh && chmod +x deploy.sh && ./deploy.sh

Two things stand out. The script is downloaded from a Gitee mirror under a different account name than the GitHub repository you are reading, and it is fetched, marked executable and run in one chain, so whatever deploy.sh does happens with no review step in between.

The repository carries four deployment scripts in two languages, deploy.sh, deploy.ps1, docker-build-push.sh and docker-build-push.ps1. Carrying both shells on a project whose maintainers are openly asking for help is a real ongoing cost.

The documentation has a similar shape. The project homepage, the documentation site, the online demo and a teaching book all sit on one tenant subdomain of a documentation platform, the official project site is on a different domain entirely, and the author's first-person note is published on WeChat.

Webhook verification is off by default and the JWT secret is generated

The backend's environment block is where the operational defaults live, and two of them deserve attention before anything else. This is the part that matters for secret handling:

      - DATABASE_PATH=/app/data/app.db
      - LOG_LEVEL=${LOG_LEVEL:-info}
      # JWT_SECRET 可选 — 不设置则由 backend 自动生成并持久化到 /app/data/.jwt-secret
      # 重启不会使已有 token 失效。如需自定义，可通过环境变量覆盖。
      - JWT_SECRET=${JWT_SECRET:-}
      - JWT_EXPIRES_IN=${JWT_EXPIRES_IN:-24h}

Authentication is handled thoughtfully. The comment says the secret is optional, that the backend generates one and persists it to /app/data/.jwt-secret when it is absent, and that restarting does not invalidate tokens already issued. Token lifetime defaults to 24 hours. The secret file sits beside the SQLite database at /app/data/app.db, so whatever volume preserves the database also preserves the signing key.

Alert ingress is handled differently. WEBHOOK_VERIFY_ENABLED defaults to false, WEBHOOK_SECRET defaults to an empty string, and WEBHOOK_IP_WHITELIST defaults to empty as well. For a platform whose loop begins with an alert arriving from outside, signature checking disabled by default is a decision to make on purpose rather than inherit.

Three model backends, one published port bound to all interfaces

The rest of the backend's configuration is three parallel sets of model variables, followed by an environment list that stops partway through the alert email settings:

      - DOUBAO_API_BASE=${DOUBAO_API_BASE:-https://ark.cn-beijing.volces.com/api/v3}
      - DOUBAO_MODEL=${DOUBAO_MODEL:-doubao-4o}
      - OPENAI_API_BASE=${OPENAI_API_BASE:-https://api.openai.com/v1}
      - OPENAI_MODEL=${OPENAI_MODEL:-gpt-4o}
      - LOCAL_AI_API_KEY=${LOCAL_AI_API_KEY:-}
      - LOCAL_AI_API_BASE=${LOCAL_AI_API_BASE:-}
      - LOCAL_AI_MODEL=${LOCAL_AI_MODEL:-}
      - WEBHOOK_VERIFY_ENABLED=${WEBHOOK_VERIFY_ENABLED:-false}
      - WEBHOOK_SECRET=${WEBHOOK_SECRET:-}
      - WEBHOOK_IP_WHITELIST=${WEBHOOK_IP_WHITELIST:-}
      - ALERT_EMAIL_HOST=${ALERT_EMAIL_HOST:-}
      - ALERT_

Doubao is wired to a Volcengine Ark endpoint with the model doubao-4o, OpenAI to its own v1 API with gpt-4o, and the LOCAL_AI group is empty by default for people running their own endpoint. Every API key in the block defaults to an empty string, which is the right default and also means the platform will start happily with no way to diagnose anything.

The service block binds the backend to 0.0.0.0 on port 3001 and publishes 3001:3001 to the host, so the port is reachable on every interface unless the firewall says otherwise. The compose file also carries a commented-out registry image on Aliyun with a latest tag, alongside the local build it actually uses.

docker:clean runs docker system prune -f, and the cycle check only sees the backend

The npm scripts are the project's operational surface, and four of them are worth knowing:

    "check:deps:graph": "npx depcruise --config .dependency-cruiser.json backend/src --output-type dot | dot -T svg > deps-graph.svg",
    "check:circular": "npx madge --circular --extensions ts backend/src",
    "docker:clean": "docker system prune -f",
    "prepare": "husky",

docker:clean is not project-scoped. docker system prune with the force flag removes all unused images, containers, networks and build cache on the machine, with no confirmation prompt, and it is one command away in a shared project. Nothing in the README warns about it.

The architecture checks are asymmetric. check:arch runs a local script over backend, and check:arch:frontend does the same for frontend, but check:deps and check:circular both point at backend/src only, so no dependency-cruiser rule and no circular-import check covers the frontend. check:deps:graph needs Graphviz on the PATH because it pipes dot output into an SVG file, which is an undocumented prerequisite for running it.

The prepare script runs husky, so an ordinary npm install also installs git hooks. The format script matches **/*.{ts,tsx,js,json,md,yml,yaml}, which means a formatting pass rewrites all seven translated READMEs as well.

Five account names across four hosts, and a README link that misses its file

This project is mirrored in several places and the naming is not consistent across them. GitHub has qinshihu/itops-agent-platform, Gitee has IT_Oline/itops-agent-platform, GitCode has gcw_IM7aAihp/itops-agent-platform, and the compose file's commented registry image sits in an Aliyun namespace called huluwa666 under an image name starting IT_Onlin. Five distinct account strings for one project.

The translation row at the top of the README has a matching slip. It links the Traditional Chinese version as README.tw.md in lower case, while the repository tree holds README.TW.md in upper case. On a case-sensitive filesystem that link does not resolve, and there are seven translated READMEs in total, with .de, .en, .fr, .ja and .ko files listed alongside.

The AI tooling section is the part with the clearest instructions in the whole document. ai-tool-configs/ holds derived templates for Cursor, Windsurf, Aider, Continue, Claude Code and GitHub Copilot, and the README marks them explicitly as not the source of truth. The source of truth is the root AGENTS.md together with .trae/, and the instruction is to read AGENTS.md first, then copy and adjust the file for your own environment rather than using the defaults as they stand.

Thirty to sixty minutes against three, and nothing measures either number

The README's persuasive section is built on paired numbers. Traditional operations take 30 to 60 minutes from being woken by an alert to writing the report; this platform takes three minutes with one tap on a phone. One person manages 20 to 50 machines the old way and 500 or more nodes with the AI carrying more than 80 percent of the workload. Marginal cost is described as approaching zero, and the knowledge base is described as never being lost again.

None of these figures comes with a measurement method, a workload description, or a test. The section that would carry that kind of support is the one that stops earliest: it sizes the market at 40 billion dollars in 2025 growing past 70 billion by 2030, and its last line breaks off partway through a sentence.

The positioning claim is starker still. The project describes itself as the only open-source AIOps platform that has engineered the full alert, diagnosis, decision, execution and verification loop, and calls 2026 the first year of autonomous IT operations. What the README is more credible about is the control model. For the security and compliance audience it names human-in-the-loop approval, full-chain auditing and command safety filtering, and for the SME row it claims parity with PagerDuty and Rundeck at no licence cost.

Editorial conclusion

The project's own warning belongs at the top of any evaluation. It says the recently pushed code and the Docker images built from it are a transitional state with unverified, mixed dependencies, and that ordinary users should wait for a stable release. Read that literally rather than as marketing caution. What the repository is genuinely good for is as a design reference for an approval-gated loop, alert to diagnosis to fix to verify, with a human in the middle and command filtering named as the safety net. What it is not currently is something to point a production operations centre at while a 4A and DDD refactor is still in its progressive replacement phase. If you build it anyway, change the defaults first: webhook signature verification is off, the signing secret is generated rather than supplied, and the backend binds to all interfaces on a published port. Settle the licence question before building on it, because the README attaches two prohibitions of its own to an MPL-2.0 grant.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. qinshihu/itops-agent-platform on GitHub
4. README
5. Releases