Ordyn

Appearance

Container Registries ​

Container registry connections are used by Ordyn to check Docker image updates for images discovered during endpoint Docker inventory.

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 as an Ordyn secret.

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

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.