Container registry
The platform's own container registry — what it stores, who can reach it, how long images are kept, and how it differs from a private registry you connect.
The platform has its own container registry. When it builds an app, a function or a static web app, it stores the resulting image there, and the cluster pulls the image from it to run the workload. You normally never talk to it directly: builds push to it and workloads pull from it on their own.
What it stores
Every image lives in a repository named after its boundary, its resource group's namespace and the resource:
| Built from | Repository | Tag |
|---|---|---|
| An app | apps/<boundary id>/<namespace>/<app name> |
The time the build started, in Unix seconds; <slot>-<time> for a slot |
| A static web app | apps/<boundary id>/<namespace>/swa-<site name> |
The time the build started, in Unix seconds |
| A function | fn/<boundary id>/<namespace>/<function name> |
The build number |
Builds also keep a layer cache next to them, under cache/<boundary id>/<namespace>/…, which
makes the next build of the same resource faster.
Who can reach it
- Each build gets a credential, valid for one hour, that it uses to push to its repository and its cache.
- Each namespace of a boundary holds a credential in the Secret
stackship-registry-pull, attached to the namespace'sdefaultservice account, which the cluster uses to pull the boundary's images. The credential is valid for 24 hours, and the platform replaces it when fewer than six hours remain. - A credential belongs to one boundary, and the registry refuses it access to any other boundary's repositories.
Caution
Within its own boundary, a credential is not limited to what it was issued for. The registry grants whatever access a credential asks for — including push and delete — on every repository and build cache of the credential's boundary, across all its resource groups. So the credential in
stackship-registry-pullis not pull-only, and a build's credential is not limited to its own repository: anyone or anything that can read one of these credentials can replace or delete every image of the boundary.
You cannot sign in to the registry with your platform account, and it hands out no credentials to people. To run an image of your own, push it to a registry you control and connect that registry to the boundary as a deployment source — see Private registry. That is a different thing from this registry: the platform only pulls from it, with the credential you give it.
How long images are kept
A retention sweep runs every night. Unless your platform is configured otherwise, it keeps these images of an app's or a function's repository and may remove the rest:
- the images the app's or function's running pods use;
- the two images pushed most recently;
- every image pushed in the last 90 days.
An app can set its own numbers through the API, with retention.keepLast and
retention.keepForDays, only in the request that creates it; changing them on an existing app has
no effect — see Image retention. In this version the sweep removes no images at all, so in practice every
image is kept; see Retention. Images of static web apps are not
part of the sweep. Build cache entries that have not been rebuilt for 14 days are removed once a
week.
When an older version is needed again:
- Redeploy this version on an app rebuilds that version from its commit when its image is no longer in the registry.
- Serve this deployment on a static web app needs the image; see Serve an earlier deployment.
How platform administrators run and check the sweep is described in Retention.