reNgine: self-hosted web reconnaissance with configurable scan engines

What reNgine is for, and who it fits

Running recon by hand means chaining subdomain enumeration, port checks, endpoint collection, directory fuzzing, screenshots and vulnerability scans, then keeping track of which output came from which target on which day. reNgine exists to hold that chain together. The README describes it as an "automated reconnaissance framework for web applications" with a focus on a configurable recon process, data correlation and organization, continuous monitoring, and a database behind an intuitive UI. The stated audience is security professionals, penetration testers and bug bounty hunters, and the README also names corporate security teams.

The design bet is that recon output is worth keeping. A one-shot scanner prints results and forgets them. reNgine writes them into Postgres, so a subdomain found in one scan is still there when a later scan adds an endpoint or a screenshot. That is what makes continuous monitoring possible rather than a marketing word: the framework can compare a new run against what it already knows for the same target.

It is not a one-command CLI. The repository is a Django application with Celery workers, Redis as broker, Postgres 12.3 as the store, and a proxy service, all wired together in docker-compose.yml. If your recon workflow is a shell script you run from a laptop, reNgine is more machinery than that job needs.

How the scan engines, Celery workers and Postgres fit together

The architecture is visible in the compose file. A db service runs postgres:12.3-alpine with a named volume at /var/lib/postgresql/data/ and binds 127.0.0.1:5432:5432, so the database is not exposed beyond the host. A redis service runs redis:alpine and acts as both broker and result backend, since the celery service sets CELERY_BROKER and CELERY_BACKEND to redis://redis:6379/0. The celery service builds from ./web and starts through /usr/src/app/celery-entrypoint.sh, with MAX_CONCURRENCY and MIN_CONCURRENCY passed in from the environment. That is the worker pool that actually runs scans.

A separate celery-beat service runs celery -A reNgine beat with the django_celery_beat DatabaseScheduler. That is the scheduling half of continuous monitoring: periodic scans are stored in the database rather than in a static crontab, which is why they survive a restart and can be edited from the UI.

The configuration layer is the part worth understanding before you install. The repository root holds default_yaml_config.yaml, and the README describes "highly configurable engines". A scan engine is therefore a YAML description of which tools run in which order, not a compiled-in pipeline. You can change the tool list without touching Python. The same idea appears in the scope handling: the 2.2.0 release notes mention support for regex in the out-of-scope subdomain configuration, which means exclusions are patterns rather than exact hostnames.

Data flows one way. The web service queues a scan, Celery picks it up, tools write into mounted volumes (scan_results, wordlist, gf_patterns, nuclei_templates, tool_config), and results are recorded in Postgres for the UI to display. Mounting gf_patterns at /root/.gf and nuclei_templates at /root/nuclei-templates means the container inherits host-side template and pattern directories instead of rebuilding the image when you add one.

Installing reNgine with Docker Compose and running a first scan

The README points to https://rengine.wiki for full documentation and to a Quick Installation section, and the repository ships install.sh, update.sh, a Makefile and a docker-compose.setup.yml alongside the main compose file. The Makefile is the intended entry point. It includes .env, defines the service list as db web proxy redis celery celery-beat ollama, and picks docker compose or docker-compose depending on what the host provides.

Certificates come first. The certs target runs the certs service from docker-compose.setup.yml in a one-off container.

make certs

Then bring the stack up. This builds the images and starts all services in detached mode.

make up

Once the containers are running, create the login you will use for the UI.

make username

The Makefile shows that this target either runs createsuperuser interactively or, when isNonInteractive is true, passes DJANGO_SUPERUSER_USERNAME and DJANGO_SUPERUSER_EMAIL with --noinput. The same file provides changepassword, migrate and logs targets, and update.sh exists for pulling a newer release.

Before any of that, the compose file expects values that are not in the repository: POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_PORT, POSTGRES_HOST, DOMAIN_NAME, MAX_CONCURRENCY and MIN_CONCURRENCY all come from the environment, and the Makefile reads .env. A .env file is present at the repository root, so the shape is known, but you should read it and set the database credentials and domain yourself rather than shipping defaults. After that, the first real use is a single target: log in, create a project, add the domain, attach an engine, and start the scan. The README does not document a rollback or cancel path for a running scan, so plan the first run against a domain you are authorised to test and can afford to scan slowly.

