Ordyn

Appearance

Container Registries ​

Container registry connections are used for Docker image update checks and authenticated Linux Runner image pulls.

The service currently supports Docker Hub and custom OCI-compatible registries.

Registry Connections ​

Registry connections define how Ordyn talks to a registry:

  • registry type
  • registry base URL
  • registry host used by discovered image references
  • authentication mode
  • request timeouts
  • enabled state

Anonymous access is enough for many public Docker Hub checks. Private registries usually require either basic authentication or a bearer token stored in a secret variable. Create the secret variables in Library > Variables, then select them on the registry connection.

Disabled registry connections stay configured but are skipped during Docker image update checks.

Runner Image Pulls ​

In an infrastructure job, add one or more connections under the Docker registries build feature. When a Linux Runner task executes in Docker, Ordyn sends credentials only when the rendered image reference has the exact host of one attached, active connection and that connection is assigned to the selected pool.

The Runner's workspace-ownership helper image is configured locally on the Runner. Its pull does not use container-registry features attached to a job. The image must already be present or allow an anonymous pull.

Image references without an explicit host use docker.io. A job without the build feature pulls anonymously. Multiple attached active connections for the same image host are ambiguous and prevent dispatch.

Docker Image Tracking Rules ​

Docker image tags are not always a single linear version stream.

Some projects maintain multiple branches at the same time. For example, an image can publish 3.6.x and 3.7.x releases in parallel. In that case, blindly picking the newest semantic version would incorrectly recommend crossing from the maintained 3.6 branch to 3.7.

Tracking rules control how Ordyn selects a recommended newer tag for a repository.

Rules match by:

  • registry host
  • repository name
  • optional tag pattern

The tag pattern supports * as a wildcard. Examples:

  • 3.6.*
  • 8.*
  • *-alpine

More specific tag-pattern rules are evaluated before repository-wide rules.

Tracking Strategies ​

Same minor branch ​

Only tags with the same major and minor version are considered.

Example:

  • current: 3.6.2
  • allowed: 3.6.3
  • ignored: 3.7.0

This is the default for tags with at least major and minor version components, such as 3.6 or 3.6.2.

Same major branch ​

Only tags with the same major version are considered.

Example:

  • current: 8
  • allowed: 8.0, 8.1, 8.2
  • ignored: 9.0

This is the default for major-only semantic tags.

Newest stable semantic version ​

Every stable semantic version tag is considered, including major and minor upgrades.

Use this only for repositories where newer semantic tags represent a safe upgrade path.

Digest only ​

No newer tag is recommended.

Ordyn reports whether the current tag points to a different remote digest.

This is useful for floating tags such as latest, stable, or vendor tags that are not meaningful semantic versions.

Disabled ​

Matching images are ignored by update tracking.

Use this when a repository should remain inventoried but should not create Docker image update recommendations.

Suffix Preservation ​

Tracking rules preserve stable tag suffixes by default.

For example, if the current tag is 1.2.3-alpine, Ordyn prefers newer tags with the same -alpine suffix and does not recommend 1.2.4-bookworm or 1.2.4 unless suffix preservation is disabled.

Supported stable suffix families include common distro and Windows image suffixes such as:

  • -alpine
  • -slim
  • -bookworm
  • -bullseye
  • -buster
  • -nanoserver-*
  • -windowsservercore-*

Digest Drift ​

A digest drift means the current tag still has the same name, but the registry resolves that tag to different image bytes.

Example:

  • local image: redis:7.2@sha256:local-digest
  • registry reports: redis:7.2@sha256:registry-digest

The UI shows this as Tag digest changed.

This is different from a version update. A version update means Ordyn found a different tag, such as 7.2.4.

Digest drift is common for floating tags and can also happen when vendors republish mutable tags.

Rechecking Images ​

When a tracking rule is created, changed, or deleted, Ordyn schedules matching Docker image update checks again.

This means policy changes are applied to already inventoried images without waiting for endpoints to report another Docker inventory snapshot.