Image management

Cloudfleet Container Registry (CFCR) stores Docker images, OCI images, multi-architecture images, and Helm charts. This guide covers common operations for managing these artifacts.

Image naming conventions

Images in Cloudfleet Container Registry follow the standard Docker naming format:

{registry}/{repository}:{tag}

Components:

  • registry: Your organization’s registry URL (for example, 12345678-6651-4e5d-9c04-079f6532989b.europe.registry.cloudfleet.dev)
  • repository: A name for your image, optionally with path segments (for example, myapp, backend/api, team/project/service)
  • tag: A version identifier (for example, latest, v1.2.3, sha-abc123)

Examples:

12345678-6651-4e5d-9c04-079f6532989b.europe.registry.cloudfleet.dev/myapp:latest
12345678-6651-4e5d-9c04-079f6532989b.europe.registry.cloudfleet.dev/myapp:v2.1.0
12345678-6651-4e5d-9c04-079f6532989b.europe.registry.cloudfleet.dev/frontend/web:main
12345678-6651-4e5d-9c04-079f6532989b.europe.registry.cloudfleet.dev/services/auth/api:sha-a1b2c3d

Pushing Docker images

Before pushing images, ensure you have authenticated using one of the methods described in Authentication.

Tag and push

Build your image locally:

docker build -t myapp:v1.0.0 .

Tag it for your registry:

docker tag myapp:v1.0.0 YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1.0.0

Push the image:

docker push YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1.0.0

Build and push in one step

Use docker build with the -t flag to tag directly:

docker build -t YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1.0.0 .
docker push YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1.0.0

Push multiple tags

Push the same image with multiple tags:

docker tag myapp:v1.0.0 YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1.0.0
docker tag myapp:v1.0.0 YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1
docker tag myapp:v1.0.0 YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:latest

docker push YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1.0.0
docker push YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1
docker push YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:latest

Or push all tags at once:

docker push --all-tags YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp

Pulling images

From local machines

Pull images after authenticating:

docker pull YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1.0.0

From CFKE clusters

CFKE clusters authenticate automatically. Reference images directly in your manifests:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: 12345678-6651-4e5d-9c04-079f6532989b.europe.registry.cloudfleet.dev/myapp:v1.0.0
        ports:
        - containerPort: 8080

No imagePullSecrets configuration required.

Pull policies

Configure how Kubernetes handles image pulls:

spec:
  containers:
  - name: myapp
    image: YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1.0.0
    imagePullPolicy: Always  # Always pull the image

Options:

  • Always: Pull the image every time the pod starts
  • IfNotPresent: Pull only if the image is not cached locally
  • Never: Never pull; use only cached images

For production deployments with specific version tags (for example, v1.0.0), IfNotPresent is typically sufficient. For latest or mutable tags, use Always to ensure you get the newest version.

Multi-architecture images

Build and push images that run on multiple CPU architectures using Docker Buildx.

Create a builder 

docker buildx create --name multiarch --use
docker buildx inspect --bootstrap

Build and push multi-arch image 

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:v1.0.0 \
  --push \
  .

This creates a manifest list containing images for both amd64 and arm64 architectures. When you pull the image, Docker automatically selects the correct architecture for your system.

Supported platforms

Cloudfleet Container Registry supports all platforms that Docker can build:

  • linux/amd64
  • linux/arm64
  • linux/arm/v7
  • linux/arm/v6
  • windows/amd64

Helm charts

Cloudfleet Container Registry supports Helm charts stored as OCI artifacts. This provides a unified registry for both container images and Helm charts.

Enable OCI support in Helm

Helm 3.8.0 and later support OCI registries natively. Verify your version:

helm version

Authenticate Helm

Helm uses the same authentication as Docker. If you have configured the Docker credential helper, Helm uses it automatically.

Alternatively, log in explicitly:

helm registry login YOUR_ORG_ID.europe.registry.cloudfleet.dev \
  --username YOUR_TOKEN_ID \
  --password YOUR_TOKEN_SECRET

Push a Helm chart

Package your chart:

helm package ./my-chart

This creates a file like my-chart-1.0.0.tgz.

Push the chart to your registry:

helm push my-chart-1.0.0.tgz oci://YOUR_ORG_ID.europe.registry.cloudfleet.dev/charts

The chart is stored at:

oci://YOUR_ORG_ID.europe.registry.cloudfleet.dev/charts/my-chart:1.0.0

Pull a Helm chart

Pull a chart to your local machine:

helm pull oci://YOUR_ORG_ID.europe.registry.cloudfleet.dev/charts/my-chart --version 1.0.0

Install a chart directly

Install a chart directly from the registry:

helm install my-release oci://YOUR_ORG_ID.europe.registry.cloudfleet.dev/charts/my-chart --version 1.0.0

OCI artifacts

Beyond container images and Helm charts, Cloudfleet Container Registry stores any OCI-compliant artifact. Common use cases include:

  • Software Bill of Materials (SBOM): Store SBOMs alongside your images
  • Signatures: Store image signatures for verification
  • Configuration files: Distribute configuration bundles
  • WASM modules: Store WebAssembly modules

Use tools like ORAS (OCI Registry As Storage) to push arbitrary artifacts:

oras push YOUR_ORG_ID.europe.registry.cloudfleet.dev/configs/app-config:v1 \
  --artifact-type application/vnd.example.config \
  config.yaml:application/yaml

Listing images

Using the Docker CLI

List tags for a repository:

docker manifest inspect YOUR_ORG_ID.europe.registry.cloudfleet.dev/myapp:latest

Using the registry API

Query the registry API directly:

curl -u "TOKEN_ID:TOKEN_SECRET" \
  https://YOUR_ORG_ID.europe.registry.cloudfleet.dev/v2/myapp/tags/list

Response:

{
  "name": "myapp",
  "tags": ["latest", "v1.0.0", "v1.0.1", "v2.0.0"]
}

Listing repositories and tags

List all repositories in your registry:

cloudfleet repositories list

List tags for a specific repository:

cloudfleet repositories tags list {region} {repository}

For example:

cloudfleet repositories tags list europe myapp

Get details about a specific tag:

cloudfleet repositories tags describe {region} {repository} {tag}

Deleting images

Delete a specific tag from a repository using the CLI:

cloudfleet repositories tags delete {region} {repository} {tag}

For example:

cloudfleet repositories tags delete europe myapp v1.0.0

This removes the tag from the repository. If no other tags reference the same image layers, those layers become eligible for garbage collection.

Best practices

Tagging strategy

Use semantic versioning for production images:

  • v1.0.0 - Specific version
  • v1.0 - Latest patch of minor version
  • v1 - Latest of major version
  • latest - Current production version

For CI/CD pipelines, include the commit SHA:

  • sha-a1b2c3d - Specific commit
  • main - Latest from main branch
  • pr-123 - Pull request builds

Repository organization

Organize repositories by team or service:

YOUR_ORG_ID.europe.registry.cloudfleet.dev/team-name/service-name:tag
YOUR_ORG_ID.europe.registry.cloudfleet.dev/backend/api:v1.0.0
YOUR_ORG_ID.europe.registry.cloudfleet.dev/frontend/web:v2.1.0
YOUR_ORG_ID.europe.registry.cloudfleet.dev/tools/migrations:latest

Image size optimization

  • Use multi-stage builds to reduce final image size
  • Choose minimal base images (Alpine, distroless)
  • Remove build dependencies from final images
  • Use .dockerignore to exclude unnecessary files

Next steps

Previous
← Authentication
Next
Access control →
On this page