Where reNgine gets in your way

The resource footprint is the first constraint. This is Postgres, Redis, a Django web app, at least one Celery worker, a beat scheduler, a proxy and an ollama service. The Makefile lists ollama among the services it starts, which is a language-model runtime, so a default `make up` pulls more than a recon tool. On a small VPS that matters. The compose file exposes concurrency knobs (MAX_CONCURRENCY, MIN_CONCURRENCY) precisely because the default worker count is a tuning decision, not a fixed answer.

Deployment is Linux-shaped. The Makefile is written for make, and while make.bat exists at the root, the README's installation path is the wiki's quick install, which the repository's own files assume a Compose-capable host. If your working machine is Windows, the practical route is a Linux host or VM rather than the desktop you browse from.

Scope is web application reconnaissance. The README lists subdomain discovery, IP and open port identification, endpoint collection, directory and file fuzzing, screenshots, vulnerability scans, WHOIS, WAF detection, misconfigured S3 bucket detection and keyword-based URL discovery. Nothing there covers internal network segmentation testing, Active Directory enumeration or exploit delivery. If your engagement is host-based rather than web-facing, this is the wrong tool and no amount of engine configuration changes that.

Finally, the correlation is only as good as your target definitions. Two projects that describe the same estate differently will not be correlated for you.

reNgine against running the underlying tools yourself

The honest alternative is not a single product. It is the set of command-line tools reNgine orchestrates, driven by your own scripts. That approach has real advantages: no database to maintain, no containers to update, no web UI to secure, and every intermediate file available for inspection. It also has the cost reNgine was built to remove, which is that correlation between runs is manual and continuous monitoring means a cron job you wrote and now have to debug.

A closer comparison is a hosted attack surface management product. Those give you the same continuous view without running infrastructure, and they are commercial. The README positions reNgine as an alternative to commercial tools and says it was created to address the limitations of traditional reconnaissance tools, which is the project's own framing rather than a measured claim. What is verifiable from the repository is the difference in control: with reNgine the engine definitions, wordlists, nuclei templates and gf patterns are files on your disk, mounted into the containers, so you can change what runs. With a hosted product you get the vendor's pipeline.

There is also a middle path worth naming: run the individual tools and push their output into a small database of your own. That gets you correlation without the Django stack. It is more work up front and less work every time you need to change a scan step.

Maintenance, licence and the upgrade path

The last push to the repository was on 2026-09-21, and the most recent release listed is v2.2.0 from 2024-09-07, following v2.1.3 and v2.1.2 in the weeks before it. So the release cadence is not weekly, and the code moves between tagged versions. That matters for upgrades: update.sh exists, but the gap between v2.2.0 and current master means you should read the CHANGELOG.md before pulling, particularly if you have edited engine YAML or added patterns to the mounted directories.

Upgrade cost is mostly container rebuild plus database migration. The Makefile exposes a migrate target that runs manage.py migrate inside the web container, which tells you migrations are part of the normal flow rather than something the entrypoint hides. The named volumes (postgres_data, scan_results, wordlist, gf_patterns, nuclei_templates, tool_config) are where your state lives, so a rebuild that recreates containers without removing volumes should preserve scan history and your custom patterns. The README and the Makefile do not document a downgrade path, so treat a version bump as one-way unless you have taken a database dump first.

On licensing, the repository carries GPL-3.0. That is a copyleft licence, and the practical question for a corporate team is not whether you may run reNgine internally, which the licence permits, but what happens if you modify it and distribute the result or offer it as a service. This is a question for your own counsel; the repository states the licence and nothing more.

Editorial conclusion

Adopt reNgine if you want a persistent, queryable recon database behind a web UI and you are willing to run Docker Compose on a Linux host. Skip it if you need a single-binary scanner, cannot give the stack a real machine, or want a tool that stays out of the way while you drive each CLI yourself. Before committing, read the .env file for the POSTGRES_* and DOMAIN_NAME values the compose file expects, and confirm that the Makefile targets match the Docker Compose command your host provides. The project is GPL-3.0, so check how that interacts with anything you plan to redistribute.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. yogeshojha/rengine on GitHub