Workflows Overview

#BountyHub Workflows

Workflows are the way you describe automation in BountyHub. They are written in a Starlark-based language — a small, safe, Python-like dialect — and they describe the way you hunt in a concise, declarative way.

Workflows act as if there were a replica of you doing the automated tasks continuously, feeding you information in real time, allowing you to do the best work you possibly can.

In bug bounty hunting, being the first one to find a bug is crucial. The faster you find a bug, the higher your chances of being the first to report it and get the bounty. Use workflows to your advantage, and let them work 24/7 for you.

#Workflow Concepts

Let's discuss the concepts that are important to understand when working with workflows.

#Workflow

A workflow is a single unit of automation. It describes the flow you take manually when hunting for bugs: enumerate subdomains, probe for live hosts, scan them, triage results, and notify yourself.

A workflow file is a Starlark program whose final value is a workflow(...) definition:

Most automation tools work in terms of pipelines, where you define a series of steps that execute in order. Execution is broken into stages, and each stage depends on the output of the previous stage.

Workflows are different. Workflows are continuous processes that keep running, always adapting to the latest data available. You define how you want to work, and the workflow continuously does it for you.

#Activities

A workflow is composed of activities. An activity is a named unit of work with its own triggers, conditions, environment, and steps. Think of an activity as one "phase" of your hunting process:

In this example:

• The discover activity runs when you dispatch it manually (for example, from the UI or CLI). It enumerates subdomains for the target domain stored in configuration.
• The probe activity triggers automatically whenever discover succeeds, and probes all discovered subdomains for live HTTP services.

Activities within a workflow run independently, driven purely by their triggers. This is what makes workflows continuous rather than linear: an activity can wait for an event, run on a cron schedule, and react to other activities finishing — all in the same definition.

#Steps

Steps are the individual units of execution inside an activity. BountyHub provides composable primitives instead of a single "run shell" escape hatch:

Every step supports a condition (cond) so you can skip steps based on what happened earlier in the run.

#Triggers

Triggers decide when an activity starts:

• trigger.cron("0 0 * * *") — run on a schedule.
• trigger.on(other_activity.succeeded()) — run when another activity finishes.
• trigger.dispatch(inputs = {...}) — start manually with input values.

Events can be combined declaratively with event.all(...) and event.any(...).

#Conditions

Conditions gate whether a step runs. The default is run.ok (run only if the run is healthy so far). You can also write conditions as lambdas that inspect the current run:

See the Syntax Reference for the full condition model.

#A Complete Example

Here is a realistic recon workflow that ties everything together:

Reading it top to bottom tells the story of a hunt: every night, subdomains are discovered and normalized; live hosts get probed; critical and high severity findings are collected; and you get pinged on Slack — potentially while your competitors are still setting up their tooling.

#Where To Go Next

• Syntax Reference — the complete language surface: workflow(), activity(), triggers, conditions, durations.
• Steps — running scripts and processes, and moving data with artifacts.
• Transforms — typed pipelines that keep your target lists clean.