# Recon-ng: modular Python OSINT framework with Docker deployment and a Metasploit-style interface

> Recon-ng is a GPL-3.0 Python framework for web-based open source intelligence gathering, structured like Metasploit but scoped exclusively to reconnaissance. It deploys as a three-service Docker stack, but documentation lives on the GitHub Wiki rather than in the README.

**lanmaster53/recon-ng** — Open Source Intelligence gathering tool aimed at reducing the time spent harvesting information from open sources.

- Repository: https://github.com/lanmaster53/recon-ng
- Stars: 5,987 · Forks: 931
- Language: Python
- License: GPL-3.0
- Published: 2026-10-11 · Updated: 2026-10-11 · Language: en
- Canonical page: https://hysenlabs.com/projects/lanmaster53-recon-ng

## Web-based OSINT collection and the Metasploit comparison the README draws

Recon-ng is aimed at reducing the time spent harvesting information from open sources. Web-based public data is its domain: the README describes it as designed exclusively for web-based open source reconnaissance. Security practitioners who already use Metasploit get a familiar interaction model, because the interface was built with that framework's look and feel in mind.

The README draws a boundary explicitly. Exploitation belongs to Metasploit; social engineering belongs to the Social-Engineer Toolkit; reconnaissance belongs to Recon-ng. Those three tools are positioned as complementary rather than overlapping, and Recon-ng makes no claim to cover the other two phases.

That boundary has a practical implication for any workflow. A team using Recon-ng in an OSINT engagement still needs separate tooling for the stages that follow. Data gathered through Recon-ng does not hand off to Metasploit automatically; the connection between reconnaissance and exploitation is outside Recon-ng's stated scope.

## Docker stack: web interface on port 5000, worker queue and Redis backend

The repository includes a docker-compose.yml that defines three services: web, worker and redis. The web service builds from the local Dockerfile and runs recon-web:

```yaml
web:
    build: .
    image: recon-ng
    ports:
        - '5000:5000'
    command: python3 ./recon-web --host 0.0.0.0
    environment:
        - REDIS_URL=redis://redis:6379/0
    depends_on:
        - redis
```

The web service listens on port 5000 on all interfaces (0.0.0.0) and connects to Redis via the REDIS_URL environment variable. Running docker compose up starts the full stack and makes the web interface accessible at port 5000.

Both the web and worker services mount two volumes: the repository directory at /recon-ng and the user's ~/.recon-ng directory at /root/.recon-ng. User data and configuration persist across container restarts through the second mount.

The worker depends on both redis and web before starting. The web service depends only on redis, which means the startup order is: redis first, then web, then worker.

## The Dockerfile: python:3.7-alpine and the build-time dependency removal pattern

Recon-ng's Dockerfile uses python:3.7-alpine as the base image. The README makes no mention of the Python version requirement; the Dockerfile is the only place in the repository that documents it. A reader checking the docker-compose.yml sees `version: '3.7'` at the top, but that is the Compose file format version, not the Python version. Both happen to be 3.7, which a quick scan could conflate.

The Dockerfile's build sequence separates compile-time and runtime dependencies:

```dockerfile
RUN apk add --no-cache --virtual .build-deps gcc libc-dev libxslt-dev &&\
    apk add --no-cache libxslt &&\
    pip install --no-cache-dir -r REQUIREMENTS &&\
    apk del .build-deps
```

gcc, libc-dev and libxslt-dev are installed as a virtual group called .build-deps, used for compiling any pip dependencies that need native extensions, then removed. Only libxslt remains as a runtime library. pip installs from a REQUIREMENTS file in the repository root. The result is an image that carries only what the application needs at runtime.

## Three entry points at the repository root: recon-ng, recon-cli and recon-web

The top-level directory contains three named executables alongside the Dockerfile and configuration files: recon-ng, recon-cli and recon-web. Each represents a different interaction mode.

recon-web is the file the Docker web service runs: `python3 ./recon-web --host 0.0.0.0`. It provides the browser-accessible interface on port 5000. recon-ng and recon-cli are the command-line paths, meaning the framework can be operated without Docker by running either of those directly.

Having two CLI entry points (recon-ng and recon-cli) alongside the web interface means different workflows are supported: interactive terminal sessions, scripted invocation and web-based operation. The README does not describe the differences between recon-ng and recon-cli specifically; the GitHub Wiki is where those distinctions are documented.

The recon/ directory at the top level holds the framework's core code, and inspecting it directly gives a concrete view of how modules are organized and which data sources the current build covers, without relying on documentation that may lag the code.

