ARL-Next: A Rebuilt Asset Reconnaissance Stack With an MCP Server and a Chinese Network Assumption

The problem ARL-Next claims to fix is ARL's operational decay

The README frames the project as a response to the original ARL's stalled maintenance, listing task hangs, memory leaks, installation errors and outdated dependencies as the motivating defects. Its comparison table puts the two side by side: original ARL is described as blocking under Celery when scanning large target sets and leaking memory until OOM, while ARL-Next claims to decouple screenshot and OSINT work into separate microservices and to remove the Docker container memory hard limit. The intended audience is clear from the feature list: security analysts running asset discovery for red team engagements, bug bounty programmes or attack-surface management, particularly those covering Chinese corporate groups. The enterprise OSINT feature, described as Tianyancha equity penetration plus ICP filing drill-down across domains, mobile apps, WeChat mini programs and quick apps, is not a generic capability. It is aimed at teams whose targets file ICP records and appear in Tianyancha. If your scope is European or North American infrastructure, that whole column of the feature matrix does not apply to you.

Two call paths: a direct OSINT microservice and a three-queue Celery cluster

The architecture diagram in the README is the most informative part of the repository. Traffic enters through Nginx serving a Vue 3.5 frontend on port 5173, which reverse-proxies REST calls to a Gunicorn backend on port 5000. From there the design splits. OSINT work (Tianyancha and ICP collection) is called directly by the backend over port 16181 against a coroutine-pool microservice, explicitly bypassing Celery. The README states this is to avoid the hang behaviour seen in the original. Production scan tasks go instead to RabbitMQ 3, which fans out into three named queues: arltask_light for DNS, port and fingerprint work, arltask_heavy for Nuclei, PoC and crawler work, and arlgithub for CVE and code-leak monitoring. A scheduler and beat process triggers periodic runs. Heavy workers call a Puppeteer microservice on port 5005 for headless screenshots. All paths converge on MongoDB 7.0, with the README naming safe_insert_asset_many for light workers, bulk_write for heavy workers and atomic upsert for the threat-intelligence worker. An Autoheal probe watches the worker cluster through docker.sock. The notable decision is the split between direct and queued execution: it trades a uniform task model for isolation of the component that was failing.

Deployment: docker-compose, prebuilt Alibaba Cloud images, and a 2-minute claim

The README advertises a 2-minute install and points at a quick-deploy section, but the truncation of the supplied text means the exact compose invocation is not visible here. What is documented is the shape of the deployment: a docker-compose stack containing Nginx plus Vue, the Gunicorn backend, the OSINT microservice, the Puppeteer microservice, RabbitMQ 3, MongoDB 7.0, Celery workers split by queue, a beat scheduler and the Autoheal probe. The README states the images are prebuilt and hosted in a private Alibaba Cloud registry, and presents this as the fix for overseas network blocking and failed pip or Docker pulls. That is a real operational dependency, not a footnote. If you cannot reach that registry, you are building multi-stage images yourself, and the 2-minute figure no longer describes your path. The README also mentions Basic Auth in front of the web interface and a health-check and self-healing mechanism, and says the system supports hot updates from the web console. There is no documented environment variable list, no compose file excerpt and no port override guidance in the material provided, so treat the configuration surface as something to read from the repository before you plan a rollout.

The MCP server is the differentiator, and also the least documented piece here

ARL-Next ships a native Python MCP server, with the README linking to a separate mcp-server/README.md for configuration. The diagram shows an AI agent connecting over stdio and then calling the backend with API token authentication. The README claims this lets an agent issue scans in natural language and export what it calls a 13-dimension asset overview. That is a genuine architectural choice: most scanners in this space expose a REST API and leave agent integration to the user. Two things are worth flagging. First, the security boundary is the API token, so the MCP server is only as safe as that token's scope, and the supplied material does not describe scoping or rotation. Second, the actual tool surface (which MCP tools exist, what arguments they take, what they return) lives in a file not included here. Do not plan an agent workflow from the main README alone. The claim that an agent can take over asset mining and analysis is marketing framing; the concrete, verifiable statement is that an MCP server exists and authenticates to the backend with a token.

Where the design breaks down

The most obvious limitation is geographic. The README's own selling points, Alibaba Cloud image hosting and ICP plus Tianyancha OSINT, are liabilities outside China. A team in another region gets the scanner and the MCP server but not the enterprise asset chain that the feature matrix leads with. Second, the stack is heavy. Nginx, a Vue build, Gunicorn, two microservices, RabbitMQ, MongoDB, three worker classes, beat and Autoheal is a lot of moving parts for a reconnaissance tool, and every one of them is a failure domain. The Autoheal probe exists precisely because the maintainers expect containers to die. Third, the removal of the Docker memory hard limit is presented as a performance win, and it is, but it also means a runaway scan can consume host memory rather than being capped by the container. The README frames this as letting large-memory machines run at full speed; the same setting on an undersized host is a risk. Fourth, the WIH sensitive-information engine is described as pure Python with no external binary dependency, which removes the Go toolchain problem but leaves the extraction throughput dependent on Python. The README asserts millisecond-level streaming parsing; that is a claim from the project, not something verified here.

How this differs from running Nuclei and Nmap yourself

The honest alternative is not another ARL fork. It is the combination most teams already have: Nmap for port and service discovery, Nuclei with a template set for vulnerability checks, and a small scheduler plus a database to store results. That approach has no web console, no ICP or Tianyancha integration, no MCP server and no screenshot microservice, but it also has no MongoDB, no RabbitMQ and no Autoheal. The difference in approach is centralisation versus composition. ARL-Next decides for you: one database schema, one task model, one UI, one MCP endpoint, one deployment. The composed approach lets you swap the scanner and keep your existing asset inventory. ARL-Next's advantage appears when the asset chain matters, meaning you want corporate equity and ICP records to feed the same pipeline that runs Nuclei, and when you want an agent to drive that pipeline. Its disadvantage is that you inherit the whole stack to get those features. If you only need periodic Nuclei runs against a known domain list, ARL-Next is more machinery than the problem requires.

Licence, maintenance and upgrade cost

ARL-Next is GPL-3.0. That matters more for a network-accessible service than for a library. If you modify the code and expose it to users over a network, the GPL-3.0 obligations around offering corresponding source apply. This is not legal advice, and the exact scope depends on how you deploy and whether your modifications are distributed, so take it to counsel if you plan to build a commercial offering on top. On maintenance, the repository shows three releases within three days in September 2026 (v1.3.1, v1.3.2, v1.3.3), which indicates active work but also a fast-moving surface. The README points to a CHANGELOG.md for details. The upgrade story the project advertises is a web-console hot update, which is convenient but means you should read the changelog before pulling, particularly around MongoDB schema changes, since the architecture relies on a wide-table collection with compound indexes. Because the images come from a private registry, you are also depending on that registry staying available and on the maintainer continuing to publish there. That is a single point of failure worth naming before you put this in a production pipeline.

Editorial conclusion

Adopt ARL-Next if you already operate inside Chinese network conditions and want a maintained ARL lineage with an MCP endpoint for agent-driven scans. Do not adopt it if you need a small single-binary scanner, if you cannot host the Alibaba Cloud images, or if you object to GPL-3.0 obligations on a networked service. Before deploying, verify that the mcp-server/README.md describes the API token flow you intend to use, confirm the docker-compose file pins the MongoDB 7.0 and RabbitMQ 3 images you can actually pull, and check whether the 2-minute deployment claim holds on your host without the prebuilt registry.

Official sources

1. Issues
2. License: GPL-3.0
3. owl234/ARL-Next on GitHub
4. README
5. Releases