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:

bash 
docker build -t myapp:v1.0.0 .

Tag it for your registry:

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

Push the image:

bash 
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:

bash 
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:

bash 
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:

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

Pulling images

From local machines

Pull images after authenticating:

bash 
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:

yaml 
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:

yaml 
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

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

Build and push multi-arch image

bash 
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:

bash 
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:

bash 
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:

bash 
helm package ./my-chart

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

Push the chart to your registry:

bash 
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:

bash 
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:

bash 
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:

bash 
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:

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

Using the registry API

Query the registry API directly:

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

Response:

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

Listing repositories and tags

List all repositories in your registry:

bash 
cloudfleet repositories list

List tags for a specific repository:

bash 
cloudfleet repositories tags list {region} {repository}

For example:

bash 
cloudfleet repositories tags list europe myapp

Get details about a specific tag:

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

Deleting images

Delete a specific tag from a repository using the CLI:

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

For example:

bash 
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