# Reconmap: engagement management for teams running many assessments

> Reconmap is a self-hosted platform for infosec teams and managed service providers that plans a scan, runs the tools on your own machines, parses the output, triages the findings, and writes the report, with a command catalogue and an LLM fallback parser doing the heavy lifting.

**reconmap/reconmap** — Reconmap is a collaboration-first security operations platform for infosec teams and MSSPs, enabling end‑to‑end engagement management, from reconnaissance through execution and reporting. With built-in command automation, output parsing, and AI‑assisted summaries, it delivers faster, more structured, and high‑quality security assessments.

- Repository: https://github.com/reconmap/reconmap
- Website: http://reconmap.com/
- Stars: 1,001 · Forks: 150
- Language: TypeScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/reconmap-reconmap

## The pitch is the whole pipeline, not a scanner

Reconmap is described as a collaboration-first security operations platform for infosec teams and managed service providers, and the summary line is AI-powered vulnerability scanning and reporting for teams running many engagements.

The one-paragraph description is the clearest statement of the design. Give it a target. Reconmap plans the scan, runs the tools, triages the findings and writes the report. Every engagement lives in one place, so your team spends its time on the work that needs a human.

That framing explains the scope, which is wider than a scanner. The feature list covers planning scans by entering a URL, domain, IP, or repository, where the AI picks the tools from your command catalog, orders them, and queues the run. It runs them anywhere, with runners executing commands on your own machines and sending the output back. It parses everything, with built-in parsers for SARIF, CycloneDX, Nmap, Testssl, Subfinder and more, and anything else going through the LLM parser. It triages automatically, giving every new finding a severity check, exploitability, affected surface, next steps, and a false-positive assessment. It writes the fix, generating remediation steps per vulnerability or suggesting next commands per asset. And it reports, exporting to Word, Markdown, or HTML.

The last two features are the ones that matter for a team with many engagements. Scales across engagements, with many projects, many people, and single sign-on through Keycloak. And bring your own model, with Ollama for fully local inference, or Azure OpenAI, OpenRouter, and other OpenAI-compatible endpoints.

The project is MIT licensed, the primary language is TypeScript, the home page is reconmap.com, and the last push to the repository was on 2026-10-15, with release 3.3.0 following on 2026-10-13.

## Four components, three languages

The under the hood table is the most useful thing in the README, because it tells you that this is not one application but a set of services with different jobs.

| Component | Stack | Path |
|---|---|---|
| Dashboard | React | src/dashboard |
| API | C# / .NET 10 | src/api |
| Runner (reconmapd) | Go | src/runner |
| CLI (rmap) | Go | src/cli |

The API is C# on .NET 10, the dashboard is React, and the two pieces that touch the outside world, the runner and the CLI, are Go. The runner is the interesting one. Runners execute commands on your own machines and send the output back, which means the tools run inside your network, on infrastructure you control, and the platform never needs a callback into a client network.

That is an architectural decision with a security consequence, and it is the reason the runner exists as a separate Go binary called reconmapd. The CLI, rmap, is the piece you drive from a terminal.

The backing services are PostgreSQL for data, Redis for cache, and Keycloak for auth. The compose file shows how they are assembled, and it is worth noting the versions. Redis is 8.8-alpine, RabbitMQ is 4.3-alpine, PostgreSQL is 18.6-alpine, and Keycloak is 26.8 from quay.io. RabbitMQ is not mentioned in the prose but appears in the compose file as a service, which suggests it is the queue between the API and the runners, and it is published on 5672. The compose file also defines named volumes for redis_data, postgres_varlib, dataprotection-keys, rustfs_data, and rustfs_logs, the last two pointing at an object store, presumably for the raw tool output and the generated reports.

The PostgreSQL service has a comment about PGDATA, because the PostgreSQL 18 images default it to a path inside the image rather than on the mounted volume, which is the kind of detail that silently loses your data on the first recreate.

## The quickstart, and the option to install nothing

The requirements are Docker and Docker Compose, and the start is one command.

```sh
docker compose up -d
```

Then you open http://localhost:5500.

The port number tells you something about the stack, because 5500 is not the API, the dashboard, or Keycloak. It is the edge of the stack, with the individual services behind it on the standard ports that the compose file lists, Redis on 6379, RabbitMQ on 5672, and PostgreSQL on 5432.

There is also a route for people who do not want to install anything. The README says to prefer not to install anything, try the live demo, or use the hosted version at netfoe.com. Given that the compose file brings up four backing services plus the application components, that option is a reasonable one for evaluating whether the platform fits before you commit to running it.

The repository carries two compose files, compose.yaml and compose.dev.yaml, which is the usual split for a production-shaped stack and a development variant. There is a .env file at the top level, a config-cli.json, config-ngapi.json, config-runner.json, and config-ui.json, so each of the four components has its own configuration file, and the environment variables for the secrets, Redis password, PostgreSQL users, and Keycloak bootstrap admin, are supplied through the environment rather than baked into the compose file.

