Repository navigation
Document the container image naming and tagging convention #53
Description
Goal
Define and document a clear container image naming and tagging convention for images published from this repository.
The convention must support both stable releases and development images that follow Nextcloud Server master, and it must be reusable by environments that consume these images.
Scope
Add repository documentation that becomes the source of truth for container image names, tags, and traceability.
The documentation must define the different parts of an image identity separately.
Image name
Explain how published image names are formed.
Use the images that this repository actually publishes as the starting point, such as the application and web images.
The naming convention must make it clear which component an image contains without putting version, channel, or runtime information into the image name when that information belongs in the tag.
Do not invent new image types only for the documentation.
Channel or version
Explain how to identify:
- stable release images;
- development images that follow Nextcloud Server
master; - immutable versions or revisions;
- moving aliases that point to the current image of a channel.
Do not use a future Nextcloud major version as the main identity of the development channel. The development channel represents the current upstream master.
Runtime variant
Explain how runtime variants are represented independently from the channel or version.
Examples may include:
apache;fpm.
The convention must allow other runtime variants to be added later without changing the meaning of the version or channel.
Do not document a runtime variant as supported unless it already exists or is part of the architecture defined by the parent Epic.
Moving and immutable tags
Define the difference between:
- moving tags, which may point to a newer image over time;
- immutable tags, which must always identify the same published image.
Document when each type should be used.
Immutable tags must provide enough information to identify the exact build or upstream revision.
Avoid ambiguous tags such as bare latest, dev, or a development image identified only by a Nextcloud major version.
Existing tags such as latest or the current version-specific development tag are implementation details of the current setup. They must not automatically become part of the new convention.
Traceability
Document the metadata that a published image must expose so that the image can be traced back to its sources.
At minimum, define metadata for:
- source repository;
- source revision;
- build date;
- Nextcloud version or revision;
- PHP version;
- runtime variant.
Use standard OCI image labels where an appropriate standard label exists.
If extra project-specific metadata is needed, clearly separate it from standard OCI labels.
Examples
Include a small set of examples showing the convention for:
- a stable image;
- a stable immutable image;
- a development
masterimage; - an immutable development image;
- different runtime variants where they are relevant.
Base examples on image components that this repository already publishes.
Examples are illustrative. Do not create tag formats that depend on the current Nextcloud 35 implementation.
Documentation location
Keep the documentation in this repository, close to the image build and publishing process.
If no documentation directory exists yet, create a small and clear location for repository documentation and link it from the README.
The documentation should be easy to reference later from AGENTS.md, workflows, and consuming repositories.
Out of scope
This issue is documentation-only.
Do not:
- change existing container image names or tags;
- change Dockerfiles;
- change publishing workflows;
- create new image variants;
- migrate existing image consumers;
- remove the current Nextcloud 35 development image.
Implementation changes will be handled by separate issues after the convention is agreed.
Acceptance criteria
- The documentation defines how image names are formed.
- Existing published image components are used as the basis for naming examples.
- Stable and
masterchannels are defined. - Moving and immutable tags are clearly distinguished.
- Runtime variants are independent from version/channel naming.
- Ambiguous tag patterns are explicitly discouraged.
- Current historical tags are not treated automatically as the new standard.
- Required traceability metadata is documented.
- OCI standard labels are used where applicable.
- Examples are independent from a specific Nextcloud development major.
- The documentation is linked from the repository README or another clear entry point.
Good first issue
This issue has a limited documentation scope.
If an existing image or consumer does not fit the convention described here, do not change the convention only to preserve the current behavior. Record the case in the pull request and ask for guidance before expanding the scope.
Activity
[-]Document the container image tagging convention[/-][+]Document the container image naming and tagging convention[/+]vitormattos commentedon Oct 7, 2026
I reviewed the proposed convention against the current Nextcloud Docker images, Nextcloud's own development environment, and common Docker Official Image practices.
What the upstream projects do
Nextcloud official runtime image
35-fpm,35.0.1-fpm,stable-fpm,production-fpm.35-fpmis a moving tag within that major.35.0.1-fpmis human-readable and stable with respect to the Nextcloud release, but the image may still be rebuilt; the OCI digest is the truly immutable identity.stable-fpmis a moving channel alias.Nextcloud's own development environment (
nextcloud/nextcloud-docker-dev)nextcloud-dev-php85:latest.SERVER_BRANCH, defaulting tomaster.Other official images
current-alpine,lts-slim, and exact-version variants.nightlymoving tag for scheduled development builds.Convention for this repository
The earlier proposal
stable-<major>-fpmis unnecessarily different from Nextcloud and adds a redundant word. The repository should stay close to the upstream Nextcloud convention unless we have a concrete reason not to.Recommended app tags:
:<major>-fpm:<full-version>-fpm:stable-fpm:master-fpmmaster@sha256:<digest>Examples:
ghcr.io/librecodecoop/nextcloud-docker-app:35-fpmghcr.io/librecodecoop/nextcloud-docker-app:35.0.1-fpmghcr.io/librecodecoop/nextcloud-docker-app:master-fpmghcr.io/librecodecoop/nextcloud-docker-app@sha256:...For the development channel, do not use
35,dev-35, or another future major as its primary identity. The channel followsmaster; when master becomes Nextcloud 36, the image name should not change.For the web image, Nextcloud version is not part of its identity. Use:
:mainas the moving repository channel;@sha256:<digest>for immutable consumption.What not to standardize
:latestthe recommended consumer contract. It is too ambiguous in a repository that publishes multiple semantic channels.nc-<major>; upstream already has a clear and familiar<major>-fpmconvention.sha-<repository-commit>as intrinsically immutable. A repository SHA identifies our source revision, not necessarily the exact resulting image if upstream/base packages are rebuilt. Store it as OCI traceability metadata and use the image digest when immutability matters.:35development tag as a compatibility alias: Inventory consumers of the current Nextcloud 35 image #52 found no active consumer that needs it.Consequence for #58 / #62
This confirms that the version-specific
Dockerfile.35is transitional and should not be evolved into the new contract. The replacement should use one generic app image build path and a developmentmaster-fpmchannel. PR #58 contains useful implementation ideas, but its proposednc-<major>,dev,dev-<major>, and compatibility<major>tags should not be adopted as the convention.The issue itself can remain documentation-only; implementation belongs in the subsequent image-foundation change.