# Hydra: a Maven multi-module skeleton whose working demo is three named tasks

> The Java framework is built around a JSON5 orchestration config that decides whether tasks run sequentially, in parallel, or in a loop, and the minimal system on disk runs three transactions called Jesus, Satan, and Rick. The default branch is beta, the docs are Chinese only, and the directory section is still a TODO.

**DragonKingpin/Hydra** — 为超级个体和一个人公司打造一个人的大厂，Hydra九头龙构筑大规模AI调度、数据采集、情报系统、数据平台、分析决策、产品生产的'军事'工业基座。

- Repository: https://github.com/DragonKingpin/Hydra
- Website: https://www.nutsky.com
- Stars: 396 · Forks: 28
- Language: Java
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/dragonkingpin-hydra

## Execution order is one Type field, and there are five accepted values

The whole scheduling model is visible in a configuration file rather than in code. Each task has an `Orchestration` block with a `Name` for its orchestrator, a `Type`, and a list of `Transactions`. The `Type` field carries a comment enumerating the accepted values:

```json5
    "Orchestration"         : {
      "Name": "ServgramOrchestrator",
      "Type": "Parallel", // Enum: { Sequential, Parallel, Loop }

      // Servgram-Classes scanning package-scopes
      "ServgramScopes": [
        "com.sauron.heist.heistron"
      ],

      "Transactions": [
        { "Name": "Heist", "Type": "Sequential", "Primary": true }
      ]
    }
```

The minimal system's own file lists a wider set in a different comment, with `Sequential`, `Parallel`, `SequentialActions`, `ParallelActions`, and `LoopActions`. So the granularity exists at two levels: whether a whole set of transactions runs one after another or concurrently, and whether the actions inside a transaction behave the same way. A transaction can also be marked `Primary`, which the first example does for `Heist`, which is the crawler and also the task started by default.

The scoping mechanism is separate from the type. `ServgramScopes` holds Java package names that are scanned, such as `com.sauron.heist.heistron`, which is how a task finds its own implementation classes rather than them being enumerated by hand.

## The default startup path is a crawler, and the demo underneath it is three named tasks

Running the jar starts `Heist`, which the documentation identifies as the crawler. Its own configuration file sits at `./system/setup/heist.json5` and changes the shape rather than just the values. It introduces `DirectlyLoad` with `Prefix` and `Suffix` lists, and here the prefix list is empty while the suffix is `[ "Heist" ]`. The effect is a class-loading rule: something ending in Heist is picked up directly, and the empty prefix means no additional qualifier is required in front of it.

The file also scans two package scopes, `com.sauron.shadow.heists` and `com.sauron.shadow.chronicle`, and its transaction list is commented as the place to edit to run the bundled example. Pointing it at `Void` gives you the smallest possible demonstration, and `Void` has its own file at `./system/setup/heists/Void.json5`:

```json5
    "Orchestration"         : {
        "Name": "VoidOrchestrator",
        "Type": "Parallel", // Enum: { Sequential, Parallel, Loop }

        "Transactions": [
          { "Name": "Jesus", "Type": "Sequential"  },
          { "Name": "Satan", "Type": "Sequential"  },
          { "Name": "Rick" , "Type": "Sequential"  }
        ]
    }
```

Three transactions, each `Sequential`, and the documentation notes that case matters in the path. On a normal start, a local pipeline runs those three tasks and their subtasks in order. The names are placeholders rather than anything semantic, which makes this the clearest thing in the repository for understanding how nesting works: an orchestrator of type Parallel whose children are each Sequential, one level down from a Parallel orchestrator whose single child is Primary.

## Configuration is JSON5 in ./system/setup, and no environment variable is needed

The deployment story is deliberately thin. The documentation states that no environment variables need to be configured, and that the system configuration files live by default under `./system/setup/`. Compilation produces a jar that is described as plug and play, and opening the project directly in IntelliJ IDEA is offered as an alternative to building at all.

The build itself is Maven with a JDK above 11. There is no wrapper script, no Dockerfile, and no compose file in the repository tree, so how a Java process finds its configuration is entirely by working directory rather than by a configured path. That is a real constraint for a system whose stated ambition is cluster-scale: the same jar assumes `./system/setup/` exists relative to wherever it is launched from.

JSON5 rather than plain JSON is a deliberate choice, since the configuration snippets in the documentation all carry trailing commas and comments inside the objects. Both the `Orchestration` blocks and the `Transactions` arrays use them, which means a standard JSON parser will reject these files. Any tooling you write that reads this configuration has to accept comments and trailing separators, or you have to strip them first.

The default configuration directory is also where the module registry is expected to live, so a deployment is a matter of assembling a tree of JSON5 files rather than editing one.

## The repository is a family of named modules, and Hydra is only one of them

The top level is where the scope of the ambition becomes visible, because the repository is not a single project. Alongside the `Hydra/` directory sit `Saurons/`, `Skynet/`, `Sparta/`, `Odin/`, `RedQueen/`, `Pinecones/`, `Titan/`, `Walnuts/`, `Archcraft/`, and `Aetherium/`, with `pom.xml` at the root and a shared `system/` directory. There is also an `assets/` directory, a `docs/` directory, a `CHANGELOG.md`, an `.idea/` directory committed to the tree, and a Windows batch file named `TestJar.cmd` alongside a `gitignore.txt`.

The names follow the same mythological register as the framework itself and as the demo transactions. That naming is consistent with the package names in the configuration, which use `com.sauron.` prefixes, and with the documentation, which frames the whole system as a personal version of a command and control apparatus: a central intelligence system, a central staff system, and what it calls firepower industrial plants. The documentation site is at docs.nutsky.com under a page named for one of the modules.

