Noureddine RAMDI / reNgine: A Django-based framework for customizable web reconnaissance pipelines

Reconnaissance in web security often means juggling a patchwork of tools to enumerate subdomains, scan ports, fuzz directories, and spot vulnerabilities. reNgine tackles this problem differently by offering a declarative YAML-based scan engine that lets you orchestrate multiple open-source security tools in customizable pipelines — all backed by a Django web interface and async task management. This approach streamlines complex recon workflows with concurrency controls and project organization, making it worth a look if you run penetration tests or security audits.

What reNgine does and how it works

At its core, reNgine is a reconnaissance framework built on Django. It acts as a centralized platform to run and coordinate many open-source security tools — everything from subdomain enumeration to vulnerability scanning and screenshot capture. It persists reconnaissance data in a PostgreSQL database, enabling correlation and historical tracking.

The web UI provides role-based access control with three roles: Sys Admin, Penetration Tester, and Auditor. This supports multi-user setups where permissions need to be carefully managed. The backend task execution uses Celery workers to run scans asynchronously, with parameters for controlling concurrency (MAX_CONCURRENCY and MIN_CONCURRENCY). This means the framework can scale task execution up or down depending on available resources and scan demand.

What really sets reNgine apart is its use of YAML files to define “scan engines.” These YAML configurations effectively act as a domain-specific language (DSL) for reconnaissance workflows. You specify which tools to run, in what order, with what parameters, and how to handle threading, timeouts, and rate limits. This declarative approach abstracts away a lot of scripting complexity and lets you build custom pipelines tailored to your target or program needs.

On top of the scanning capabilities, reNgine supports continuous monitoring, subscans for focused follow-ups, and automated report generation in PDF format with customizable templates. Version 2.2.0 adds features like Bounty Hub integration for syncing HackerOne programs, Chaos subdomain enumeration, and regex-based out-of-scope filtering — all pointing to a mature and actively developed project.

The technical strengths and tradeoffs

The codebase is surprisingly clean for a project coordinating so many external tools and workflows. Django handles the web UI and database interactions, while Celery manages asynchronous task execution. This separation of concerns is a solid architectural choice that fits the problem well.

The YAML-based scan engine configuration is the standout technical feature. It acts like a mini DSL, giving you granular control over how scans run. This includes thread management, task timeouts, and rate-limiting — all critical for reliable recon in the wild where APIs and services may throttle or block you.

The concurrency model via Celery workers is configurable, allowing operators to tune performance based on CPU cores and workload. This is important because recon tasks are often IO-bound but can saturate network or processing resources if not properly managed.

Of course, the tradeoff is complexity. Writing and maintaining YAML scan configs requires some upfront learning and discipline. The system also depends heavily on the quality and compatibility of the underlying open-source tools it orchestrates, so failures or inaccuracies in those tools can cascade.

The role-based access control adds security and operational rigor but also demands good user management in multi-tenant environments. The PostgreSQL backend enables powerful data correlation but requires a production-ready deployment setup.

Finally, the GPT-powered vulnerability report generation is a nice touch, automating mundane report writing. However, users should validate AI-generated content for accuracy and context.

Quick start

Quick Setup for Ubuntu/VPS

1. Clone the repository

   git clone https://github.com/yogeshojha/rengine && cd rengine
   

2. Configure the environment

   nano .env
   

   Ensure you change the POSTGRES_PASSWORD for security.

3. (Optional) For non-interactive install, set admin credentials in .env

   DJANGO_SUPERUSER_USERNAME=yourUsername
   DJANGO_SUPERUSER_EMAIL=YourMail@example.com
   DJANGO_SUPERUSER_PASSWORD=yourStrongPassword
   

   If you need to carry out a non-interactive installation, you can setup the login, email and password of the web interface admin directly from the .env file (instead of manually setting them from prompts during the installation process). This option can be interesting for automated installation (via ansible, vagrant, etc.).

   • DJANGO_SUPERUSER_USERNAME: web interface admin username (used to login to the web interface).

   • DJANGO_SUPERUSER_EMAIL: web interface admin email.

   • DJANGO_SUPERUSER_PASSWORD: web interface admin password (used to login to the web interface).

4. Adjust Celery worker scaling in .env

   MAX_CONCURRENCY=80
   MIN_CONCURRENCY=10
   

   MAX_CONCURRENCY: This parameter specifies the maximum number of reNgine’s concurrent Celery worker processes that can be spawned. In this case, it’s set to 80, meaning that the application can utilize up to 80 concurrent worker processes to execute tasks concurrently. This is useful for handling a high volume of scans or when you want to scale up processing power during periods of high demand. If you have more CPU cores, you will need to increase this for maximised performance.

   MIN_CONCURRENCY: On the other hand, MIN_CONCURRENCY specifies the minimum number of concurrent worker processes that should be maintained, even during periods of lower demand. In this example, it’s set to 10, which means that even when there are fewer tasks to process, at least 10 workers remain active.

verdict

reNgine is a solid choice if you need a self-hosted, extensible reconnaissance framework that can orchestrate multiple open-source tools with fine-grained control over concurrency and workflow logic. Its YAML-driven scan engine configs are powerful but require some investment to master.

It’s well suited for security teams or penetration testers who want a unified platform with role-based access control and project organization. The async task model and PostgreSQL backend make it viable for real-world scanning workloads, though you’ll need to ensure you have the infrastructure and operational expertise to run it smoothly.

If you prefer an out-of-the-box scanner with minimal configuration, reNgine might feel heavyweight or complex. But if you want to build custom recon pipelines tuned to your targets and integrate various tools under one roof, it’s worth exploring.

Related Articles

• Maigret: A resilient OSINT username scraper across thousands of sites — Maigret is a Python-based OSINT tool that scrapes public profiles by username from 3,000+ sites without API keys. It fea
• Agno: Building production-ready agentic software with minimal code — Agno provides a minimal, production-ready Python framework for scalable agentic software with per-user isolation and nat
• Camoufox: a stealthy Firefox fork for AI agents and web scraping — Camoufox is a Firefox fork optimized for AI agents and web scraping with stealth fingerprint injection at the C++ level
• Inside Grafana: a modular platform for monitoring and observability — Grafana is an open-source monitoring platform with an extensible plugin architecture enabling diverse data source integr
• Jan: a local-first desktop app for large language models with Tauri and Rust — Jan is an open-source desktop app that runs large language models locally using Tauri, Node.js, and Rust. It offers priv

→ GitHub Repo: yogeshojha/rengine ⭐ 8,621 · HTML