Releases

A release is a record that a specific commit produced a specific container image, via a specific build. It is a fact, not an action: nothing is deployed when a release is written.

If a build is the meal, a release is the receipt: this commit, this image, this digest, at this time.

Loha writes a release automatically whenever a build finishes successfully and pushed at least one image. There is nothing to enable and nothing to configure. A build that only lints or tests produces no release, which is correct: it produced no artifact.

What a release records

Field	What it is
Service	Which image this is, within the repository (see Services below).
Commit	The commit the build ran against.
Image	The image repository it was pushed to, without a tag.
Digest	The sha256:… manifest digest of exactly the image that was pushed.
Build	The build that produced it. Click a release row to open it.
Created	When the release was recorded.

The digest is the point

A tag moves. myapp:latest means something different next week, and even myapp:v1.2.3 can be overwritten by a re-push. A digest does not move: sha256:abc… names exactly one image, permanently.

Join the image and the digest with @ to get a reference you can deploy with confidence:

harbor.example.com/acme/api@sha256:9f2c…

That is what the Images produced section on a build page shows, in full, so you can copy it.

Services

A service is the durable thing a release groups under: one per image a repository publishes.

Most repositories publish one image and therefore have one service. But a repository that builds two images (say an API and a web frontend) has two services, and each successful build writes two releases, one per image. That is why the Releases list has a Service column: two rows from the same build share a commit and a timestamp, and the service is what tells them apart.

A service's name is the last part of its image reference, so harbor.example.com/acme/api shows as api. It is a display name only. Two registries can host the same name without conflict.

Same reference, different tags

Two build steps pushing different tags of the same image reference (app:v1 and app:latest) are one service, and record one release. The reference is what identifies a service; the tag is not part of it.

Where to find them

Releases appear in three places, all read-only:

• Workspace → Releases: everything the workspace has shipped, newest first, with the repository named on every row. The answer to "what shipped today?"
• Project → Releases: the same list narrowed to one team's repositories.
• A repository → Releases tab: just that repo's, with no Repository column since every row would repeat it.

A build page also shows Images produced (the releases that build wrote), so you can go from a green build straight to the digest it produced. Clicking a release row goes the other way, to the build that made it.

Lists are paginated, newest first. Releases from a single build all share a timestamp, so they are ordered by image reference within a build to keep paging stable.

Releases outlive their builds

Build records are pruned by your plan's retention window. Releases are not. When a build is swept, its releases survive; only the link back to it is cleared, and the release row keeps showing the commit, image and digest.

This is deliberate. The commit-to-digest provenance is the whole reason the record exists, and it would be worthless if it disappeared on a schedule. A release you shipped six months ago is still exactly as findable as yesterday's.

From the API, CLI, and agents

Releases are readable outside the dashboard:

• GET /api/v1/releases: filter by repositoryId, projectId, or buildId; paginated. Scope: repos:read. See the API reference.
• loha releases: the same list in your terminal, with --repo, --project, --build and --json. See the CLI reference.
• list_releases: the MCP tool, so an agent can answer "what image is running from commit X?" without you pasting anything.

There is no write route, and there will not be one: Loha writes releases itself when a build pushes an image.

Subscribe to releases

An outbound webhook can subscribe to com.loha.release.produced.v1 and receive one event per successful build that pushed images, listing every image and its digest. It is the "an image shipped, go deploy it" hook. See Outbound webhooks.

What releases are not

Loha does not deploy a release. There is no Promote button, no environments, and no rollback: a release records what was built, not where it runs. Deployment is a separate, larger piece of work.

Nor is a release a GitHub- or GitLab-style "release" with notes and attached files. Those are a source-forge concept about tagging source; a Loha release is about a container image and its digest.

Where to go next

• Builds: what produces a release
• Container registries: where your images are pushed, and the credential that lets them be
• Outbound webhooks: get told when an image ships
• Buildah build / Docker build: the steps that push images