> ## Documentation Index
> Fetch the complete documentation index at: https://docs.herodotus.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Ways to Run HDP

> Local execution, Atlantic proving, and HDP Server orchestration

There are three common ways to run HDP workflows.

## 1) Run locally (developer loop)

Best for fast iteration on module logic.

Core flow:

1. `hdp dry-run -m <compiled_module>.json --print_output`
2. `hdp fetch-proofs`
3. `hdp sound-run -m <compiled_module>.json --print_output`

Example (from [examples/eth\_call/run.sh](https://github.com/HerodotusDev/hdp-cairo/blob/main/examples/eth_call/run.sh)):

```bash theme={null}
scarb build -p example_eth_call && \
hdp dry-run -m target/dev/example_eth_call_module.compiled_contract_class.json --print_output && \
hdp fetch-proofs --mmr-deployment-config examples/eth_call/mmr_deployment_config.json && \
hdp sound-run -m target/dev/example_eth_call_module.compiled_contract_class.json --print_output --cairo_pie ./pie.zip
```

## 2) Prove with [Atlantic](/atlantic-api/introduction)

Best when you want managed proving and verification pipelines.

[Atlantic](/atlantic-api/introduction) can be used with different prover modes exposed in Atlantic docs (currently `stone` and `stwo`). This lets teams optimize for workflow needs without running prover infrastructure themselves.

Typical flow:

1. Produce trace/PIE from HDP run
2. Submit [Atlantic](/atlantic-api/introduction) query
3. Track query status and retrieve proof-related job details
4. Verify on chosen target (for example L1, L2, or off-chain mode depending on workflow)

Start here:

* [Atlantic Introduction](/atlantic-api/introduction)
* [Atlantic Getting Started](/atlantic-api/getting-started)
* [S-two on Atlantic](/atlantic-api/stwo)
* [Atlantic Query Jobs Endpoint](/atlantic-api/endpoints/get-query-jobs)

## 3) Use [HDP Server API](/data-processor-api/introduction) (orchestrated path)

Best when you want API-driven scheduling and lifecycle management from your backend.

This is **not** the same as [State Server](/data-processor/state-server):

* **HDP Server API** orchestrates HDP task execution lifecycle (`/tasks`, status, retries, outputs).
* **State Server** provides injected-state trie read/write/proof endpoints used in injected-state workflows.

Key endpoints:

* `POST /tasks` -> schedule a task
* `GET /tasks/{task_uuid}/status` -> track task status
* `GET /tasks/{task_uuid}/details` -> inspect execution metadata
* `POST /tasks/{task_uuid}/retry` -> retry failed tasks

Start here:

* [HDP Server Introduction](/data-processor-api/introduction)
* [Schedule a new task](/data-processor-api/create-task)
* [Get task status](/data-processor-api/task-status)
* [List tasks](/data-processor-api/list-tasks)
* [Get task details](/data-processor-api/get-task-details)
* [Get task state transitions](/data-processor-api/get-task-state-transitions)
* [Get task output preimage](/data-processor-api/get-task-output-preimage)
* [Get used MMRs](/data-processor-api/get-mmrs)
* [Retry task](/data-processor-api/retry-task)
* [Decommitment only](/data-processor-api/decommitment-only)

## Choosing the path

* Use **local HDP** for module development and testing.
* Use **[Atlantic](/atlantic-api/introduction)** for self-running but managed proving/verification.
* Use **[HDP Server](/data-processor-api/introduction)** for full managed orchestration including proving/verification with Atlantic.

Most teams combine all three: local dev loop -> [Atlantic](/atlantic-api/introduction)/[HDP Server](/data-processor-api/introduction) in staging and production.