Skip to main content
reNgine Cloud > Configuration

Understanding and Customizing Scan Engines in reNgine Cloud

Last updated April 8, 2026

Scan engines define what tools reNgine runs during reconnaissance and in what order. This guide explains the built-in engines and how to create custom ones.

What Is a Scan Engine?

A scan engine is a YAML configuration that specifies which reconnaissance tools to run, their parameters, and the execution order. Each scan in reNgine uses exactly one engine.

Built-In Engines

reNgine ships with several pre-configured engines:

Engine Description Use Case
Initial Scan - reNgine Recommended Subdomain discovery, HTTP probing, OSINT, WAF detection, URL extraction, screenshots First scan of a new target
Initial Scan - Passive DNS enumeration, certificate transparency, WHOIS — no active probing Stealth reconnaissance
Passive with Screenshots Passive scan plus screenshot capture of discovered hosts Quick visual overview
Scan - Active Full scan: port scanning, vulnerability detection, directory fuzzing Deep assessment

Creating a Custom Engine

  1. Go to Scan Engines in the sidebar.
  2. Click Add New Engine.
  3. Provide a Name and optional Description.
  4. Edit the YAML configuration to define your tool pipeline.

Engine YAML Structure

subdomain_discovery:
  uses_tools:
    - subfinder
    - ctfr
    - sublist3r
  threads: 30
  timeout: 300

http_crawl:
  uses_tools:
    - httpx
  threads: 50
  timeout: 300
  custom_header: "User-Agent: Mozilla/5.0"

port_scan:
  enable: true
  uses_tools:
    - naabu
  ports: top-1000
  threads: 25
  timeout: 600

vulnerability_scan:
  enable: true
  uses_tools:
    - nuclei
  severity: critical, high, medium
  concurrency: 25
  timeout: 900

screenshot:
  enable: true
  uses_tools:
    - eyewitness
  timeout: 300

Key Configuration Options

  • threads — Controls concurrency for each tool. Higher values are faster but use more resources.
  • timeout — Maximum seconds for each phase. Increase for large targets.
  • ports — For port scanning: top-100, top-1000, full (all 65535), or a custom list.
  • severity — For vulnerability scanning: filter by critical, high, medium, low, info.

Tuning for Performance

Small Targets (single domain, <50 subdomains)

Use the default recommended engine. Scans typically complete in 10-20 minutes.

Large Targets (100+ subdomains)

  • Increase timeouts to 600-900 seconds per phase.
  • Reduce thread counts if the VM runs low on memory.
  • Consider splitting the scan into passive (first) and active (follow-up).

Resource-Constrained VMs

  • Disable screenshot capture (most resource-intensive phase).
  • Use top-100 ports instead of top-1000.
  • Lower nuclei concurrency to 10.

Troubleshooting

Scan phase times out Increase the timeout value for that phase. Check docker stats to verify the VM has sufficient CPU and memory.

Nuclei finding too many false positives Restrict severity to critical, high and update nuclei templates: docker exec -it nuclei nuclei -update-templates.

Custom engine not appearing Ensure the YAML is valid (no tab characters — use spaces only). Check for syntax errors in the reNgine logs: docker compose logs web.


Still need help? Open a ticket at support.hailbytes.com.