Container registry

Every Aether organization can have its own private container registry. Push your images to it, then pull them from your clusters’ workloads. Images are vulnerability-scanned on push, and you can configure cleanup/retention policies from the portal.

The registry is hosted at registry.aetherplatform.cloud. It is a global name — one registry for every region, not one per region.

Enable it first

The registry isn’t provisioned until you turn it on. Open Registry in the portal and enable it — Aether creates your organization’s private project and issues a first set of credentials. Until then the Registry page shows the registry as disabled.

Image naming

Your organization gets its own project in the registry, named aether- plus your organization’s slug. Repositories live directly inside it:

registry.aetherplatform.cloud/aether-<org-slug>/<image>:<tag>

<org-slug> is your organization’s slug — the short, URL-safe identifier shown in the portal. Replace it (and <image> / <tag>) with your own values.

That project is the isolation boundary: credentials issued to your organization can only reach your organization’s project.

Push an image

1. In the portal, open Registry and create a robot account. You’ll get a username and a token to use as the password.

   Caution

   The token is shown once, at creation. Copy it somewhere safe — if you lose it, rotate the account rather than trying to read it back.

   Copy the username exactly as the portal gives it to you — it begins with robot$ and encodes both your project and the account name. Don’t reconstruct it by hand; docker login fails on a hand-built username.

2. Log in with Docker:

   docker login registry.aetherplatform.cloud

   Enter the robot username and token.

3. Tag your local image for the registry:

   docker tag my-app:latest \
     registry.aetherplatform.cloud/aether-<org-slug>/my-app:v1

4. Push it:

   docker push registry.aetherplatform.cloud/aether-<org-slug>/my-app:v1

Pull from a cluster

Reference the full image path in your workload spec:

Create an image pull secret from a robot account’s credentials:

kubectl create secret docker-registry aether-registry \
  --docker-server=registry.aetherplatform.cloud \
  --docker-username='<robot-username>' \
  --docker-password='<token>'

Tip

Quote both values — the username contains a $, which your shell would otherwise try to expand.

Then reference the secret and the full image path in your workload spec:

spec:
  imagePullSecrets:
    - name: aether-registry
  containers:
    - name: my-app
      image: registry.aetherplatform.cloud/aether-<org-slug>/my-app:v1

Credentials

You can hold several robot accounts at once, each with its own set of permitted actions (pull, push, delete, and so on) — one per CI pipeline, say, so you can revoke a single one without disturbing the others. Create, list, and delete them from the portal’s Registry page, and rotate an account to replace its token when you need to.

Browsing what you’ve pushed

The Registry page lists each repository with its size, tag count, when it was last pushed to, and a summary of the vulnerabilities its scans found. Drill into a repository to see its tags — digest, size, when each was pushed and last pulled, and which are untagged.

Scanning

• On push — every pushed image is automatically scanned for known vulnerabilities.
• On demand — you can also re-scan a specific tag at any time, which is what you want after a new CVE lands for a base image you already pushed.

Results are shown per tag in the portal.

Cleanup policies

Cleanup policies keep your storage tidy automatically. A policy has:

• An action — delete matching images, or protect them from deletion.
• Conditions — what it matches: image age, tag count, tag name patterns, or whether an image is untagged.
• A scope — all repositories, or a specific one.
• A schedule — nightly, weekly, or manual-only.

Two things make policies safe to iterate on: a dry run shows exactly what a policy would remove without touching anything, and a manual run now applies it on demand. After each run the policy reports how many images it deleted and how much space it freed.

Storage quota

Each organization’s registry has a storage quota, and the portal shows how much of it you’re using. Registry storage is metered and billed by the space your images occupy — see the Billing model.

You can also disable the registry from the portal, optionally purging all of its repositories in the process.

Next steps

• Observability — watch your cluster’s health and metrics.