Hydra tutorial series — Part 7: CI and deployment

In part 5 you ran Hydra by hand: build the images, run a stage with dev-run.sh, label an issue. That is the right way to learn Hydra, but it is not how it runs day to day. In production nobody starts containers from a terminal. Instead a scheduled flow notices the labelled issue and has each stage run for it, with no one at the keyboard. This part explains that path, where the pre-built images fit in, and the three deployment models behind it.

Same pipeline, different trigger

The personas, the gates and the no-loop rule from part 2 are the same locally and in production. What differs is who pulls the trigger, where the work runs, and what gets recorded:

So everything you learned about labels in parts 5 and 6 applies. You are just handing the steering wheel to the flows.

Trigger: flows, not Actions

Hydra's stage dispatch does not run in CI. It briefly did: hydra#448 (2026-07-31) ran the stage as an Actions job, hydra-stage.yml, and hydra#452 (2026-08-01) removed it again. (The older hydra-build.yml and hydra-review.yml had already been retired in May.) The people Hydra is built for have Nextcloud and LLM access on a Kubernetes environment someone else set up, and no forge account with Actions rights or cluster access of their own. So the stage now runs on what they already have: Nextcloud, OpenRegister flows and the hermiq ExApp, which runs each stage as claude -p in a checkout of the target repo. The flows live in hydra's flows/ folder:

• hydra-sequencer is the pipeline. It runs every five minutes and does one unit of work per tick: it resumes a review stage that is in flight, or else takes the first open issue in the ConductionNL organisation labelled applier:queued, then security-review:queued, then code-review:queued, then build:queued. It searches the whole organisation in one call rather than walking the repos one by one, and claims a slot from a shared pool of three before it starts work.
• hydra-dispatch claims a slot and runs one hermiq agent step for an issue it is handed. It does not search the forge and does not hand work to the sequencer.
• hydra-lock-reaper runs every ten minutes and clears stale per-issue locks.

Both hydra-sequencer and hydra-dispatch ship with enabled: false, so nothing runs until someone switches them on in the OpenRegister instance. And the flows check less than older docs claimed: no flow enforces a spec's depends_on list or keeps sibling specs from building at the same time.

What GitHub Actions still does is build the images, in .github/workflows/hydra-image.yml, on every push to main or development. Nothing else can build a container image, so that is the one CI job left.

The entry point is unchanged from part 1: a label on the issue (build:queued), not a person at a terminal. Same contract, different plumbing.

Images: the GitHub Container Registry

In a local run you build the images yourself (part 5). Wherever a stage runs as a container outside your laptop, that would waste minutes on every stage, so hydra-image.yml builds them once and pushes them to the GitHub Container Registry (GHCR): the hydra-nextcloud-test:stable32 base image first, then hydra-builder (which copies the Nextcloud tree out of that base), and hydra-reviewer and hydra-security alongside. The Kubernetes Jobs name these images directly. For the scripts on a host (manual-review.sh, the cron scripts), the naming is driven by two variables in secrets/.env:

# pull the published images; unset, the scripts use localhost/hydra and test (part 5)
HYDRA_IMAGE_PREFIX=ghcr.io/conductionnl/hydra
HYDRA_IMAGE_TAG=latest

dev-run.sh ignores both and always starts localhost/hydra-<stage>:test.

So the reviewer image resolves to ghcr.io/conductionnl/hydra-reviewer:latest, and the same for builder and security. (The applier image is not built by this workflow.) latest only moves when a release is published. Every push to main or development also publishes an immutable sha-<short> tag, and pinning HYDRA_IMAGE_TAG to one of those is how you freeze a known-good pipeline version instead of always tracking latest.

Credentials: a reference, not a token

Production Hydra never uses a shared org-admin token, and it never holds a forge token at all. Every issue, label, comment and pull-request call the flows make goes through one OpenConnector source, flows/hydra-forge.source.json. That source carries only a credentialRef: the id of a credential that lives in the broker (Doriath). The broker fills in the secret and sends the call, locked to api.github.com. What hydra stores is a uuid:

"authentication": {
  "credentialRef": { "credentialId": "{brokeredGithubCredentialId}" }
}

When the reference cannot be resolved, the run is refused. Nothing falls back to another token. The workload steps work the same way: they carry separate credential ids for reading the repo, for pushing, and for the model, and the push is done by the pipeline, so the agent that writes the code never holds a forge credential.

The Claude side follows the personal-scope rule from part 5: a Claude Max or Pro subscription may serve its owner, not an organisation. Hydra's part in that is making every stage say whose credential ran it:

1. The owner comes from the step that ran the stage. The hermiq workload step reports the stage's owner, together with credential_owner and credential_name. How hermiq resolves the owner is configured in hermiq, not in the hydra repo.
2. No owner, no record. hydra-record-stage refuses to record a stage without an owner, because "who ran this, on whose credential" cannot be recovered after the run.

hydra.json records those three fields on every stage entry. It never holds the token itself.

The three deployment models

Hydra's docs/deployment-models.md describes three ways to run it, in increasing operational weight.

Troubleshooting CI runs

Test yourself