Private Registry V2 deployment

Find the private image.
Ship it with guardrails.

Connect a self-hosted or hosted Docker Registry V2, verify pull credentials and browse repositories and tags while preparing a release. Felania keeps registry access inside the deployment workflow for remote Linux devices.

Start 14 days free →Read the registry guide

Registry V2Pull-only credentialsEncrypted at rest

VERIFYTest before savingCatch host and credential errors early.

DISCOVERBrowse repositoriesUse the Registry V2 catalog when available.

SELECTInspect image tagsChoose the intended version explicitly.

DEPLOYReuse guarded rolloutCanary, validate and recover.

Registry access is deployment infrastructure

Private images should not create a manual side channel.

Copying credentials into Compose files, chat messages or per-device shell sessions makes releases harder to repeat and secrets harder to contain.

Save a pull identity, not a human account

Create a dedicated registry user with only the permission needed to read images. Felania verifies the credential over HTTPS before encrypting and storing it for the workspace.

Use a descriptive credential name.
Prefer read-only or pull-only permission.
Rotate it independently of operator access.

Make image selection visible

After a registry is connected, the image browser can read the catalog and list tags for a selected repository. This reduces typing mistakes and keeps the chosen artifact close to the release definition.

Search repositories instead of remembering paths.
Select explicit tags for predictable releases.
Reuse the image in a canary-first workflow.

Registry workflow

From credential to canary in four steps.

Create pull-only access

For a self-hosted Registry V2 with htpasswd, use the registry username and password. Hosted providers may supply an access token instead.

Verify the registry

Enter the HTTPS registry host and credential. Felania confirms authentication before saving the encrypted secret.

Browse image versions

Open the saved registry, filter repositories, select one and inspect the tags returned by the Registry V2 API.

Deploy safely

Reference the private image in a release, begin with a canary and keep health validation and rollback available.

Honest compatibility

Registry V2 is standard. Catalog policy still varies.

Felania surfaces the difference between authentication success and catalog availability instead of pretending every registry exposes the same API behavior.

CATALOG

Browse when available

If the registry allows the V2 catalog endpoint, Felania lists repositories and lets the operator inspect tags.

EXPLICIT

Use an exact image path

When a provider disables catalog listing, an authenticated image can still be referenced explicitly by repository and tag.

SELF-HOSTED

Works with registry:2

A standard Docker Registry using htpasswd can use that dedicated username and password; it does not issue a separate magic token.

Questions

Private registry access, without guesswork.

Where do I get an access token for self-hosted registry:2?

With htpasswd authentication, the registry username and password are the credential. Create a dedicated pull-only identity if your authorization layer supports repository-level permissions.

Why can authentication work while the catalog is unavailable?

Some registries disable or restrict /v2/_catalog. In that case Felania cannot enumerate repositories, but an image path you already know may still be used explicitly.

Does Felania need push permission?

No for normal deployment. The platform is designed to pull existing images, so the safest credential is one that cannot publish or delete registry content.

Are registry credentials shown again to users?

The credential is treated as a secret and stored encrypted. Operators work with the saved registry identity rather than copying the password into each deployment.

Keep the secret small and the release visible.

Add a test registry during the no-card trial, browse an image and use it in a canary-first release.

Start free →Try the live demo