DEPLOYING

Private registries

Pull from Docker Hub, GHCR, GitLab or a self-hosted registry with stored credentials.

Public images need no configuration. A registry entry exists for the other case: images behind credentials — your own GitHub Container Registry, a GitLab registry, a paid Docker Hub repository, or a registry you run yourself.

Adding one

A registry is a host, a username and a password. The host is what docker login takes — no scheme, no path:

TEXT

ghcr.io
registry.gitlab.com
registry.example.com:5000

That same string is the prefix an image reference must carry to match this entry. ghcr.io/acme/api:v3 matches the ghcr.io row and is pulled with its credentials; acme/api:v3 does not, and goes to Docker Hub anonymously.

DockBoard tests the credentials when you save, and shows the result. A registry that has never tested successfully is visibly pending rather than quietly broken until your next deployment.

The password is stored encrypted and never returned in plaintext by any endpoint. It is only ever decrypted into a docker login that DockBoard runs itself, or shipped to an agent inside an encrypted deployment payload.

Use a token scoped to *read packages*, not your account password. GitHub, GitLab and Docker Hub all issue one, and it can be revoked without changing anything else you own.

Personal or project-scoped

A registry belongs to the person who added it, and is optionally pinned to one project:

Personal — usable across every project of its owner. Right for your own account’s token.
Project-scoped — usable only inside that project. Right for a client’s registry, or for a credential that belongs to the team rather than to you.

Same shape as DNS providers, for the same reason: a credential should reach exactly as far as the work it is for.

Running your own registry

DockBoard can run a registry container on one of your servers and manage the certificate for it. The certificate is self-signed, so the machines that pull from it need to trust it — DockBoard distributes that CA to each of them.

The distribution costs nothing operationally: Docker reads the trust store per pull, so a new machine needs no daemon restart. That is why this design was picked over editing the daemon’s insecure-registry list, which does.

A server hosting a registry cannot be deleted while applications still pull from it. Silently dropping the credentials for a registry in use turns into a pull failure on every subsequent deployment, with nothing on screen explaining why. Move or delete those applications first.

A cluster always has its own registry, provisioned automatically at cluster creation — every node pulls from it. That one is managed for you and is not the same object as a registry you add here.

Using one in an application

Nothing to select. Deploy an application from a prebuilt image and give the full reference — if its host prefix matches a registry you can reach, the credentials are used automatically:

TEXT

ghcr.io/acme/api:v3.2.1

A pull that fails on authentication says so in the deploy log. The two usual causes: the token expired, or the image reference is missing the host prefix and is quietly being looked up on Docker Hub.