## The rq task queue on Redis: asynchronous module execution in the worker service

The worker service runs against a Redis queue named recon-tasks:

```bash
rq worker -u redis://redis:6379/0 recon-tasks
```

rq (Redis Queue) is the task distribution library that connects the two containers. When a reconnaissance module submits a job, it goes into the recon-tasks queue and the worker picks it up for execution, which means individual modules run outside the web process rather than blocking the interface during collection.

The architecture has a specific constraint: both the web and worker containers need to reach the same Redis instance. In the docker-compose.yml, that is the redis service. Any deployment that splits these services across different hosts needs to ensure the REDIS_URL environment variable points to a shared Redis instance reachable by both containers.

If the worker is not running, tasks submitted through the web interface will sit in the queue without being processed. The docker-compose.yml starts the worker automatically, but in a deployment where only the web service is run, queue processing stops.

## A modular Python framework: the Development Guide and the contributor path

The README describes Recon-ng as completely modular and claims contribution is accessible for even the newest Python developers. The GitHub Wiki hosts a Development Guide that covers building and maintaining modules.

Modularity at this level means adding a new data source is a module-writing task rather than a change to the framework core. What the framework's module API looks like, what data it expects modules to return, and how results are stored are all in the Development Guide rather than the README.

Black Hills Information Security is named as a sponsor. Beyond that credit, the project's financial support comes from individual donations. That governance model, a single-author project supported by sponsorship and donations, means feature decisions and the roadmap depend on one maintainer's priorities.

With no GitHub releases available, there is no tagged version to reference in a dependency lock file or a deployment manifest; the last push to the repository was on 2026-10-05.

## Metasploit for exploitation, SET for social engineering: Recon-ng's scope boundary

The README's own framing gives the most direct picture of what Recon-ng is not. For exploitation, use the Metasploit Framework; for social engineering, use the Social-Engineer Toolkit. Recon-ng's position is upstream of both: it gathers the information that those tools might later act on.

For users already working in a Metasploit-centric workflow, the interface familiarity reduces the cost of adding a dedicated OSINT phase. The Metasploit paradigm of modules, options and workspaces maps onto Recon-ng's design, even though the underlying goals are different. One tool runs exploits; the other collects open source data.

That scope boundary also describes where Recon-ng falls short as a replacement for a general-purpose framework. It is not designed to do more than reconnaissance. A project that needs automated data collection from public web sources followed by structured reporting and handoff to other tools is the right context for Recon-ng. A project that needs a single tool covering multiple attack phases is looking for something else.

## Conclusion

Recon-ng fits teams that need a structured OSINT collection environment with a module-based workflow they can extend in Python. The Metasploit-like interface reduces orientation time for practitioners already familiar with that framework. Do not treat the repository README as a setup guide: documentation lives on the GitHub Wiki, and the Dockerfile pins python:3.7-alpine as the base image. Before deploying, review the REQUIREMENTS file and visit the GitHub Wiki to understand the current module list and the framework's data model.

## FAQ

### What is Recon-ng used for?

Recon-ng is used for open source web-based reconnaissance: collecting publicly available information to reduce the time spent harvesting from open sources. It is scoped to the intelligence gathering phase, separate from exploitation or social engineering.

### How do I run Recon-ng with Docker?

The repository includes a docker-compose.yml that starts three services: web, worker and redis. Running docker compose up starts the stack; the web interface is then available on port 5000. User data persists in the ~/.recon-ng directory on the host.

### What Python version does Recon-ng use?

The Dockerfile uses python:3.7-alpine as the base image. The README does not document a Python version requirement; the Dockerfile is the only place in the repository where this is stated.

### What is the difference between Recon-ng and Metasploit?

The README states that Recon-ng is designed exclusively for web-based open source reconnaissance and is not intended to compete with Metasploit. For exploitation, the README directs users to Metasploit; Recon-ng covers only the reconnaissance phase that precedes exploitation.

### Is Recon-ng open source?

Yes, under GPL-3.0, which is stated in the LICENSE file at the repository root. Documentation and contribution guidelines are on the GitHub Wiki.

## Sources

- [Issues](https://github.com/lanmaster53/recon-ng/issues)
- [lanmaster53/recon-ng on GitHub](https://github.com/lanmaster53/recon-ng)
- [License: GPL-3.0](https://github.com/lanmaster53/recon-ng/blob/master/LICENSE)
- [README](https://github.com/lanmaster53/recon-ng/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lanmaster53-recon-ng