One application joins agents, memory, tools, and sandboxes
DeerFlow 2.0 is a full agent product rather than a small orchestration library. A lead agent can call tools, use skills, delegate to sub-agents, compact context, remember information across sessions, and work with files in a sandbox. Users interact through a web application, terminal workbench, embedded Python client, scheduled tasks, or messaging channels. That saves a platform team from assembling a chat UI, runtime, persistence, and execution layer separately.
Version 2 shares no code with the original deep-research framework, which remains on the main-1.x branch. The new scope covers research, coding, report generation, slides, media skills, and other file-producing work. Breadth is useful when one internal service must support several task types. It also makes evaluation harder, because a successful research demo does not validate command execution, memory isolation, messaging identities, or multi-worker recovery.
The 36 MB backend environment built, then collection failed
Our harness targeted the Python project under backend/ at commit 13f0a7f. The full checkout contained 2,337 files, about 503,895 source lines, and occupied 44 MB. Installing 33 packages took 32 seconds and left a 36 MB environment. The build succeeded in 16 seconds, and pip-audit found 0 known vulnerabilities in those installed Python dependencies.
That modest backend measurement excludes the frontend packages, Docker images, sandbox image, model weights, databases, and optional integrations needed for a complete service. The repository has a Dockerfile, a tests directory, and 14 CI workflow files. DeerFlow's own sizing table starts local evaluation at 4 vCPU, 8 GB RAM, and 20 GB of free SSD, then recommends more for Docker or shared use. A local model needs separate capacity.
What happened when we ran it
Our test step failed after 22 seconds with exit code 1. Pytest reported 0 passed, 0 failed, 4 skipped, and 200 collection or setup errors out of 200 before stopping at its failure limit. The log tail named MCP interceptor, migration, OAuth, routing, session-pool, timeout, and sync-wrapper test modules. No test body completed in the reported result.
Those filenames identify where collection or setup stopped, not why. The tail contains no missing-package message, stack trace, service error, or assertion that would support a cause. We therefore cannot say whether the fresh Debian container lacked configuration, a service, a fixture, or something else. The bounded finding is that installation and build passed, while the backend suite did not reach executable tests in our 3-CPU, 8 GB environment.
Model choice still means provider-specific configuration
The setup wizard asks for a model provider, optional web search, and execution permissions, then writes config.yaml and .env. DeerFlow documents OpenAI-compatible endpoints, the Responses API, OpenRouter, vLLM, Codex CLI, and Claude Code OAuth among its choices. Each path has different keys, base URLs, reasoning fields, and streaming usage behavior. A shared configuration format reduces switching cost but cannot make provider semantics identical.
Local development requires Python 3.12 or newer, Node 22 or newer, pnpm, uv, and nginx. Docker Compose v2.24+ is required for the recommended container route. The production command builds the images and waits for a health endpoint. Persistent deployments can use SQLite or PostgreSQL for checkpoints and application data. PostgreSQL plus Redis-backed coordination enters the picture when several Gateway workers must share runs and stream delivery.
Command execution makes localhost the correct default
DeerFlow can execute system commands, read and write files, call business tools, and launch MCP servers. Its Docker entry point binds to 127.0.0.1 by default, and the security notice describes a local trusted environment as the intended deployment. Changing BIND_HOST to 0.0.0.0 should happen only after account setup, an IP allowlist or isolated network, and a pre-authenticating reverse proxy are in place.
Gateway administrators deserve even tighter control. They can register stdio MCP servers that launch commands inside the container. An allowlist limits launchers such as npx and uvx, but the documentation says this is defense in depth because those tools fetch and execute packages. Treat an admin session as code execution, keep provider secrets out of agent-readable paths, and test what the selected sandbox can reach on the network and host filesystem.
A single worker is simpler than distributed run ownership
Production defaults to 1 Gateway worker because active tasks belong to the process running them. DeerFlow documents a multi-worker design using PostgreSQL, a Redis stream bridge, heartbeat leases, database-backed events, reconnect replay, and orphan recovery. Cancellation can arrive at a worker that does not own the run, so the owner must observe a persisted request during lease renewal. These are serious distributed-systems concerns, not a toggle for extra throughput.
Start with one worker and measure concurrent sessions before adding that machinery. The README suggests reducing concurrent runs first when CPU or memory remains pinned. A long task may also have a remote tool side effect already in flight when local cancellation occurs. Operators need limits for sub-agents, tool calls, runtime, tokens, and sandbox resources, plus a recovery drill for a Gateway restart during active work.
August activity is intense, while version 2 is still settling
GitHub showed 80,969 stars, 910 open issues and pull requests, and a last push on August 27, 2026. Release v2.0.0 arrived June 25 after 182 merged milestone pull requests. Current work touches memory cleanup, sandbox hardening, runtime eviction, scheduling, frontend retries, messaging, and MCP cancellation. The combined open count includes pull requests and is not a 910-bug tally.
The repository is moving fast enough to merit pinned revisions and staged upgrades. Open macOS and Ubuntu reports describe local nginx startup failing on permission to its compiled log path, even after prerequisite checks passed in one case. DeerFlow is worth evaluating when its complete shell saves months of integration work. Our 200 setup or collection errors and the product's privilege level mean evaluation should happen in an isolated environment with real failure and recovery tests.