Flowsint: Visual, extensible OSINT graph platform for security analysis
Flowsint is a modular, self-hosted OSINT graph investigation platform with rich enrichers for link and threat-intelligence analysis, aimed at teams able to self-host.
GitHub reconurge/flowsint Updated 2026-02-01 Branch main Stars 5.3K Forks 640
FastAPI Graph DB / Neo4j OSINT investigation Self-hosted (local) Docker / Make Modular enricher system

💡 Deep Analysis

5
What concrete investigative problems does Flowsint solve, and how does it realize these capabilities within a single platform?

Core Analysis

Problem Core: Flowsint addresses how to consolidate disparate OSINT data (domains, IPs, social media, crypto wallets, website content, etc.) into an interactive relationship graph for fast attribution, relationship reasoning and traceability, while enabling local-first deployment for privacy/compliance.

Technical Analysis

  • Graph-Centric Model: Uses Neo4j for entities and relationships, enabling path queries (shortest path, neighbor expansion) useful for tracing attack chains or linkages.
  • Unified Types and Modular Enrichers: flowsint-types (Pydantic) standardizes entity schemas so different enrichers produce consistent outputs, reducing integration friction.
  • Asynchronous Enrichment Pipeline: Celery + real-time event streaming offloads slow external calls (WHOIS, blockchain APIs, Maigret) so the UI can progressively display results.
  • Local-First Deployment: Docker/Make local deployment keeps data on-premise—important for privacy-sensitive investigations.

Practical Recommendations

  1. Quick Validation: Run make prod locally and perform a domain → subdomain → WHOIS flow to observe nodes/edges creation in the graph.
  2. Pre-configure External APIs: Provision API keys and rate-limiting for enrichers that rely on external services (blockchain, WHOIS, Maigret).
  3. Extend via Enrichers: Implement new data sources following flowsint-enrichers base class and flowsint-types schemas.

Caveats

  • Not a Bulk Scanner: It’s intended for interactive and semi-automated investigations; large-scale scanning is constrained by external rate limits and legal/ethical boundaries.
  • Operational Complexity: Requires correct setup of PostgreSQL, Neo4j, a message broker (e.g., Redis/RabbitMQ) and Celery.

Important: Read ETHICS.md and confirm legal boundaries before sensitive investigations.

Summary: Flowsint unifies multi-source OSINT enrichment and graph exploration into a local-first platform, well suited for privacy-conscious, cross-domain investigative work.

85.0%
For an investigator, what are the onboarding learning costs and typical usage obstacles for Flowsint? What practical best practices reduce the barrier to entry?

Core Analysis

Problem Core: Assess the time and skills required for an investigator to deploy and use Flowsint locally, and how to avoid common obstacles for rapid productivity.

Technical Analysis

  • Onboarding (end users): The graphical frontend lets non-technical users perform basic entity searches and visual exploration for quick lead validation.
  • Pain Points: Full installation requires Docker/Make, Neo4j, Postgres, a broker and Celery; many enrichers rely on external APIs (need keys and are rate-limited).
  • Admin/Developer Burden: Extending enrichers, tuning graph models or optimizing Neo4j queries requires Python, Pydantic, Celery and Neo4j familiarity.

Practical Recommendations (Best Practices)

  1. Use Official Container Workflow: Run make dev or make prod in an isolated VM to validate service connectivity (Neo4j, Postgres) step by step.
  2. Prepare External Credentials: Collect API keys for WHOIS, blockchain, Maigret, etc., and enforce rate-limiting policies.
  3. Tiered Training: Provide UI guides for analysts, deployment/backup training for admins, and enricher development examples for devs.
  4. Small-Scale Pilots: Validate enricher outputs and rate behavior with 3–5 representative cases before scaling.

Caveats

  • Dependencies & Versions: As an early-stage project, breaking changes or missing functionality are possible; keep config and data backups.
  • Ethics & Compliance: Follow ETHICS.md and consult legal advisors when necessary.

Important: First deployments should be done in a controlled environment with logging of API keys and access for audit.

Summary: Basic usage is low-friction and good for quick lead validation; achieving full capability requires deployment and developer effort. Containerization, credential management and tiered training will reduce onboarding costs.

85.0%
When deploying Flowsint in production/team environments, how should you design reliable deployment, backup and maintenance procedures to ensure data security and availability?

Core Analysis

Problem Core: Transitioning Flowsint from a local PoC to a team-grade environment requires ensuring data durability, credential protection and fast recovery while maintaining privacy.

Technical Analysis

  • Data Layer: Neo4j holds graph entities/relations; Postgres stores users/tasks/logs—both need robust backup and restore.
  • Task Layer: Celery workers and a broker (Redis/RabbitMQ) manage async enrichers; they must support retries and idempotency.
  • Configuration/Credentials: Use a vault or environment-based secrets; enforce least privilege for API keys and credentials.

Practical Recommendations (Deployment & Maintenance)

  1. Containerization & Orchestration: Use Docker Compose or Kubernetes to separate services (api, app, neo4j, postgres, broker, celery). K8s fits team/high-availability use.
  2. Backup Strategy:
    - Neo4j: periodic snapshots or official backup tools; test restores.
    - Postgres: WAL archiving + periodic full backups.
    - Secrets: centralize in Vault (HashiCorp) or K8s secrets and limit access.
  3. Monitoring & Alerts: Track Neo4j query latency, Celery queue length, API error rates, and resource usage; set alerts.
  4. Audit & Access Control: Enforce RBAC at app layer, log user actions and task runs for audit purposes.
  5. DR Drills: Regularly test service outage and data restore to validate RTO/RPO.

