DeerFlow

GDPR overview

There is no GDPR information of any kind on the site. A search across every collected page, in rendered text and in archived HTML alike, returned no occurrence of GDPR, RGPD or CCPA. No Data Processing Agreement is offered, no subprocessor list is published, no Article 27 EU representative is designated, no data protection officer is named and no privacy contact address exists. No SOC 2 or ISO 27001 certification is claimed. This silence is not automatically a compliance failure: DeerFlow is self-hosted software rather than a service, so the organisation that deploys it acts as controller and carries the obligations itself. European teams should plan on writing their own record of processing activities, and note that authentication is theirs to configure through BETTER_AUTH_SECRET.

Who owns the data?

No terms of service and no privacy policy are published on the site, so the project makes no contractual claim over user data at all. In practice, ownership follows the deployment. DeerFlow is self-hosted: conversation threads are written to backend/.deer-flow/threads/ on infrastructure the operator controls, and Docker deployments bind-mount that directory into the gateway container. Uploaded files sit in the thread sandbox under /mnt/user-data/uploads/. The organisation that installs DeerFlow therefore holds the data and also carries the responsibility a vendor agreement would normally allocate. Anyone who needs a written data-ownership commitment from the publisher will not find one here.

Reuse rights

Because no terms of service exist, the project neither restricts nor authorises what an operator does with the data its own deployment produces: nothing is written down. What the documentation does make clear is that data leaves the deployment as soon as external services are configured. Prompts and content are sent to whichever model provider the operator wires up through config.yaml and the .env file. Community tools add further recipients: Tavily, Exa, InfoQuest, Firecrawl and Jina AI all take operator-supplied API keys, while DuckDuckGo search and anonymous Jina AI extraction work without one. Uploaded PDFs are converted to Markdown before reaching the model. Each of those third parties applies its own terms, which the operator has to review separately.

Data retention & training

Hosting summary

DeerFlow hosts nothing on the user's behalf: it is self-hosted software, so the jurisdiction that applies is the one where the operator chooses to run it. Conversation threads are written to backend/.deer-flow/threads/, which Docker deployments bind-mount into the gateway container. The documentation recommends replacing that bind-mount with a named volume or a PersistentVolumeClaim in production, precisely because recreating containers otherwise destroys the data. Session files live in the sandbox under /mnt/user-data/uploads/ and generated outputs under /mnt/user-data/outputs/. No hosting country or region is declared anywhere on the site, and none could be, since the publisher operates none of it. For completeness, the marketing site itself resolves to 101.47.172.234, located in Singapore on AS150436, Byteplus Pte. Ltd. That address describes where the brochure is served and says nothing about where a user's data would sit. Operators who need a documented jurisdiction should treat it as a question they answer themselves when they choose a cluster.