There is also a testing/ directory and a DEVELOPMENT.md, and an AGENTS.md at the root, which is a newer convention for instructing coding agents working in a repository.

## The command catalog and the LLM fallback

The planning step is the part that makes this different from running a tool by hand, and it is worth thinking about what a command catalog implies.

The AI picks the tools from your command catalog, orders them, and queues the run. The catalog is yours, which means the set of tools and the flags they run with are under your control rather than embedded in the platform. That is the difference between a scanner that knows how to run nmap and a platform that knows how to run the commands you have told it about, in the order that makes sense for the target you gave it.

The parsing layer has a similar split. There are built-in parsers for the structured output formats, SARIF and CycloneDX, and for the specific tools, Nmap, Testssl, and Subfinder, and anything else goes through the LLM parser. The distinction is between a format you can parse deterministically and one you can only get a model to interpret, and the LLM parser is what makes the platform work with tools it has never seen.

The triage step is where the platform's judgement enters, and the README lists what every new finding gets: a severity check, exploitability, affected surface, next steps, and a false-positive assessment. The false-positive assessment is the interesting one, because in a service engagement most of the findings are noise, and a system that tells you which ones to ignore changes the economics of reviewing a scan.

The remediation side is symmetric. It can generate remediation steps per vulnerability, or suggest next commands per asset, which is how the tool supports the enumeration loop where a new asset leads to new commands.

And then there is the MCP server, which lets your AI assistant query and drive Reconmap. That is a small feature with a large implication, because it means the platform's data is addressable by the same kind of assistant that is doing the scanning.

## What the AI features mean for your data

The documentation section is short, and it points to a separate page for the part that matters most.

User, admin, and developer manuals are at reconmap.com, and for the AI side there is a dedicated document, docs/pages/user-manual/system/ai-features.md, for model setup and data handling. The split is deliberate. The fact that the model configuration and the data handling are documented separately from the rest of the platform is a signal about what the maintainers consider the sensitive part.

That matters because of what flows through this system. A scan of a client network produces findings, and the findings include hostnames, software versions, sometimes credentials found in configurations, and the text of web pages. The triage step sends findings to a model. The remediation step sends them to a model. If you use a hosted endpoint, that data leaves your environment.

The bring your own model option is what addresses this, and the README names the local option first. Ollama for fully local inference is the configuration where nothing leaves the machine, and that is the one to pick if the engagement is under an NDA or a contract that forbids it. The OpenAI-compatible endpoint options, Azure OpenAI and OpenRouter among them, are the ones to pick when you need a stronger model and your agreements permit it.

The policy/ directory at the top level of the repository is also worth noting. A platform that runs commands and processes findings will have policy files describing what it is allowed to do, and a data protection keys volume in the compose file suggests the data it holds is encrypted at rest with keys it manages separately. That is consistent with the design of a tool meant for engagements where the data is sensitive by definition.

## Conclusion

Adopt Reconmap if your team runs many client engagements and the repetitive parts are the bottleneck, since the plan-run-parse-triage-report pipeline is what it automates. Do not adopt it for a one-off assessment, where the deployment overhead outweighs the benefit. Verify first which model endpoint you will use and how the AI features handle your data, since that is documented separately from the rest of the platform.

## FAQ

### What does Reconmap actually do?

Give it a target and it plans the scan, runs the tools, triages the findings, and writes the report. You enter a URL, domain, IP, or repo, the AI picks tools from your command catalog, orders them, and queues the run, and every engagement lives in one place.

### How do I run Reconmap?

You need Docker and Docker Compose, then run docker compose up -d and open http://localhost:5500. If you would rather not install anything, the README points at a live demo and a hosted version at netfoe.com.

### Which tools does Reconmap support?

There are built-in parsers for SARIF, CycloneDX, Nmap, Testssl, and Subfinder, and anything else goes through the LLM parser. The commands themselves come from your own command catalog, so the set of tools and the flags they run with are under your control.

### Can I run the scans with a local model?

Yes. Bring your own model is a listed feature, and Ollama is named for fully local inference, alongside Azure OpenAI, OpenRouter, and other OpenAI-compatible endpoints. The documentation has a separate AI features page covering model setup and data handling.

### What are the components of the Reconmap stack?

A React dashboard in src/dashboard, a C# and .NET 10 API in src/api, a Go runner called reconmapd in src/runner, and a Go CLI called rmap in src/cli, backed by PostgreSQL for data, Redis for cache, and Keycloak for authentication.

## Sources

- [License: MIT](https://github.com/reconmap/reconmap/blob/main/LICENSE)
- [Project website](http://reconmap.com/)
- [README](https://github.com/reconmap/reconmap/blob/main/README.md)
- [reconmap/reconmap on GitHub](https://github.com/reconmap/reconmap)
- [Releases](https://github.com/reconmap/reconmap/releases)

---

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