Caveats

  • Cost & Complexity: HA and K8s increase operational cost; constrained teams can run single-node containers with offsite backups.
  • Compliance & Privacy: Local storage reduces cloud exposure but still require encryption at rest and secure backup transport.

Important: Define and test backup/restore, key rotation and audit procedures before production use.

Summary: Productionizing Flowsint requires a full ops plan—orchestration, backups, secrets management, monitoring and audits—to deliver privacy-preserving yet reliable team operations.

85.0%
In which investigative scenarios is Flowsint most suitable? What are the clear applicability constraints or scenarios where it is not recommended?

Core Analysis

Problem Core: Define where Flowsint delivers the most value and where architectural or legal/operational constraints limit applicability.

Technical Analysis (Suitability)

  • Best-fit scenarios:
  • Interactive attribution and relationship analysis: Linking domains, IPs, social accounts and wallets into relationship chains for manual/semi-automated exploration.
  • Privacy-sensitive investigations: Requirements to keep data on-premises (corporate investigations, law enforcement with data handling constraints).
  • Small-to-medium case work: Deep dives on individual cases or limited sets of targets.
  • Not recommended:
  • Large-scale bulk scanning: External rate limits, resource consumption and legal constraints restrict throughput.
  • Real-time, large-scale monitoring/alerting: Flowsint is designed for exploration, not as a 24/7 alerting platform.
  • Teams without ops capability: Managing Neo4j, Postgres and brokers requires some operational maturity.

Practical Recommendations

  1. Use as a case workbench: Deploy Flowsint as an interactive investigation workspace and integrate batch scanner outputs into it for deeper graph analysis.
  2. Hybrid workflows: Use dedicated scanners for high-volume tasks and ingest summaries into Flowsint for link analysis.
  3. Pre-check compliance: Validate legal and policy constraints before enabling automated enrichers.

Caveats

  • Data quality & external dependencies: Enricher reliability depends on third-party services—plan retries and graceful degradation.
  • Early-stage stability: Avoid relying solely on Flowsint for critical intelligence until maturity improves.

Important: Treat Flowsint as a powerful interactive analysis tool, not a substitute for dedicated bulk scanners or SIEMs.

Summary: Flowsint excels at graph-oriented, privacy-aware investigative work; it is less suitable for bulk scanning or 24/7 monitoring.

85.0%
If I want to write a custom enricher for a specific data source (e.g., private API or custom blockchain node), how should I design it to be compatible with Flowsint's type system and task pipeline?

Core Analysis

Problem Core: How to implement a custom enricher that integrates cleanly with Flowsint’s type system and asynchronous task pipeline, ensuring consistent data models, async execution, retries and rate control.

Technical Analysis

  • Use flowsint-types: Base all output entities (Domain, IP, Wallet, Transaction, etc.) on the provided Pydantic models to prevent schema mismatches.
  • Inherit enricher base class: Follow patterns in flowsint-enrichers to leverage lifecycle hooks and configuration loading.
  • Push long work to Celery: Encapsulate external requests or heavy processing as Celery tasks; let the orchestrator submit tasks and stream results back to the API/frontend.
  • Idempotency & retries: Make tasks idempotent (e.g., deduplicate by entity ID) and use Celery retry/backoff for transient failures.
  • Rate limiting & credential handling: Read API keys from the vault or env vars, implement client-side rate limiting and exponential backoff to avoid throttling.

Practical Steps (Development)

  1. Start from example enricher: Copy an existing enricher and replace the business logic while preserving I/O tests.
  2. Unit tests: Validate Pydantic outputs and edge cases (empty responses, error codes).
  3. Local validation: Run in make dev and confirm entries are written correctly to Neo4j/Postgres.
  4. Docs & config: Provide config knobs (API key, rate limits) and usage docs for operators.

Caveats

  • Data cleaning: External APIs may return inconsistent data—validate and sanitize fields.
  • Compliance: Ensure the new data source’s usage complies with legal and privacy requirements; log provenance for audit.

Important: Prioritize using flowsint-types models and base classes so your enricher fits the existing pipeline and reduces regression risk.

Summary: Implement the enricher using project base classes and Pydantic schemas, run work as Celery tasks, and add rate-control, idempotency and tests to ensure compatibility and reliability.

85.0%

✨ Highlights

  • Local-first data storage with privacy emphasis
  • Modular enricher ecosystem with broad coverage
  • Early-stage development with no releases or contributors
  • License unknown; legal/compliance risks not clarified

🔧 Engineering

  • Graph-based OSINT relationship visualization with automated enrichers
  • Modular architecture (core/types/enrichers/api/app) enabling extension and integration

⚠️ Risks

  • No releases and no active contributors — maintenance and security patching are uncertain
  • License not declared and contains sensitive capabilities — perform legal/compliance review before use

👥 For who?

  • Security analysts, OSINT researchers, and investigative journalists — favors self-hosted deployments
  • Suitable for teams or individuals with Docker/CLI and basic backend deployment skills