Osmedeus v5: A Declarative Workflow Engine That Treats Recon as Code
A Modern Orchestration Engine for Security
At a glance
- What is it?
- Osmedeus is a Go-based orchestration engine that turns security workflows into auditable YAML, with Redis-backed distributed execution and optional LLM agent steps. This review covers what it actually does, how to run it, and where its complexity will bite.
- Who is it for?
- Adopt Osmedeus if you run recurring reconnaissance or attack-surface scans and want those pipelines versioned as YAML rather than glued-together shell scripts. It suits teams that already use Docker or SSH runners and can tolerate a Redis dependency.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Recon Scripts That Rot and Cannot Be Audited
The key shift is from imperative to declarative. Instead of saying "run this, then that," you describe what should happen and let the engine decide the execution details. The README emphasizes "auditable YAML definitions," which means every workflow change is a diff you can review. For a security tool, that is a genuine advantage. You can see exactly what a workflow will do before it runs, and the dry-run flag exists precisely for that preview.
Architecture: Orchestration, Not Another Scanner
The event-driven scheduling layer adds cron, file-watch, and event triggers with filtering and deduplication. That positions Osmedeus as a long-running service rather than a one-shot script. You can queue work, process it later, and query the results through a CLI or REST API. The README shows a web UI with workflow visualization and vulnerability views, which suggests a monitoring surface for ongoing operations. The architecture is closer to a CI/CD system for security than to a traditional recon tool.
Getting It Running: Commands and Config Keys
The CLI has a broader surface. `osmedeus workflow list` shows available workflows. Asset queries use `osmedeus assets -w example.com`, with filters like `--source httpx --type web --json`. Vulnerability queries use `osmedeus query vulns --severity high --workspace example.com`. There is a database layer: `osmedeus db list --table runs`. For testing utility functions, `osmedeus func eval 'log_info("hello")'` evaluates expressions, and platform variables like `PlatformOS` are available. Worker management includes `osmedeus worker queue new` and `osmedeus worker queue run --concurrency 5`. Cloud provisioning is `osmedeus cloud create --instances 3`. The breadth is impressive but also a warning: this is not a tool you master in an afternoon.
The LLM and Agentic Layer: Useful or Gimmick?
That is a double-edged sword. On one hand, it allows natural-language interaction with the workflow engine, which could lower the barrier for less technical users. On the other hand, LLM-driven steps introduce nondeterminism into a security pipeline. If you need reproducible scans for compliance or regression testing, an agent that decides its own next step is a liability. The README does not specify how the engine validates LLM output or prevents prompt injection from target content. That is a genuine gap. For bug bounty, where targets may be hostile, letting an agent parse web content and make tool calls is risky. The ACP subprocess agents run external tools like Claude Code, which expands the attack surface. This feature is optional, but its presence means Osmedeus is trying to be both a deterministic orchestrator and an AI playground. Those two goals can conflict.
Distributed Execution: Power and Operational Cost
But distributed execution has a cost. You must deploy and maintain Redis. You must manage worker registration and network connectivity. The README does not provide a docker-compose file or a Helm chart; it assumes you can set up the infrastructure yourself. For a solo bug bounty hunter, running Redis just to scan a few domains might be overkill. The local mode (`osmedeus run` without workers) exists, but the engine's design clearly favors the distributed model. If you only need single-host scans, a simpler tool like nuclei or a custom script would have less operational overhead.
Cloud Provisioning: Convenience with a Cost Warning
The trade-off is that you are granting Osmedeus API credentials to your cloud providers. The README does not detail how those credentials are stored or encrypted, despite the project claiming "encrypted data handling" and "secure credential management." You should verify that claim in the documentation before pointing it at production cloud accounts. The automatic cleanup is a good safety net, but it depends on the engine correctly identifying instances it created. If a cleanup step fails, you are left with running instances. The cloud feature is powerful, but it demands trust in the tool's credential handling and lifecycle management.
Maintenance and Upgrade Cost: What the Repo Tells Us
The license is MIT, which is permissive for commercial use and modification. That is a positive for adoption because you can vendor the tool or embed it in your own products without copyleft obligations. However, MIT also means no warranty. The project depends on external tools (nmap, httpx, nuclei) that have their own licenses and update cycles. As a workflow engine, Osmedeus's maintenance burden is tied to those dependencies. When a tool changes its output format, your workflows may break. The documentation site is the place to check for migration guides between major versions, but the README does not mention any. The v5 line is relatively new, so expect breaking changes as the API stabilizes.
Alternatives: How It Differs from Simpler Orchestrators
A real alternative in the same space is `reNgine`, an open-source recon platform that provides a web UI and scheduled scans. reNgine is more turnkey: you install it and get a dashboard, whereas Osmedeus requires you to define workflows and understand the CLI. However, reNgine is less flexible for custom pipelines and does not offer the same distributed worker model. Osmedeus's advantage is its declarative YAML and runner abstraction. Its disadvantage is that you must build your own workflows from scratch or install presets. If you want a ready-made recon suite, reNgine might be easier. If you want to codify your own exact process, Osmedeus gives you the levers.
Editorial conclusion
Adopt Osmedeus if you run recurring reconnaissance or attack-surface scans and want those pipelines versioned as YAML rather than glued-together shell scripts. It suits teams that already use Docker or SSH runners and can tolerate a Redis dependency. Avoid it if you need a point-and-click scanner or if your environment forbids cloud provisioning and external agent subprocesses. Before committing, verify that the v5 workflow syntax matches your existing modules, test the dry-run mode on a non-production target, and confirm the MIT license fits your redistribution policy. The project is actively maintained, with v5.1.0 released in August 2026, but the breadth of features means you should budget time for learning the CLI and reading the docs at docs.osmedeus.org.
Community notes