For images that package upstream software, tags separate the upstream software version from the Wodby image revision. Wodby software such as Edge Alpine and Backup uses its own semantic product versions for both Git and Docker tags. Edge 3.x and 2.x identify different runtime compatibility contracts. These repositories do not use the image revision sequence.
For packaged upstream software, choose a major/minor release line or an exact
upstream version. The first release uses r0 everywhere: Git tag r0 and, for example, Docker tags 11-r0,
11.4-r0, and 11.4.2-r0. Subsequent releases follow the counters below:
| Example Docker tag | Revision counter | Matching Git tag |
|---|---|---|
wodby/mariadb:11-r102 |
Repository release 102 | 11-r102 |
wodby/mariadb:11.4-r102 |
Repository release 102 | 11.4-r102 |
wodby/mariadb:11.4.2-r0 |
First revision of exactly 11.4.2 | 11.4.2-r0 |
These illustrative aliases all point to the primary Git release tag r102's
commit. A major alias selects the supported minor line designated for that major.
Development variants retain their qualifier, such as wodby/php:8.5-dev-r102
and wodby/php:8.5.10-dev-r0. Images without an upstream-version prefix use the
repository release directly, such as wodby/sshd:r102.
- Git release tags are
r0,r1,r2, and so on. The counter increases per repository and is shared by its runtime versions, variants, and architectures. Major/minor Docker tags use this counter. It never resets when an upstream version changes. Numbers can have gaps. - Full-version tags start at
r0for each exact upstream version. The next repository release containing that same version usesr1, and so on. A new upstream version starts atr0again. Variants and architectures share the counter. Failed release attempts can leave gaps; retries reuse their number. - Alias tag descriptions use the primary release notes to explain what changed.
- After the images and any versioned aliases publish successfully, CI creates one
GitHub Release named after the primary tag, such as
r2, with its annotated tag notes. Versioned aliases do not get separate GitHub Releases. Retrying a workflow preserves an existing published release; a manually prepared draft needs review. - Every published versioned revision tag gets a matching annotated Git alias pointing to the primary release commit. Only primary Git tags trigger builds. Dropping a major or minor line stops new releases for it; existing Docker and Git revision tags remain available.
- Each new image release gets a new revision, including releases that adopt dependency or security fixes without changing the upstream software version. CI retries do not allocate another revision.
- Revisions identify releases; they do not indicate compatibility. Review the release notes before upgrading. Breaking configuration, permission, storage, or startup changes require explicit migration instructions.
- Published revision tags must not be reassigned to different image contents.
Pin an image digest when the exact artifact must be enforced independently
of registry tag settings. Floating tags such as
11.4andlatestremain mutable. - Previously published image tags remain available. Parent-image and Docker4X updates accept both formats, prefer published revisions for the selected runtime and variant, and never automatically move from a revision back to a legacy tag.
Upstream version formats differ. PostgreSQL 17.11 and Squid 7.6 are complete
versions, so 17.11-r0 and 7.6-r0 use the full-version counter; 17-r102 and
7-r102 use the repository counter. Supabase PostgreSQL uses its complete bundle
version, such as 17.6.1.136-r0. WordPress initial releases named 7.2 use
7.2.0-r0 for the exact version, keeping 7.2-r102 for the minor line.
Email digests and consolidated reports include a Grype Exception Warnings section
when catalog image repositories contain configured ignore rules. Each warning shows
the repository, branch, complete rule scope, and configuration URL so exceptions can
be reviewed and removed after a fix is adopted. The report checks the default branch,
using the first conventional .grype.yaml, .grype.yml, .grype/config.yaml, or .grype/config.yml file. Custom config paths,
environment-only rules, and VEX files are not inspected. These are configured rules,
not confirmed matches from a vulnerability scan. Lookup and parsing errors appear in
the general warnings section.
Exceptions alone do not trigger an email; digests retain the existing update-event
and workflow/artifact-failure triggers. To generate a report locally, first install
its dependencies with python -m pip install -r scripts/requirements.txt.
| Image | Alpine version |
|---|---|
| wodby/mariadb | 3.22 |
| wodby/nginx | 3.23 |
| wodby/opensmtpd | 3.23 |
| wodby/vinyl | 3.22, 3.23 |
| wodby/squid | 3.24 |
- Minor/patch version update
- Rebuild against updated base image
- Rebuild
wodby/alpineagainst complete new gotpl releases - New image revision released on version update
- New image revision released on Alpine Linux update
- New
wodby/alpinerevision when tested package upgrades fix known CVEs. All supported variants and architectures are compared with the last revision using one vulnerability database snapshot. Digest-only changes do not trigger releases. Release notes list package versions and CVEs; release builds verify those fixes.
| Image | Upstream (base image) | Versions |
|---|---|---|
| wodby/alpine | alpine | 3.24, 3.23, 3.22, 3.21 |
| wodby/apache | _/httpd | 2.4 |
| wodby/memcached | _/memcached | 1 |
| wodby/mysql | _/mysql | 8.0 |
| wodby/node | node | 26, 24, 22 |
| wodby/php | _/php | 8.5, 8.4, 8.3, 8.2 |
| wodby/postgres | _/postgres | 18, 17, 16, 15, 14 |
| wodby/supabase-postgres | supabase/postgres | 17 |
| wodby/python | python | 3.14, 3.13, 3.12, 3.11 |
| wodby/go | _/golang | 1.27, 1.26 |
| wodby/valkey | valkey/valkey | 9.0, 8.1, 8.0, 7.2 |
| wodby/redis | redis | 8.6, 8.4, 8.2, 7.4 |
| wodby/ruby | ruby | 4.0, 3.4, 3.3 |
| wodby/rabbitmq | rabbitmq | 4.3, 4.2 |
Supabase PostgreSQL is monitored for newer bundles within its pinned major version and for changes to the pinned tag digest. Updates produce manual-review report events; they do not automatically change the image or create releases because initialization SQL and backup compatibility must be validated together.
wodby/backup follows the published wodby/alpine:3-rN revisions. A newer
parent revision, including one with package security fixes, produces a Backup
semantic patch release. Release notes include the parent's changes, and release
builds use that exact digest-pinned parent revision. Changes to the floating
wodby/alpine:3 digest only rebuild Backup's latest tag.
The updater publishes the parent-pin commit and annotated product tag together. Backup's release workflow tests the image, publishes its Docker tag, then creates a GitHub Release with the same version. Failed builds can retry the existing tag.
- Rebuild against updated base image
- Update the base image revision
- New release using the image revision or product version format
| Image | Upstream (base image) | Versions |
|---|---|---|
| wodby/edge-alpine | wodby/nginx | 1.31 |
| wodby/drupal-php | wodby/php | 8.5, 8.4, 8.3, 8.2 |
| wodby/drupal | wodby/drupal-php | 8.5, 8.4, 8.3, 8.2 |
| wodby/drupal-cms | wodby/drupal-php | 8.4 |
| wodby/matomo | wodby/php | 8.2 |
| wodby/webgrind | wodby/php | 8.2 |
| wodby/wordpress-php | wodby/php | 8.5, 8.4, 8.3, 8.2 |
| wodby/wordpress | wodby/wordpress-php | 8.5, 8.4, 8.3, 8.2 |
| wodby/xhprof | wodby/php | 8.2 |
| wodby/laravel-php | wodby/php | 8.5, 8.4, 8.3, 8.2 |
Products can run the shared product-base-update action in their own repository.
This keeps checkout access, logs, and release publication inside that repository.
The action follows published parent revisions within the configured runtime line;
it never selects a new Node, PHP, or other runtime major version.
The product opts in with .image-release-format containing semver and a
base-images.mk with BASE_IMAGE_VERSION, BASE_IMAGE_REVISION, and digest pins
for both the floating runtime line and its selected revision. Its build must use
the revision pin. An initial annotated semantic release must already exist.
Run the action from a clean checkout of the default branch with full Git history:
permissions:
contents: write
actions: write
steps:
- uses: actions/checkout@v7
with:
ref: ${{ github.event.repository.default_branch }}
fetch-depth: 0
- uses: wodby/images/.github/actions/product-base-update@master
with:
publication-workflow: build.yml
publish: 'true'Pin the action to a reviewed commit for reproducible workflow behavior. Serialize
scheduled and manual runs with a workflow concurrency group. Omit publish for a
preview that resolves the next parent revision without changing files or Git state.
The repository token needs permission to push to the default branch and create tags.
A newer parent creates an annotated product patch tag with the parent's release
notes, pushed atomically with the pin commit. The action explicitly dispatches the
publication workflow because repository-token pushes do not start other workflows.
The publication workflow must accept workflow_dispatch on a tag, test the images,
and publish all variants before calling image-release with release-format: semver.
Retries reuse the existing product tag; active runs and published releases are
preserved. Parent lookup failures leave the checkout unchanged.
- Minor/patch version updates
- New release using the image revision or product version format
| Image | Upstream | Versions |
|---|---|---|
| wodby/adminer | vrana/adminer | 6 |
| wodby/cachet | CachetHQ/Cachet | 2 |
| wodby/drupal | drupal | 11, 10 |
| wodby/drupal-cms | drupal-cms | 2 |
| wodby/mariadb | mariadb | 12.3, 11.8, 11.4, 10.11, 10.6 |
| wodby/matomo | matomo-org/matomo | 5 |
| wodby/nginx | nginx | 1.31, 1.30 |
| wodby/prometheus | prometheus/prometheus | 3.13 |
| wodby/vinyl | vinyl-cache/vinyl-cache | 9.1, 6.0 |
| wodby/webgrind | jokkedk/webgrind | 1 |
| wodby/wordpress | wordpress | 7 |
| wodby/xhprof | longxinH/xhprof | 2 |
| wodby/solr | apache/solr | 10, 9 |
| wodby/zookeeper | apache/zookeeper | 3.9 |
| wodby/openclaw | openclaw/openclaw | 2026 |
Update image revision tags in active and commented .env entries, including
test fixtures. Each runtime and variant is checked against its own published
revisions, so alternatives can catch up even when the active tag is current.
Docker4X test fixtures use *_IMAGE_REVISION for the image release suffix; the
updater also accepts legacy *_STABILITY_TAG variables in older checkouts.
| Project |
|---|
| wodby/docker4drupal |
| wodby/docker4php |
| wodby/docker4python |
| wodby/docker4ruby |
| wodby/docker4wordpress |
| wodby/docker4laravel |
Update runtime versions within the configured compatibility line.
| Project | Runtime | Policy |
|---|---|---|
| wodby/gotpl | Go | Patch updates only; EOL lines are reported for manual migration |
wodby/edge-alpine automatically updates NGINX 1.31, lego 4.x, s6-overlay 3.x, gotpl 0.6.x, and etcd-client 3.6 patches. Confd advances only to stable releases descended from its current source pin; older releases are skipped and divergent histories are reported. Go build images remain on their configured compatibility line.
Runtime component updates appear in release notes; compiler versions and digests remain in logs and source diffs. Every release waits for the Edge build, runtime tests, and vulnerability scan. Major-line migrations and conflicts with custom source patches require review. The explicit Go library overrides remain manual.
wodby/workspace-agents bundles coding agent tools for development workspaces. The updater runs the repository's own
scripts/update.sh, which pins Claude Code's stable release and the latest Codex, opencode and ripgrep releases with
verified checksums. Any version change is pushed to master together with a new patch release in one atomic push. The
release notes list the updated tools.
- A checksum change without a version change stops the update for review, because an upstream asset was replaced.
- The first release is tagged by hand; until then the updater only reports that it is waiting.
- Adding tools and major-version changes are manual.
Not automated:
- Adding new minor/major version
- Moving gotpl to a new Go minor line
- Rebase to a new major Alpine version
- Switching the latest version
- wodby/opensmtpd (installed from Alpine repository package)
- wodby/adminer not auto-updates for the base image (php:8.4-apache)
Image Makefiles consume base-images.mk to pass an exact repository:tag@digest
reference to Docker. The updater compares these digests instead of Docker Hub
timestamps. It resolves the actual build tag, including variants such as
fpm-alpine, dev, and dev-macos. Pins use the multi-platform image index.
Version and image-revision updates resolve all affected references before changing the pins. A missing tag, invalid response, or failed lookup leaves the pin file unchanged. Digest-only changes trigger rebuilds. Backup creates a semantic patch release only for a newer published Alpine image revision; other images retain their version and Alpine release rules. A committed pin is a build input, not proof of a successful build; failed image builds can be retried using the same commit and digest.
Images that only track application releases keep their existing update flow.