Registry Management

Overview

A registry configuration in WEDA stores the URL and authentication credentials for an external container registry. WEDA Core encrypts sensitive credentials at rest and supplies the required registry settings to WEDA Node during deployment. This lets devices authenticate and pull private images without configuring credentials manually on each machine.

Create the configuration in the same Org as the target devices. In v1.2.0, both its name and its registry host must be unique within that Org.

WEDA supports four registry types:

Registry type	Credential fields
Docker Hub (DockerHub)	username + accessToken, both required.
Azure ACR (AzureACR)	username + userPassword, both required.
AWS ECR (AwsECR)	Provide region, accessKey and accessSecretKey together, or leave all three empty for anonymous access. For authentication, use a valid region code such as us-east-1, a 20-character access key and a 40-character secret key.
Custom (Custom), for example Harbor or GitLab Container Registry	username + userPassword are optional; provide both when authentication is used.

Operations

Operation	API	Description
Create a Container Registry	POST /api/v1/orgs/{orgId}/containers/registries	Create a registry configuration.
List Container Registries	GET /api/v1/orgs/{orgId}/containers/registries	List registry configurations in an Org.
Get a Container Registry	GET /api/v1/orgs/{orgId}/containers/registries/{registryId}	Read a registry configuration by ID.
Update a Container Registry	PUT /api/v1/orgs/{orgId}/containers/registries/{registryId}	Update a registry configuration.
Delete a Container Registry	DELETE /api/v1/orgs/{orgId}/containers/registries/{registryId}	Delete a registry configuration.

Create in WEDA Console

For example, prepare authenticated access to a private Harbor registry before deploying an application that references its images. The screenshots use harbor as the configuration name. Substitute your registry address and account when following the steps.

1. In WEDA Console, select the target devices' Org and open Registries.
2. Check whether a configuration for the registry host already exists. Reuse or update that configuration when appropriate.

Select the intended Org and inspect its existing registry configurations before adding one.

3. Select Add.

The credential fields depend on the selected registry type. Docker Hub uses a username and access token.

4. Choose the Registry Type and complete Basic information:
   • Registry Name: A unique name, such as harbor.
   • Registry URL: Your registry address, such as https://harbor.company.com.
   • Registry Type: Custom for this Harbor example.

Choose the registry provider whose credential requirements apply to your image source.

5. Enter the registry account's username and password in Credentials.

This Custom registry example uses account credentials. Use your own registry address and keep password or token values masked.

6. Select Submit, then Add in the confirmation dialog.

Select Add to save the registry configuration.

Check the result: The configuration appears in the selected Org's registry list. Confirm its name, URL and type. API clients receive 201 Created and should retain the returned registryId for later reads, updates or deletion.

Confirm that harbor appears in the intended Org with the expected URL and type.

Saving a configuration does not confirm that a target device can reach the registry or pull a particular image. Check those results during deployment.

Read, Update and Delete

In WEDA Console: Select the configuration's edit icon in the registry list. In the form shown below, Registry Name and Registry URL are read-only; edit the available type or credential fields as needed, then select Submit and read the configuration back.

Inspect the existing configuration before changing its access settings. Follow the selected registry type's credential requirements.

Through the API:

• Read: List configurations in the intended Org or request a specific registryId. Registry responses use createdAt, an ISO 8601 timestamp, in v1.2.0. Update integrations that previously read creationTime.
• Sort: Use sorting=createdAt desc for newest first, or createdAt asc for oldest first. Newest first is the default; registryName is also a supported sorting field.
• Update: Send the intended configuration to the PUT endpoint using its Org and registryId. Apply the same name, host and provider-specific credential rules, then read the configuration back to verify it. Do not treat this endpoint as a partial PATCH or assume omitted credentials are retained.
• Delete: Use the DELETE endpoint for that Org and registryId. A successful deletion returns 204 No Content. Check the Org's registry list afterward. Before deleting access settings, review which application images will need that registry for future deployments.

Note: Registry changes do not redeploy applications

Creating or updating a registry configuration does not automatically trigger a deployment. Deploy the Stack again when devices need to receive the updated registry settings.

Constraints

• registryName: Required, non-empty and no more than 32 characters. The name must be unique within the Org. In v1.2.0, Update checks the same Org rather than the entire tenant, so another Org can use the same name.
• registryUrl: Required and must be a valid HTTP or HTTPS registry URL.
• Credentials: Follow the selected registry type's requirements. Paired fields must be submitted together; for explicit AWS authentication, provide all three AWS fields together.

Registry Host Uniqueness in v1.2.0

WEDA Node chooses image pull credentials by registry host. To avoid ambiguous matches, WEDA rejects a new configuration whose host is already configured in the same Org, even if its registry name is different.

For this comparison, WEDA lowercases the host, removes the URL scheme, path, user information, query and default port, and retains a non-default port:

Registry URL	Host used for duplicate detection
https://reg.example.com	reg.example.com
http://reg.example.com/v2/	reg.example.com
https://REG.example.com:443	reg.example.com
https://reg.example.com:5000	reg.example.com:5000

The first three entries count as the same host. The fourth is distinct. These examples explain duplicate detection; use your registry provider's connection URL when configuring access.

The Docker Hub hostnames docker.io, index.docker.io, registry-1.docker.io and hub.docker.com also count as the same host, docker.io.

Note: Handle a registry host conflict

A duplicate host returns 409 Conflict, with title WEDA.ContainerMgmt.RegistryHostExists. Find the existing configuration in the same Org and reuse or update it. Changing only the registry name, URL scheme or path does not avoid the host conflict.

On Update, the host check runs only when the normalized host changes. Duplicate configurations created before this rule are retained and can still be edited while their host remains unchanged. The upgrade does not automatically consolidate those configurations.

For API error handling, distinguish a host conflict from a name conflict, WEDA.ContainerMgmt.RegistryNameExists. For 400 field-validation errors, inspect validationItems[].fieldName and validationItems[].detail to identify the field and correction needed.

Using the Registry with a Stack

Container Stacks reference images by registry hostname and image path, such as harbor.company.com/factory/inspection:1.0. They do not directly reference a WEDA registryId.

During deployment, WEDA Core supplies the target Org's registry configurations to WEDA Node so it can authenticate with the registries referenced by the Stack. Keep the image host and the intended registry access settings aligned.

Related

• Define the application and its revisions in Container Stack Management.
• Deploy a revision and check device results in Container Deployment & Commands.