Two practical consequences follow from the structure. First, the `pom.xml` at the root means a build pulls in every module, so a change in any of them affects your compile even if you only intend to use one. Second, the committed `.idea/` directory means your IDE configuration comes from the repository unless you override it, which is a small friction point that most Java projects avoid by ignoring the directory.

The stated coverage of the platform is broad and worth reading as a design list rather than a feature list: distributed task scheduling with large scale concurrency, distributed service and device centres with lifecycle management, S3 style object storage with volumes and distributed buckets, remote control with a shell system and deployment tooling, and a messaging layer for broadcast.

## The documented use cases name specific targets, and the disclaimer is part of them

The scenarios section lists what the platform is meant to be pointed at, and the list is specific enough to be useful and specific enough to raise questions. Large scale collection is described as a unified parallel architecture, with named examples: full-site crawling of Wikipedia, full-site crawling of Urban Dictionary, IMDb scraping, a chronicle subproject that collects world news daily to build an internet memory and intelligence system, large scale financial data collection aimed at modelling money flow, and search engine infrastructure data including IP reverse lookup, ISP tracing, DNS and reverse DNS, domains, and NIC records.

A parenthetical note in that list is worth reading closely rather than skimming. It says that to avoid controversy, no controversial code and no controversial data are provided. That is a boundary statement about what the repository ships, and it is doing real work: the list describes capability while the disclaimer declines to supply the implementations.

The other scenarios sit at a higher level of abstraction. A large knowledge base that links a personal graph across finance, news, academia, games, music, film, video, novels, and food, then hands the result to a large model to generate a report. A data warehouse where historical change is navigable. A dataset market aimed at eventually training a personal model. A data platform that integrates other open source data products for ETL, warehouse, extraction, and intelligence work. And a middle platform layer that separates concerns for information, control, scheduling, audit, and permissions.

Whether any of those are implemented is a different question from whether they are described, and the repository's own directory section does not help: it is a single line reading TODO.

## Documentation, licence, and the state of the English page

The documentation situation is the first thing to check if you do not read Chinese. The README offers a language line where the Chinese version is marked as the current one and the English entry is annotated with a to-do marker. The main documentation lives at docs.nutsky.com on a page for the Hazelnut Sauron module, and it is described as continuously and incrementally updated, which is a promise about the pace rather than a statement about completeness.

A second link is pointed at as a record of the actual cluster build process, hosted as a long article on a Chinese blogging platform rather than inside the repository. That distinction matters: the repository is the framework, and the deployment story is a separate write-up.

The licence is MIT, described in the repository's own terms as permitting redistribution and modification once the licence is retained, with contributions invited. The project has no GitHub releases at all, and the default branch is `beta` rather than `main`, which is a signal about how the author is versioning. The changelog is a repository file rather than a release feed, so the two mechanisms that would normally tell you what changed do not exist here.

The reference section is unusual in a way that is worth noting rather than skipping. It lists fifteen sources the design draws on, including the C and C++ standard library, the Java JDK, the Go SDK, PHP 5.6 sources, MySQL sources, the Linux kernel, Windows 95 and NT internals, Boost, ACL, the Spring framework, Hadoop MapReduce, TensorFlow, and the JavaScript DOM and CSS selector design, followed by a general acknowledgement of smaller libraries. It reads as a statement of intellectual debt rather than a bibliography of dependencies.

## Conclusion

This suits a Java developer who wants a skeleton for distributed task scheduling and wants to see the configuration shape rather than a finished product, and who reads Chinese documentation without trouble. It is a poor fit if you need working collectors, since the crawling examples are named as use cases rather than shipped as code, and a poor fit if you need English docs, because the English README entry is marked as a to-do. Before you build, check three things: that you have a JDK above 11 and Maven, that you can read the JSON5 orchestration files, since the execution model lives entirely in their Type fields, and what the `Heist` default task actually does in your environment before you point a crawler at anything. The last push was 2026-07-17, the default branch is `beta` rather than `main`, and the repository publishes no GitHub releases.

## FAQ

### What is Hydra in DragonKingpin's repository?

It is a Java framework for large scale AI, data, and task scheduling that the author describes as a personal command and control platform. The repository is a Maven multi-module project and the default branch is beta.

### How do I run the minimal Hydra system?

Compile with Maven on a JDK above 11, then start the jar with no environment variables set. The default startup runs the Heist crawler task, and pointing the transaction list in ./system/setup/heist.json5 at Void runs the bundled demo with three sequential transactions instead.

### What do the Type values in the Hydra orchestration config do?

They control execution order. The values are Sequential, Parallel, and Loop at the orchestrator level, with SequentialActions, ParallelActions, and LoopActions also listed for transactions, so a parallel orchestrator can contain children that each run their own actions sequentially.

### Does Hydra come with working web crawlers?

The documentation names collection targets such as Wikipedia, Urban Dictionary, IMDb, daily world news, financial data, and DNS and ISP records as use cases, and adds that no controversial code and no controversial data are provided. What the repository ships is the framework and the Heist task name rather than those collectors.

## Sources

- [DragonKingpin/Hydra on GitHub](https://github.com/DragonKingpin/Hydra)
- [Issues](https://github.com/DragonKingpin/Hydra/issues)
- [License: MIT](https://github.com/DragonKingpin/Hydra/blob/beta/LICENSE)
- [Project website](https://www.nutsky.com)
- [README](https://github.com/DragonKingpin/Hydra/blob/beta/README.md)

---

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