Should you evaluate DeerFlow?
Evaluate DeerFlow when its combined research and coding workspace answers a concrete need and your team can own deployment. Our run on September 27, 2026, at commit 230d8f0 left setup unresolved. We did not verify a running web application, Docker deployment, model connection, terminal-client session, or completed agent workload.
DeerFlow orchestrates subagents, memory, and sandboxes through extensible skills. The commit-pinned README describes that architecture. The v2.1.0 release notes also describe projects, conversation branching, scheduled tasks, and durable batch delegation. These are documented capabilities, not tasks demonstrated in our sandbox.
Our install outcome needs investigation
Our harness recorded install exit 0 in 59 seconds, but the install tail contains local-package build errors. Setuptools rejected automatic discovery of multiple top-level packages: app, samples, packages, and extension_test_fixtures. The tail includes errors from both editable and wheel build attempts. The available evidence does not explain the enclosing command's zero exit status, so a clean installation cannot be inferred from that status alone.
The build step recorded exit 0 in 12 seconds with an empty log tail. It establishes the recorded command outcome, not a working service or application build of known scope. Our sandbox recorded 35 dependency packages occupying 37 MB.
Our harness records each step's success flag, exit code, elapsed time, and available log tail, with parser summaries stored separately. Read those fields together. The MrKeyoor testing methodology explains the publisher's approach and its limits. Its current description does not establish which methodology revision the September run used. This review uses the stored run; no new execution was performed.
What the pytest record establishes
DeerFlow pytest recorded 200 errors in our sandbox. The attached stored parser summaries record 0 passed, 0 failed, 4 skipped, and 200 errors. Their total field is 200; these values are not verified unique or exhaustive test counts. The skipped tests remain a separate category.
The harness recorded test exit 1 after 23 seconds. Separately, the raw pytest footer reports 4 skipped, 7 warnings, and 200 errors in 13.78 seconds. The footer's duration and the harness's wall time have different reporting boundaries and should not replace each other.
The raw tail names errors in delegation, extension, file-handling, and Gateway modules, including tests/test_gateway_health.py and tests/test_gateway_request_path.py. It does not supply the underlying tracebacks needed to establish a shared cause. The install packaging errors warrant investigation, but the supplied evidence does not prove they caused the pytest errors.
For an adoption trial, reproduce the documented setup path, inspect the first complete traceback, and explain the install outcome. Then verify service launch and complete a representative agent task. Our stored command outcomes cannot substitute for those checks.
Plan resources around the documented deployment
The commit-pinned README starts local evaluation at 4 vCPU, 8 GB RAM, and 20 GB of free SSD. Our sandbox had 3 CPUs, below that documented CPU starting point. That difference limits how broadly this result should be applied; it does not establish the cause of the packaging or pytest errors.
Docker development starts at 4 vCPU, 8 GB RAM, and 25 GB of free SSD. A long-running server starts at 8 vCPU, 16 GB RAM, and 40 GB. The README excludes a locally hosted language model from those figures and recommends Linux with Docker for persistent deployment.
Docker requires Compose v2.24 or newer. The setup wizard asks for a model provider, optional search, sandbox mode, bash access, and file-write choices. The README recommends make doctor for diagnostics. The supplied installation guide distinguishes prerequisite preparation through make docker-init from the subsequent launch step, make docker-start.
Review v2.1.0 before upgrading
The v2.1.0 notes document breaking changes to tracing, managed skill projections, E2B capacity, memory configuration, checkpoint settings, and Docker binding. The published Docker entry port binds to 127.0.0.1 by default. Check those changes against your configuration before upgrading or changing network exposure.
The release describes tool receipts and parent-side acceptance checks for delegated deliverables, with undecidable criteria reported as UNVERIFIED. Those documented controls do not establish that our sandbox completed delegated work. Likewise, our pip-audit result of 0 recorded advisories, with unknown scan coverage, does not validate the controls or prove security.
Compare the workflow you need
OpenHands Agent Canvas is a self-hosted developer control center for coding agents and automations. Its README describes multiple execution backends and support for several coding agents. Consider it as a replacement candidate when coordinating coding agents and automations is your main requirement. The supplied evidence does not justify describing it as limited to a narrow coding loop.
Dify supports building and testing AI workflows on a visual canvas. Its README also describes RAG pipelines, model management, observability, and agents that can run commands and handle files. Consider it as a replacement candidate when building an LLM application through visual workflows is the central task. Neither comparison establishes complete DeerFlow feature parity, and our run did not test either alternative.
What the scores mean
These retained editorial scores use a 1 to 5 rubric. They measure the stated dimension, not overall product quality or runtime performance.
For setup ease, 1 means preparation blocked; 2 means unresolved setup evidence; 3 means preparation reproduced; 4 means launch verified; and 5 means a representative workload verified. DeerFlow scores 2 because the install outcome conflicts with packaging errors and the test command returned errors.
For documentation, 1 means no usable setup guidance; 2 means basic installation instructions; 3 adds configuration and launch guidance; 4 adds diagnostics and deployment guidance; and 5 adds sizing and migration coverage. DeerFlow scores 5 for the supplied documentation's coverage. We did not verify every instruction.
For community, 1 means little participation evidence; 2 means contribution channels exist; 3 means visible contributions; 4 means documented participation in a release; and 5 means substantial release participation alongside repository attention. DeerFlow retains 5 based on the supplied repository extract and the v2.1.0 contributor account. This rubric does not measure adoption, support response time, or user satisfaction.
For maturity, 1 means an experiment without an operating path; 2 means a documented prototype; 3 means a documented release and deployment path; 4 adds migration guidance and operational controls; and 5 requires demonstrated deployment reliability beyond this run. DeerFlow scores 4 for its documented controls and migration guidance. Our sandbox leaves deployment reliability unverified.