Container Registries

Where Nodion stores and pulls the container images your applications run on.

A container registry is the storage layer for the Docker images that back your applications. When you deploy an application on Nodion, the platform either builds an image from your Git repository and pushes it to a registry, or pulls a pre-built image that you already published somewhere. Either way a registry is involved.

Nodion supports four registry types:

• Nodion: the managed registry we run for every project, in every region.
• Docker Hub: the public registry at docker.io.
• GitHub Container Registry: ghcr.io, tied to your GitHub account or organization.
• Custom: any OCI-compatible registry reachable over the internet (AWS ECR, GitLab, JFrog, self-hosted, etc.).

Nodion Registries (the default)

Every time you create a new project, Nodion automatically provisions one managed registry per available region. You'll see entries like Nodion Registry (EU Central), Nodion Registry (US East) and so on when you open Registries on that project. The hostnames look like registry.<region-slug>.nodion.net.

The registry record itself is created immediately, but the push/pull credentials are generated on demand the first time you need them. Open the registry in the dashboard and click Generate Credentials. A dedicated access token is created and stored encrypted against the registry record.

Once credentials exist the hostname plus that token are everything you need to docker login, docker tag and docker push from a build pipeline. Inside Nodion no extra configuration is needed. Applications in the same project can pull from their Nodion registry transparently.

Isolation is per project: each project has its own namespace in every region, and credentials only have access to that namespace. Images are not visible to other users or other Nodion projects.

Connecting a third-party registry

For Docker Hub and GHCR, go to Registries → Add Registry, pick the provider, enter the hostname (auto-filled for Docker Hub) and the username plus a personal access token with read access. For public images you can even leave credentials empty; Nodion will pull anonymously.

For a custom registry, provide the hostname and any credentials the registry expects. Nodion uses standard OCI authentication, so anything that speaks the Docker Registry v2 API works.

Credentials for third-party registries are encrypted at rest on the Nodion side and are only ever sent to the deploy target that pulls the image at deploy time.

Using a registry for deployments

There are two places a registry gets used:

• Dockerfile and Buildpacks strategies. Nodion builds the image for you and pushes it to your project's Nodion registry in the target region. You don't need to configure anything; the default registry is used transparently.
• Prebuilt Image strategy. You select a registry when creating the application and provide an image name (and optional tag). Nodion pulls that image on each deploy. Use this when your build pipeline already produces images elsewhere, or when you're deploying an off-the-shelf image like nginx, redis or a vendored product image.

The CLI speeds this up for prebuilt images: if you pass --strategy prebuilt_image without --container-registry, the CLI auto-selects the Nodion registry for the chosen region. That keeps nodion apps create short for the common case.

Rotating and revoking credentials

For Nodion registries, credentials are one-shot today: once generated they stay bound to that registry. To rotate, create a fresh Nodion registry from the dashboard and repoint your external pipelines at the new credentials. Automated rotation is on the roadmap.

For third-party registries, revoke the token at the source (Docker Hub account settings, GitHub personal access tokens, your custom registry's admin UI) and update the credentials on the Nodion registry record in the dashboard. Nodion won't retain stale credentials once they're overwritten.