Tencent Container Registry

Operation Guide

Product Documentation

Copyright Notice

©2013-2026 Tencent Cloud. All rights reserved.

Copyright in this document is exclusively owned by Tencent Cloud. You must not reproduce, modify, copy or distribute in any way, in whole or in part, the contents of this document without Tencent Cloud's the prior written consent.

Trademark Notice

All trademarks associated with Tencent Cloud and its services are owned by the Tencent corporate group, including its parent, subsidiaries and affiliated companies, as the case may be. Trademarks of third parties referred to in this document are owned by their respective proprietors.

Service Statement

This document is intended to provide users with general information about Tencent Cloud's products and services only and does not form part of Tencent Cloud's terms and conditions. Tencent Cloud's products or services are subject to change. Specific products and services and the standards applicable to them are exclusively provided for in Tencent Cloud's applicable terms and conditions.

Contents

Operation Guide

Creating an Enterprise Edition Instance

Last updated：2025-12-22 17:33:20

Overview

This document introduces how to purchase a Tencent Container Registry (TCR) Enterprise Edition instance on the TCR purchase page.

Prerequisites

Before purchasing a TCR Enterprise Edition instance, complete the following tasks:
Sign up for a Tencent Cloud account and complete identity verification.
Activate Cloud Object Storage (COS), which is used to store image data.
Activate Virtual Private Cloud (VPC) and Private DNS, which are used for image push and pull in a VPC.
Activate the TCR service in the console and grant required operation permissions on your COS and VPC resources.

Directions

Creating via the console

1. Log in to the Tencent Cloud console, choose Products > Basic > Container > TCR, and click Buy Now to go to the TCR console.
2. Click Instance management in the left sidebar to go to the Instance management page and click Create.
3. On the TCR Purchase page, purchase an instance. You can use the following information for reference:



Billing Mode: TCR is billed in pay-as-you-go mode. For more information, see Billing Overview.
Instance Name: Enter a custom instance name. The name must be globally unique and cannot be identical with an existing instance name of your own or another user. This name is used as the access domain name of this TCR instance. The name cannot be modified after the instance is purchased. We recommend that you use an abbreviation that combines the company name and instance region or project as the instance name.
Instance Region: Select a region where you want to deploy the instance. The region cannot be modified after the instance is purchased. Select the region based on the location of the container cluster resources.
Instance Specification: Select the instance specifications that you want to purchase. Different instance specifications have different instance performance levels and quotas. Make your choices based on the specification comparison on the page.
Instance Domain Name: The instance domain name that is automatically generated. Its prefix is the same as the instance name. The instance domain name cannot be modified after the instance is purchased. This domain name is used when you run the docker login command to log in to the instance.
Backend Storage: When an instance is purchased, a Tencent Cloud COS bucket is automatically purchased and associated under the current account. Images and other data in the instance will be stored in the bucket, and storage and traffic costs will be generated. For more information, see COS Billing Guide. After instance purchase, you can go to the COS console to view the bucket. Avoid mistakenly deleting the bucket because data such as images hosted in the instance cannot be recovered after the bucket is deleted.
COS multi-AZ: Optional. COS provides the multi-AZ storage architecture. We recommend that you enable the COS multi-AZ feature to achieve multi-AZ disaster recovery for higher data reliability and service availability. This feature incurs higher storage costs. For more information, see MAZ Feature Overview.
Instance Tag: Bind the newly created instance to a Tencent Cloud tag. You can also bind and edit tags on the instance details page after you purchase the instance.
4. Read and agree to the TCR Service Agreement. Enterprise Edition instances are billed differently based on their region and specifications. Confirm the selected specifications and configuration fees after configuring the basic information.
5. After checking the selected option, click Buy Now to purchase the Enterprise Edition instance you have selected and configured.
6. You can view the instance purchase progress on the Instance management page. If the instance status is Running, the instance is purchased and is running properly.
Note:
If it takes an unusually long time to purchase an instance or the displayed status is Abnormal, please submit a ticket.

Creating via API

You can also create an instance by calling the CreateInstance API. For more information, see CreateInstance.

Overview

If you purchase Enterprise Edition instances in pay-as-you-go mode, fees will be generated on an hourly basis after an instance is created, and the specific fees will be displayed on the purchase page. You can go to the Billing Center to view the fees generated by this service. If you have any doubt about the fees, please submit a ticket to contact us.

Access Configuration

Credential Access Control

Managing User Accounts

Last updated：2025-12-22 17:33:20

Overview

To push/pull container images, you need to log in to the instance first with the access credential. TCR supports credentials of user accounts and service accounts. This document describes how to manage user accounts.
If you want to use multiple sub-accounts to manage and operate your TCR Enterprise Edition instance, such as pushing or pulling images, you must first log in as the account admin and grant each sub-account permissions. For more information, see TCR Enterprise Authorization Management. When a user logs in to the TCR console by using a sub-account, a user account is generated. This user account is a Docker Registry access credential associated with the user’s identity, because the username of the access credential is the same as the ID of the Tencent Cloud sub-account. The user uses this user account to log in to the repository, and push and pull images. Operations of this user account on images are recorded and can be traced back to the user for internal auditing.
When you create a user account, you can create a temporary login token or long-term access credential. We recommend that you create a temporary login token for temporary image push or pull to avoid data security risks due to unexpected credential leakage.
Long-term access credential: A long-term access credential is permanently valid, and can be disabled or deleted. You can use the long-term access credential in scenarios such as early-stage testing, continuous integration and continuous deployment (CI/CD), and image pull in a container cluster.
Note:
Keep the access credential properly. If it is lost, disable or delete it promptly.
Temporary login token: A temporary login token is valid for 1 hour and cannot be disabled or terminated. You can use the temporary login token in scenarios such as one-time external authorization, or in a production cluster with high security requirements by regular refreshing.

Prerequisites

You have purchased a TCR Enterprise Edition instance.
To obtain the access credential through an API, you must obtain the API key that is required for calling v3.0 APIs.

Directions

Obtaining a long-term access credential

1. Log in to the TCR console and choose Access credential > User accounts in the left sidebar.
2. On the User accounts page, select a region and an instance, and click Create.
3. On the Create Access Credential page, perform the following steps:
3.1 In the Create Access Credential step, specify the purpose of the credential in Usage Description, and click Next.
3.2 In the Save Access Credential step, click Save Access Credential to download the access credential. This is your only chance to download the access credential. Save it properly.



4. You can view, disable, or delete a created access credential on the Access credential tab.

Obtaining a temporary login token

1. Log in to the TCR console and choose Access credential > User accounts in the left sidebar.
2. On the User accounts page, select a region and an instance. Click Generate Temp Login Token.
3. On the Temp login token page, click Copy login token to obtain a temporary access credential.




Creating via API

You can also create an instance access credential by calling the CreateInstanceToken API. For more information, see CreateInstanceToken.

Related Operations

Log in to the TCR Enterprise Edition instance. For more information, see Logging in to the TCR instance.

Overview

A long-term access credential will be created automatically in some scenarios:

1. When you install the TCR add-on in a TKE cluster, a long-term access credential is automatically created for the selected instance. This credential will not be automatically terminated when the add-on is deleted. If you do not want to use it any more, you need to manually delete it.
2. When you use the image building or delivery pipeline feature, a dedicated access credential is automatically created and provided to the CODING DevOps service to push the auto-built images. Do not delete the access credential directly. Otherwise, the build configurations of the existing images become invalid.

Managing Service Accounts

Last updated：2025-12-22 17:33:20

Overview

To push/pull container images, you need to log in to the instance first with the access credential. TCR supports credentials of user accounts and service accounts. This document describes how to manage service accounts, which is applicable to CI/CD automation scenarios.
A user account is bound with your Tencent Cloud account. The username must be the same as the Tencent Cloud account ID, and the password is generated randomly. The permission of the user account is controlled by the CAM permission of the associated Tencent Cloud account. When the associated Tencent Cloud account is deleted or disabled, the user account goes invalid. This can cause image push/pull failures in Kubernetes clusters or CI/CD scenarios. For more information, see Managing User Accounts.
For CI/CD scenarios or you want to configure permissions on the namespace level, we recommend using the service account. Service Account supports the following features:
Custom username and password
Namespace-specific read/write permission configuration
Custom validity period. You can disable a service account temporarily.
Note:
1. Service-level accounts support the operation audit. The service-level accounts used for upload and download operations are recorded in operation audit logs, but the actual user identities of the accounts cannot be verified or traced by the platform. Be cautious when distributing service-level accounts externally. User-level accounts are recommended if the image pulling or pushing operators or account holders need to be audited strictly.
2. The permission configuration of a service account prevails the CAM permissions. It means that service account can perform namespace-specific operations that do not allowed by the associated Tencent Cloud account. This brings the risk of broken access control. We recommend only assign the service account to the administrators of the instance.

Prerequisites

Purchase a TCR Enterprise Edition instance.
To obtain the access credential via API, obtain the API key for calling API 3.0.

Directions

Creating a service account

1. Log in to the TCR console and choose Access credential > Service accounts in the left sidebar.
2. On the Service accounts page, select a region and an instance, and click Create.
3. On the Create service account page, set the parameters as instructed below:
Name (Required): Custom name of the account. It supports [a-z], [0-9] and [._-], and must start with a letter or digit. The prefix tcr$ is automatically added to the name to mark it as a service account. For example, if you enter robot-demo, the actual username is tcr$robot-demo.
Note:
Certain open-source Continuous Integration (CI)/Continuous Deployment (CD) platforms may not correctly process the tcr$ prefix. The backend supports the tcr@ prefix by default. For example, you can use tcr@robot-demo as the username for replacing tcr$robot-demo. If you encounter any issues, please submit a ticket for consultation.
Description: Enter the account description.
Validity: Select Permanent or specify a validity period (in days). The default value is 30 days.
Permission configuration: Configure the namespace-specific permission. Select namespaces based on the principle of least privilege.
Namespace: Select target namespaces
Permission type: Select Read-only or Read/Write. In the Read-only mode, image push is not supported.

4. Note down the username and password immediately after the account is created. This page will be displayed only once and the credential information cannot be retrieved after the page is closed.



Managing service accounts

1. Log in to the TCR console and choose Access credential > Service accounts in the left sidebar.
2. On the Service account page, select the region and instance name.
Check existing service accounts
Check the permissions of service accounts
Modify the service account configuration (except the account name)
Enable/Disable service accounts. Note that after an account is disabled, you cannot use it to push or pull images.
Delete service accounts. Note that after an account is deleted, you cannot use it to push or pull images.


Network Access Control

Network Access Control Overview

Last updated：2025-12-22 17:33:20

Tencent Container Registry (TCR) supports network access control for TCR Enterprise instances. To ensure data security of your image repositories and Helm Charts, the public and private network access entries are disabled for the newly created TCR Enterprise instances by default. This means that all external access requests are denied.
Based on your application requirements, you can configure public and private network access control policies to minimize the application clients that can access the instance and pull/push images. For more information, please see:
Public network access control
Private network access control

Configuring Public Network Access Control

Last updated：2025-12-22 17:33:20

Overview

Tencent Container Registry (TCR) Enterprise supports public network access control. An allowlist can be configured to restrict instance access by clients through the Internet, ensuring instance data privacy and security. When a TCR Enterprise instance is created, the public network access entry is disabled by default. This means that you cannot use a development test server to push or pull images over the internet. This document describes how to configure public network access control for a TCR Enterprise instance.

Prerequisites

Before configuring public network access control for a TCR Enterprise instance, you must create a TCR Enterprise instance.

Directions

Enabling the public network access entry

1. Log in to the TCR console and select Network ACL > Public network in the left sidebar.
2. To change the instance, select the region where the desired instance is deployed and the desired instance name from the Instance name drop-down list at the top of the "Public network" page.
3. Select Open internet access entry to enable the public network access entry. When the status of the button changes from Enabling to Close internet access entry, and Add a public IP to allowlist is in a selectable status, it indicates that the entry is enabled, as shown in the following figure. After the entry is enabled, all internet access requests are still denied.


Configuring the access policy

1. On the “Public network” page, click Add a public IP to allowlist. Configure the public IP range and notes in the pop-up window.
Associated instance: The target instance, for which the public network access policy is configured. To change the instance, select the desired instance name from the "Instance name" drop-down list at the top of the "Public network" page.
Method: You can manually configure public IP addresses or import the public IP list from an existing security group.
Manually configure: The public IP address range that is allowed to access the instance. The value can be a single IPv4 address or CIDR block, for example, 192.168.0.0/24. We do not recommend that you enter 0.0.0.0/0 to accept all internet access requests to the instance.
Import existing: All allowed addresses in the inbound rules will be deduplicated and imported to the allowlist. After importing, you can further modify the list manually. Please note that the modified security group configurations cannot be synced automatically, and you need to re-import them again.
Note: Notes about the access policy. This parameter is optional.
2. Click OK. The public network access allowlist policy is added and takes effect.
If the public network access entry cannot be enabled or the allowlist policy cannot be created, you can submit a ticket.

Private Network Access Control

Last updated：2025-12-22 17:33:20

Overview

Tencent Container Registry (TCR) Enterprise Edition supports private network access control. A private network access linkage can be used to restrict instance access by clients in a Virtual Private Cloud (VPC). In actual production scenarios involving container computing, pulling container images through a VPC can effectively improve the pulling speed and reduce public network bandwidth costs. TCR allows users to connect their VPCs to a TCR Enterprise Edition instance to implement private network access and access control.
This document describes how to configure private network access control for a TCR enterprise edition instance. After completing the following configuration, you can use a Cloud Virtual Machine (CVM) in a specified VPC to pull images from a TCR instance through the private network, or pull container images in TKE and other container clusters through the cluster private network. For more information, see TKE Clusters Use the TCR Addon to Enable Secret-free Pulling of Container Images via Private Network.

Prerequisites

Make sure that the following conditions are met before configuring private network access control for a TCR Enterprise Edition instance:
You have purchased a TCR Enterprise Edition instance.
If you are using a sub-account, the sub-account must have obtained operation permissions on the corresponding instance. For more information, see TCR Enterprise Authorization Management.
You have activated the VPC service and created a VPC and a subnet in the region where the TCR Enterprise Edition instance is deployed.
You have activated the Private DNS service.

Directions

Creating an access linkage

1. Log in to the TCR console and choose Access Control > Private Network Access in the left sidebar.
2. On the Private Network Access page, click Create.
3. In the Create a private network access linkage pop-up window, specify a VPC and a subnet, as shown in the figure below:



Associated Instance: Target instance for which the private network access policy is configured. To change the instance, select another instance name from the Instance Name drop-down list at the top of the Private Network Access page.
Region: Region where the VPC to access resides, which is the same as the region where the current instance is deployed by default. If the multi-region replication feature is enabled for the current instance and replicas are configured for the instance in multiple regions, you can select the region where a replica is deployed to access the VPC of the replica. For more information, see Configuring Instance Replication.
Virtual Private Cloud:
First, select the VPC that you want to connect to. The drop-down list displays all available VPCs in the region of the current instance.
Then, select a subnet with usable private IPs in the VPC. Creating a private network access linkage occupies a private IP in the subnet. The IP is also used as the destination IP for private network resolution of the instance domain name. The subnet is only used to assign private network access addresses. After the linkage is created, CVMs in subnets of the VPC can access the TCR Enterprise Edition instance through the linkage.
4. Click OK to start creating the private network access linkage. If the access linkage status changes to Normal linkage and the private network parsing IP is not empty, the private network access linkage was successfully created.



Note:
By default, only resolution for public network access is configured for the access domain name of the instance. After connecting the instance to the specified VPC and obtaining the private network parsing IP, click Manage Auto-parsing to configure the dedicated private network parsing for the instance domain name in the VPC.

Managing private network parsing

After the private network access linkage is established, CVMs in the associated VPC access the instance through the private network by accessing the private network parsing IP. By default, the default domain name of the instance (for example, tcr-demo.tencentcloudcr.com) and private network domain name (for example, tcr-demo-vpc.tencentcloudcr.com) will not be automatically resolved to the private network parsing IP in the VPC. You need to use the Manage Auto-parsing feature to configure private network parsing, or use an external DNS service to manage parsing.

Using Private DNS for automatic configuration (default method)

By default, Tencent Cloud Private DNS is used to configure domain name resolution in VPCs. You need to activate the service before using this feature.
1. Log in to the TCR console and choose Access Control > Private Network Access in the left sidebar.
2. On the Private Network Access page, click Manage Auto-parsing next to the created private network access linkage.
3. In the Manage Auto-parsing pop-up window that appears, configure domain name resolution for the linkage, as shown in the figure below:

DNS Service: Indicates whether Private DNS is activated. If the service is not activated, click Activate Service to activate it. No additional fees will be charged on the products using Private DNS.
Resolution Configuration: This feature is disabled by default. You can turn on the switch to enable automatic resolution of the default domain name. After this feature is enabled, the instance domain name will be resolved to the private IP in the VPC instead of being resolved to a public IP of the instance. The instance will be used to push and pull images in the private network without the need to configure the domain name resolution manually or by using the TCR add-on.
Advanced Configuration: You can configure the auto-parsing of VPC domain names. VPC domain names are dedicated domain names in VPCs. You can use a VPC domain name in VPCs to distinguish it from the default domain name used in the public network. By default, an image repository provides the access address of the default domain name and related operation instructions. If you use a dedicated VPC domain name, modify the access address configuration of the image repository.
4. Click OK.

Using the TCR add-on for automatic configuration

This solution is applicable to the scenarios where Private DNS has not provided services in the region where the TKE cluster is located. This solution is not recommended by default.
If you are using TKE, refer to TCR to install the TCR add-on in the TKE cluster and select Enable Private Network Parsing in the TCR Component Parameter Setting window. For nodes in the cluster, this add-on can automatically configure private network resolution for the associated TCR instance. This enables secret-free pulling of images in the instance through the private network.

Manually configuring a CVM host

This solution is applicable to CVMs or nodes located in self-built Kubernetes clusters in VPCs that require temporary access to TCR Enterprise Edition instances. It is not recommended by default.
Here, a Linux CVM is used as an example. Log in to the CVM and run the following command:
echo '172.16.1.95 techo-demo.tencentcloudcr.com' >> /etc/hosts
Replace 172.21.17.69 and demo.tencentcloudcr.com with the private network parsing IP and TCR instance domain name that you use.

Access Permission Configuration

Access Permission Management Overview

Last updated：2025-12-22 17:33:20

Tencent Container Registry (TCR) provides two modes of access permission management for Enterprise Edition instances. An instance administrator can allocate independent access credentials to the instance development and Ops personnel and internal automated systems such as continuous integration (CI)/continuous deployment (CD), and implement fine-grained user permission management to ensure instance data security.

Scenarios

Personnel Permission Control

An Enterprise Edition instance purchased is usually used by multiple teams that include various roles such as R&D, Ops, and testing roles. While normal business requirements are met, the minimum permissions should be configured for different teams and roles to avoid data security issues such as accidental deletion or leakage of images.
For the specified personnel, an independent account needs to be assigned for identity authentication and independent permissions be configured for operation authentication. When image repositories are used, access credentials (username + password) for login to the repositories (docker login) need to be allocated to the specified personnel, and the account permissions need to be configured, for example, the permissions to push images only to or pull images only from repository A, or the permissions to pull images only from repository B.
Meanwhile, enterprises need to assign personnel to audit image repository operations and trace abnormal operations.

System Permission Control

The production and deployment of container images also involve automated systems, such as CI/CD pipelines. In automation scenarios, using the accounts of the specified personnel may cause severe consequences. For example, if an Ops person's access credential is configured in the release system to enable cluster nodes to pull images, the image access credential will become invalid if the person's account is accidentally deleted, or the technician is transferred or leaves, leading to release failures. Therefore, in the scenarios, access credentials irrelevant to designated personnel should be used, and account permissions should be managed independently.

Product Feature

For the above two typical scenarios, the product provides two access permission management features: user-level account and service-level account. You can use them in combination to meet the requirements for internal permission management.

User-Level Accounts

User-level accounts are directly associated with Tencent Cloud accounts, and account permissions are managed based on Cloud Access Management (CAM). To grant permissions to a specified person within the enterprise, you need to create a dedicated sub-account for the person under the Tencent Cloud root account and associate the sub-account with the permission policy in CAM. For details, see Managing Sub-account Permissions Based on CAM.
The user can use the sub-account to log in to the product console and go to the Access Credential–User-Level Account feature page to create an exclusive access credential. This credential is associated with the sub-account and can only be viewed and managed by the sub-account. The user can use this credential to log in to image repositories and push and pull images. Actual operations are controlled by the associated policy.
Note:
Note that when a sub-account is disabled or deleted, the associated access credential will become invalid. Therefore, you are not advised to configure access credentials associated with the sub-account in automated systems.
For use of user-level accounts, see User-Level Accounts.

Service-Level Accounts

Service-level accounts are not directly associated with Tencent Cloud accounts and belong to resources within instances. Their permission management is independent of CAM. To configure access credentials for automatically pushing or pulling images for automated systems such as CI/CD pipelines and Kubernetes clusters, you can create a service-level account within an instance and configure the namespaces that can be accessed by using the access credentials.
Note:
Because a service-level account is a resource within an instance, all sub-accounts with API permissions related to the service-level account feature can view and manage the service-level account. Meanwhile, because the service-level account has permissions independent of the CAM permission system, the risk of unauthorized access may occur. Strictly control the authorization scope of relevant APIs.
For use of service-level accounts, see Service-Level Accounts.

CAM APIs for Enterprise Edition

Last updated：2025-12-22 17:33:20

Instance Management APIs

APIs and Description
Resource Type
Six-segment Example of Resource
CreateInstanceCreating an instance
instance
qcs::tcr:$region:$account:instance/$instanceid
DescribeInstanceStatusQuerying the instance status
instance
qcs::tcr:$region:$account:instance/*qcs::tcr:$region:$account:instance/$instanceid
DescribeInstancesQuerying the instance information
instance
qcs::tcr:$region:$account:instance/*qcs::tcr:$region:$account:instance/$instanceid
CreateInstanceTokenCreating an instance access credential
instance
qcs::tcr:$region:$account:instance/$instanceid
DeleteInstanceTokenDeleting a long-term access credential
instance
qcs::tcr:$region:$account:instance/$instanceid
ModifyInstanceTokenUpdating the instance’s long-term access credential
instance
qcs::tcr:$region:$account:instance/$instanceid
DescribeInstanceTokenQuerying the long-term access credential information
instance
qcs::tcr:$region:$account:instance/$instanceid


Namespace APIs

APIs and Description
Resource Type
Six-segment Example of Resource
CreateNamespaceCreating a namespace
repository
qcs::tcr:$region:$account:repository/$instanceId/$namespaceName
DeleteNamespaceDeleting a namespace
repository
qcs::tcr:$region:$account:repository/$instanceId/$namespaceName
ModifyNamespaceUpdating the namespace information
repository
qcs::tcr:$region:$account:repository/$instanceId/$namespaceName
DescribeNamespacesQuerying the namespace information
repository
qcs::tcr:$region:$account:repository/$instanceId/*qcs::tcr:$region:$account:repository/$instanceId/$namespaceName


Image Repository APIs

APIs and Description
Resource Type
Six-segment Example of Resource
CreateRepositoryCreating an image repository
repository
qcs::tcr:$region:$account:repository/$instanceId/$namespaceName/$repositoryName
DeleteRepositoryDeleting an image repository
repository
qcs::tcr:$region:$account:repository/$instanceId/$namespaceName/$repositoryName
ModifyRepositoryUpdating the image repository information
repository
qcs::tcr:$region:$account:repository/$instanceId/$namespaceName/$repositoryName
DescribeImagesQuerying the container image information
repository
qcs::tcr:$region:$account:repository/$instanceId/$namespaceName/$repositoryName/*
DescribeImagesQuerying the image repository information
repository
qcs::tcr:$region:$account:repository/$instanceId/$namespaceName/*qcs::tcr:$region:$account:repository/$instanceId/$namespaceName/$repositoryName


Managing Sub-account Permissions Based on CAM

Last updated：2025-12-22 17:33:20

This document describes how to enable sub-accounts to view and use the TCR Enterprise related resources through the CAM policy, including specific operation steps and common policy configuration examples.
Note:
If you need the permissions of other Tencent Cloud services when using some features in TCR console such as VPC, CloudAudit, Tag, please see the corresponding CAM Guide in CAM-Enabled Products.

Introduction to Cloud Access Management

Cloud access management (CAM) is a web service provided by Tencent Cloud. It helps users securely manage the permissions for accessing resources under their Tencent Cloud accounts. CAM allows you to create, manage, or terminate users (groups) and controls who can use Tencent Cloud resources through identity management and policy management.
When you use CAM, you can associate a policy with a user or a user group. The policy authorizes or refuses users to use the specified resource to complete the specified task. For more information on CAM policies, refer to Policy Syntax. For more information on how to use CAM policies, refer to Policies.
If you do not need to perform access management of TCR resources for sub-accounts, you can skip this section. This does not affect your understanding and use of other sections of this document.

CAM-based Resource-level Access Control of TCR

Resource-level permissions refer to the capabilities that can specify and allow users to perform specific operations on specific resources. TCR supports resource-level access control of CAM and controls the granularity to the repository level, that is, you can authorize sub-accounts to perform operations on resources in only the specified image repository or the Helm Chart repository by configuring the CAM policy.
Types of resources that can be authorized by TCR in CAM:
Resource Type
Resource Description Method in Authorization Policy
Enterprise edition instance
qcs::tcr:$region:$account:instance/*
Enterprise edition repository
qcs::tcr:$region:$account:repository/*
Personal edition repository
qcs::tcr:$region:$account:repo/*
$region: the region information. For example, ap-guangzhou indicates the region of Guangzhou. If the value is null, the field indicates all regions. For the specific list of regions and abbreviations, refer to Regions and Availability Zones.
$account: the root account of the resource owner. The value is expressed as uin/${uin}, for example, uin/12345678. If the value is null, the field indicates the root account of the CAM user who creates the policy.
For details on resource description in the authorization policy, refer to Resource Description.

Directions

This document takes the example of "granting the sub-account the read-only permission of an image repository" to introduce how to create a policy.
Instance ID: tcr-xxxxxxxx
Namespace: team-01
Image repository: repo-demo
Creating by policy generator (recommended)
1. Log in to the CAM console.
2. In the left sidebar, click Policies to go to the policy management page.
3. Click Create custom policy in the upper-left corner.
4. In the pop-up window, click Create by policy generator to go to the Edit policy page.
5. Select the service in the Visual Policy Generator, enter the following information, and edit an authorization statement.
Effect: Select Allow or Deny. Here, we select Allow.
Service: Select the service you want to authorize. Here, we select Tencent Container Registry (tcr).
Action: Select the operations you want to authorize. Here, we select Read.
Resource: Select all resources or specific resources you want to authorize. Here, we select Specific resources, and add the following six-segment resource to restrict the access.
repository: Select the region where the repository resides, and enter the resource path of the repository, for example, tcr-xxxxxxxx/team-01/repo-demo/*. You can get the resource path in Image Repository.
repo: It is left empty.
instance: Select the region where the repository resides, and enter the ID of the instance to which the repository belongs, for example, tcr-xxxxxxxx. You can get the instance ID in the Instance List.
Condition: It is left empty.
6. Click Next to go to the Associate users/user groups page.
7. On the Associate users/user groups page, add the policy name and description, and you can associate users or user groups for quick authorization at the same time.
8. Click Complete to complete the custom policy creation.
Creating by policy syntax
1. Log in to the CAM console.
2. In the left sidebar, click Policies to go to the policy management page.
3. Click Create custom policy in the upper-left corner.
4. In the selection window that pops up, click Create by policy syntax to go to the Select policy template page.
5. In Select a template type section, select Blank template.
6. Click Next to go to the Edit policy page.
7. In the Edit policy page, enter the policy name and description, and add the following policy content.
 {
     "version": "2.0",
     "statement": [{
             "action": [
                 "tcr:DescribeRepositories",
                 "tcr:PullRepository",
                 "tcr:DescribeNamespaces"
             ],
             "resource": [
                 "qcs::tcr:::repository/tcr-xxxxxxxx/team-01/repo-demo/*"
             ],
             "effect": "allow"
         },
         {
             "action": [
                 "tcr:DescribeInstance*"				
             ],
             "resource": [
                 "qcs::tcr:::instance/tcr-xxxxxxxx"
             ],
             "effect": "allow"
         }
     ]
 }
8. Click Complete to complete the custom policy creation.

Common Policy Configuration

If you need to customize the policy JSON, please see CAM APIs for TCR Enterprise and Syntax Logic.

Preset policy configuration

QcloudTCRFullAccess: Full read/write permission of TCR. After the policy is bound to a sub-account, the sub-account has all operation permissions for all TCR resources, including TCR Enterprise and TCR Individual.
  {
      "version": "2.0",
      "statement": [{
          "action": [
              "tcr:*"
          ],
          "resource": "*",
          "effect": "allow"
      }]
  }
QcloudTCRReadOnlyAccess: Read-only permission of TCR. After the policy is bound to a sub-account, the sub-account has the read-only permission for all TCR resources, including the TCR Enterprise and TCR Individual.
  {
      "version": "2.0",
      "statement": [{
          "action": [
              "tcr:Describe*",
              "tcr:PullRepository*"
          ],
          "resource": "*",
          "effect": "allow"
      }]
  }

Policy configuration in typical scenarios

Note:
The following scenario policies are only used for TCR Enterprise use cases. For the policies used for TCR Individual, please see Example of Authorization Solution of TCR Individual.
Grant a sub-account all read/write operation permissions for all resources in TCR Enterprise.
  {
      "version": "2.0",
      "statement": [{
          "action": [
              "tcr:*"
          ],
          "resource": [
              "qcs::tcr:::instance/*",
              "qcs::tcr:::repository/*"
          ],
          "effect": "allow"
      }]
  }
Grant a sub-account the read-only permission for all resources in TCR Enterprise.
  {
      "version": "2.0",
      "statement": [{
          "action": [
              "tcr:Describe*",
              "tcr:PullRepository*"
          ],
          "resource": [
              "qcs::tcr:::instance/*",
              "qcs::tcr:::repository/*"
          ],
          "effect": "allow"
      }]
  }
Grant a sub-account permissions to manage the specified instance, for example, dev-guangzhou, whose instance ID is tcr-xxxxxxxx.
  {
      "version": "2.0",
      "statement": [{
          "action": [
              "tcr:*"
          ],
          "resource": [
              "qcs::tcr:::instance/tcr-xxxxxxxx",
              "qcs::tcr:::repository/tcr-xxxxxxxx/*"
          ],
          "effect": "allow"
      }]
  }
Grant a sub-account permissions to manage the specified namespace in the specified instance, for example, team-01 under the instance tcr-xxxxxxxx.
  {
      "version": "2.0",
      "statement": [{
              "action": [
                  "tcr:*"
              ],
              "resource": [
                  "qcs::tcr:::repository/tcr-xxxxxxxx/team-01",
                  "qcs::tcr:::repository/tcr-xxxxxxxx/team-01/*"
              ],
              "effect": "allow"
          },
          {
              "action": [
                  "tcr:DescribeInstance*"
              ],
              "resource": [
                  "qcs::tcr:::instance/tcr-xxxxxxxx"
              ],
              "effect": "allow"
          }
      ]
  }
Grant a sub-account the read-only permission of an image repository, which means that the sub-account can only pull the images in the image repository instead of deleting a repository, modifying repository attributes, or pushing images, for example, repo-demo in the namespace team-01 under the instance tcr-xxxxxxxx.
  {
      "version": "2.0",
      "statement": [{
              "action": [
                  "tcr:Describe*",
                  "tcr:PullRepository"
              ],
              "resource": [
                  "qcs::tcr:::instance/tcr-xxxxxxxx",
                  "qcs::tcr:::repository/tcr-xxxxxxxx/team-01",
                  "qcs::tcr:::repository/tcr-xxxxxxxx/team-01/repo-demo",
                  "qcs::tcr:::repository/tcr-xxxxxxxx/team-01/repo-demo/*"
              ],
              "effect": "allow"
          }
      ]
  }


Access Domain Name Configuration

Configuring Custom Domain Name

Last updated：2025-12-22 17:33:20

Overview

Tencent Container Registry (TCR) Enterprise Edition allows you to configure and use custom domain names, which facilitates the use of the domain access service uniformly planned by your company. In addition, you can continue using the original domain name after migrating from another image registry service to TCR, which helps maintain the service continuity.
TCR Enterprise Edition instances with any specifications all support configuring multiple domain names without affecting the normal use of existing default domain names of the instances. To use a custom domain name, you need to provide the SSL certificate associated with the domain name and access the instance over HTTPS. This document describes how to use a custom domain name to access a TCR Enterprise Edition instance.

Concepts

Domain name

A domain name is a string of characters separated by dots. A domain name in TCR Enterprise Edition is used to access the instance service and directly determines the access address of an image repository.

SSL certificate

An SSL certificate is used for compliance with the HTTPS protocol, so that TCR Enterprise Edition can implement encrypted transfer and identity verification over the HTTPS protocol, ensuring the transfer security.

DNSPod

DNSPod can route the access traffic to a custom domain name to the corresponding IP address of a TCR Enterprise Edition instance.

Prerequisites

Before configuring and using a custom domain name, you need to complete the following:
Get a domain name. You can register one in Tencent Cloud Domains.
Note:
Get an ICP filing for you domain name if you want to use it in a public network environment.
You do not need to get an ICP filing if your TCR Enterprise Edition instance is outside the Chinese mainland.
Get a certificate for the domain name. You can purchase a certificate in SSL Certificates and confirm that it has been bound to the custom domain name to be used by the instance.
Activate DNSPod. For more information, see Private DNS.

Directions

Creating custom domain name

1. Log in to the TCR console and select Domain Name Management on the left sidebar.
2. On the Domain Name Management page, select the region and ID of the instance for which you want to add a custom domain name.
3. Click Add custom domain. In the Add Domain Name pop-up window, configure the domain name and certificate information as prompted as shown below:


Domain Name: enter the custom domain name to be used. We recommend you use a common domain suffix.
Certificate: select a certificate bound to the custom domain name. Only a certificate managed in SSL Certificates can be selected.
Note:
If your custom domain name has been filed with MIIT, and a DNS record has been added in the Domains console, you can enter it in the Domain Name input box and select a certificate.
4. Click OK. After adding a custom domain name successfully, you can view it on the Domain Name Management page. Then, you can perform the following operations to manage the custom domain name as shown below:



Setting access control and DNS

You can use the custom domain name in the public network or VPC. We recommend you use a VPC to access the instance preferably.
Private network access

Configuring private network access control

Connect a VPC to the instance and confirm that the private network access IP is generated normally as instructed in Private Network Access Control.

Configuring Private DNS

Log in to the Private DNS console, use the added custom domain name to create a private domain, associate it with the connected Virtual Private Cloud (VPC), and configure the Domain Name System (DNS) record for this private domain.
1. Use a canonical name (CNAME) record pointing to the standard access domain name of an instance. Note that automatic DNS needs to be enabled when VPC access is configured in Tencent Container Registry (TCR).
2. Use an address (A) record pointing to the private network access IP address of the created private network access link. Note that the private network access IP address may change when VPC is accessed again subsequently.
For details, see Private DNS.
Public network access

Configuring public network access control

Enable the public network access entry and open the public network access address as instructed in Public Network Access Control.

Configuring public network DNS

Go to the DNSPod console, configure a DNS record for the added custom domain name, select CNAME as the record type, and enter the default domain name of the instance as the record value.

Updating domain certificate

If you need to update the certificate bound to your custom domain name for reasons such as certificate expiration or upgrade, go to the Domain Name Management page, click Update Certificate on the right of the row of the custom domain name and select an SSL certificate again. Certificate update requires redelivery of the SSL certificate information, during which the custom domain name can still be accessed normally.

Deleting custom domain name

On the Domain Name Management page, click Delete on the right of the row of the specified custom domain name to delete it. Doing so may invalidate the existing container image pull configuration and thus affect application update. Therefore, do so with caution.

Manage Image Repository

Managing Namespaces

Last updated：2025-12-22 17:33:20

Overview

In Tencent Container Registry (TCR) Enterprise Edition, a namespace is used to manage multiple associated image repositories and Helm charts. It does not directly store container images or Helm charts, but can map to teams, product projects, or individuals in an enterprise.
TCR Enterprise Edition instances are exclusive for an enterprise. Therefore, you do not need to worry that a namespace may be occupied by other users when creating the namespace. However, if you create a namespace in a TCR Personal Edition instance, the name of the namespace must be different from that of any existing namespaces. This document describes how to create and manage a namespace in a TCR Enterprise Edition instance.

Prerequisites

Before creating and managing a namespace in a TCR Enterprise Edition instance, complete the following preparations:
Purchasing Instances.
If you are using a sub-account, you must have granted the sub-account required permissions for the instance. For more information, see Example of Authorization Solution of the Enterprise Edition.

Directions

Creating a namespace

1. Log in to the TCR console and select Namespace on the left sidebar.
2. On the Namespace page, you can view the namespace list of the current instance. To change the instance, select the desired instance name from the Instance drop-down list at the top of the page.
3. Click Create. In the Create a Namespace window, configure the name and access level of the namespace as shown below:

Associated Instance: the currently selected instance, to which the created namespace belongs.
Name: the namespace name. It is a string of 2-30 characters. The name can only contain lowercase letters, number, and separators, which are periods (.), underscores (_), and hyphens (-). It cannot start or end with a separator or contain several consecutive separators. We recommend that you set this parameter to the name of an enterprise team or product project. You can also set this parameter to a personal name and use this namespace for personal testing. The namespace names must be unique in an instance.
Access Level: you can select Private or Public. The default value is Private. If you set this parameter to "Public", all image repositories and Helm charts in the namespace are public repositories. If anonymous access is also enabled for this instance (which is enabled by default), any clients in the allowlist can pull images and Helm charts without having to log in. You can modify Access Level after the namespace is created.
Tag: Cloud tags can be bound for the classification and management of resources from the namespace dimension. If existing tags do not meet your requirements, select Manage Tags in the console to manage tags.
4. Click OK.
5. After the namespace is created, you can view the namespace on the "Namespace" page. Then, you can perform the following operations to manage the namespace, as shown in the figure below.



Changing the access level

1. Click the namespace that you want to change the access level and go to its "Basic Information" page.
2. On the "Basic Information" page, click

next to the Access Level. Change the public or private attribute of the namespace in the pop-up window.
Note:
After the access level is changed, all the image repositories and Helm charts in the namespace immediately inherit this attribute. Do not change a private namespace to a public namespace unless necessary.

Changing the security scan mode

1. Click the namespace that you want to change the access level and go to its "Basic Information" page.
2. Click

next to the Security Scan to change the security scan mode for container images in this namespace. You can set the security scan mode to Manually Scan or Auto-scan.
Note:
Changing the security scan mode does not affect the existing security scan results.
Manually Scan: to perform a security scan on a specified container image and view the result, you need to go to the Image Repository page, select the image, and click Scan on the Tag Management tab.
Auto-scan: an automatic security scan is triggered when a new image is pushed to any image repository in the current namespace.

Configuring deployment security

An Enterprise Edition instance can block the deployment of high-risk images. For more information, see High-Risk Image Deployment Blocking.

Deleting a namespace

To delete a namespace, select it and click Delete next to it. To prevent important data from being deleted by mistake, a namespace that still contains image repositories or Helm charts cannot be deleted.

Basic Image Repository Operations

Last updated：2025-12-22 17:33:20

Overview

In Tencent Container Registry (TCR) Enterprise Edition, an image repository is used to manage container images. A single image repository may contain container images with different tags. An image repository belongs to a namespace and inherits the public or private attribute and security scan triggering mode from its namespace.
An image repository is the minimum unit for permission management in TCR. The instance admin can grant image repository management or read-only permissions to a sub-account. For example, the instance admin can grant the tom sub-account only the permission to pull images from the project-a-frontend image repository, but disallow the sub-account to push or delete images. For more information about other permission management and authorization methods, see TCR Enterprise Authorization Management. This document describes how to create and manage an image repository in a TCR Enterprise Edition instance.

Prerequisites

Make sure that the following conditions are met before creating and managing an image repository in a TCR Enterprise Edition instance:
You have purchased a TCR Enterprise Edition instance.
If you are using a sub-account, the sub-account must have obtained operation permissions on the corresponding instance. For more information, see TCR Enterprise Authorization Management.

Directions

Creating an image repository

1. Log in to the TCR console and click Image Repository in the left sidebar. On the Image Repository page, you can view the image repository list of the current instance. To change the instance, select the required instance name from the Instance Name drop-down list at the top of the page.
2. Click Create. In the Create repository pop-up window, configure the image repository, as shown in the figure below:



Associated Instance: Currently selected instance, to which the image repository belongs.
Namespace: Namespace to which the image repository belongs. If the list is empty, create a namespace in the instance.
Name: Name of the image repository. The value must be 2 to 200 characters in length and can only contain lowercase letters, numbers, and separators including periods (.), underscores (_), hyphens (-), and slashes (/). It cannot start or end with a separator or contain several consecutive separators. The name can be a multi-level path, such as team-01/front/nginx. You can set the name flexibly based on your business requirements.
Brief Description: Brief description of the image repository. It is a string that can be up to 100 characters in length. You can edit the description after the image repository is created.
Detailed Description: Detailed description of the image repository. This parameter supports the Markdown syntax. It is a string that can be up to 1000 characters in length. You can edit the description after the image repository is created.
3. Click Confirm.

Performing basic operations on the created image repository

You can view the created image repository on the Image Repository page and perform the following basic operations on the image repository:



Filtering namespaces On the Image Repository page, you can click

and select the target namespace from the drop-down list.
Viewing image repository details Click the name of the image repository. The details page is displayed, where you can manage image tags and edit the basic information of the image repository.
Deleting the image repository You can click Delete next to the image repository to delete it. Carefully confirm the deletion before deleting to prevent important data from being deleted by mistake.
Note:
After the image repository is deleted, all container images in the image repository are deleted.

Managing image tags

Click the name of a specified image repository. The repository details page is displayed, and the Tag Management tab is selected by default. On this tab, you can manage all the image tags in the repository, perform security scans, and view the layer information, as shown in the figure below:

Filtering image tags In the search box in the upper-right part of the tag list, you can enter an image tag to search for this image tag. Fuzzy search is supported.
Obtaining the pulling command You can click Copy command next to a target image tag to copy the pulling command of the image tag.
Performing a security scan You can click Scan for a target image tag to perform a security scan. After the scan result of the security level property appears, click

to view the details.
Viewing the image layer information You can click Layer Information next to a target image repository to view the image layer information in the pop-up window.
Deleting an image tag You can click Delete next to a target image tag to delete this image tag. Carefully confirm the deletion before deleting to prevent important data from being deleted by mistake.
Note:
When a specified image tag is deleted, other image tags that have the same image ID as the deleted image tag may also be deleted. Consequently, these image tags will become unavailable.

Building images

You can compile the source code managed on GitHub, GitLab.com, private Gitlab, Gitee, TGit, or CODING to build images.

Editing the repository information

On the details page of an image repository, select the Repository Information tab. On this tab, you can view and edit the basic information of the image repository, as shown in the figure below:

Editing the brief description Click

next to Brief Description, edit the brief description, and then click Save.
Editing the detailed description Click

next to Detailed Description, edit the detailed description, and then click Save. The Markdown syntax is supported for the detailed description. After you save the description, you can view the effect of text rendering.

Image Distribution

Intra-Instance Multi-Region Image Replication

Last updated：2025-12-22 17:33:20

Overview

Tencent Container Registry (TCR) allows users to create replicas of a premium instance in multiple regions with the same access domain name and credential as the original premium instance. It realizes the single-region upload, multi-region high-speed real-time synchronization, and image pulling from the nearest region over the private network. Compared with the cross-instance synchronization, this feature can unify the publish configuration of multi-regional clusters, improve the cross-region synchronization speed of cloud native artifacts, and help users realize the global synchronization update of service applications.
The instance replication feature allows users to create replicas of a premium instance in multiple regions. The replica instances will synchronize data with the primary instance in real time. Users can use the domain name and access credentials of the primary instance to access the replica instances through the private network. By using the instance replication feature, users can uniformly manage the application images of the multi-regional services, and do not need to purchase multiple Enterprise Edition instances, which can reduce the usage cost, increase the speed of container image distribution, and simplify the deployment and configuration.


Prerequisites

Make sure that the following conditions are met before creating and managing the replica instances of a TCR Enterprise Edition instance:
You have purchased an Enterprise Edition instance with premium specification.
If you are using a sub-account, the sub-account must have obtained operation permissions on the corresponding instance. For more information, see TCR Enterprise Authorization Management.

Use Limits

1. You can pull images from, but not push images to, instances. To push and pull images across regions at the same time, use the cross-instance (account) image synchronization feature, which requires you to create an instance in each region and configure a synchronization rule.
2. The instance replication feature relies on the support of the underlying networks and is subject to security compliance requirements.
Cross-border instance replication is not supported. For example, if your primary instance is in the South China (Guangzhou) region, you cannot create a replica that belongs to an overseas region.
The instance replication feature is not supported in the Taiwan (China) region.

Directions

Creating and managing a replica instance

1. Log in to the TCR console and choose Synchronization and Replication > Replication in the left sidebar.
2. On the Replication page, select a region and an instance, and click Create.
3. In the Create Replica Instance window, complete the following configurations:

Primary Instance Name: Name of the currently selected premium instance.
Default Region: Region where the currently selected premium instance is located.
Replicate to: Region where the replica instance is located, which cannot be the same as the region of the current primary instance.
4. Click OK.

Note:
You can delete the replication instances that are no longer needed in the specified region. If you have configured replica instances for a premium instance and you want to delete the premium instance, you need to delete all the replica instances first before deleting the premium instance.

Viewing image replication logs

After configuring a replica instance, if you push an image to the primary instance, the image data will be automatically replicated to the replica instance.


Accessing the replica instance via the private network

1. To ensure that the container clusters or CVMs in the replication region can access the replica instance through the private network, you need to connect the VPC in the replication region to the instance. Please refer to Configuring Private Network Access Control and choose the VPC in the replication region.
2. After the above configuration is completed, the container clusters or CVMs in the replication region can access the instance through the private network. The image access address and access credentials are the same as those of the premium instance in the original region.

References

You can also use the CreateReplicationInstance API to create a replica instance. For more information, see CreateReplicationInstance.

Cross-Tenant Synchronization

Last updated：2025-12-22 17:33:20

Overview

Tencent Container Registry (TCR) supports the synchronization of container images and Helm Charts among instances in different regions. It also supports single-instance image pushing and worldwide automatic image data synchronization and distribution, helping enterprises quickly deploy and update the container service in multiple regions worldwide.
The instance synchronization feature allows you to customize rules to synchronize specified resources in an instance to a specified location of another instance. In particular, you can select the synchronized resource type (container image, Helm Chart, or both), filter the synchronized resource paths, and use a regular expression to filter repositories and tags. You can also select whether to overwrite existing images with the same names to prevent the loss of historical data due to overwriting. Currently, the instance synchronization feature supports cross-tenant synchronization. You can create a synchronization rule by specifying the instance ID, account ID and access credential of the synchronization target.

Prerequisites

Before creating and managing the synchronization configuration of a TCR Enterprise instance, you need to complete the following tasks:
You have purchased a TCR Enterprise instance with standard or premium specification.
If you are using a sub-account, you must have granted the sub-account operation permissions for the corresponding instance. For more information, see Example of Authorization Solution of the Enterprise Edition.

Directions

Creating a synchronization rule

1. Log in to the TCR console and select Synchronization and Replication > Synchronization in the left sidebar.
2. On the Synchronization page, select a region and an instance, and click Create.
3. In the Create Instance Synchronization Rule window, configure the rule as instructed below.


Name: rule name, which is a string of lowercase letters, numbers, and special characters ([-._]) and must start with a letter or number.
Description: rule description.
Sync Source:
Source Instance: the current instance is the source instance. You can return to the "Synchronization" page to change the source instance.
Namespace: namespace with which the current instance needs to synchronize. Currently, you cannot select all namespaces.
Repository Name: the repository to be synchronized. If you do not enter the repository name, the system will select all repositories in the namespace by default.
Tag: the tag to be synchronized. If you do not enter the tag, the system will select all tags in the qualified repositories by default.
Repository Type: type of the resource to be synchronized. You can choose both Container Image and Helm Chart, or only one of them.
Synchronization Target: you can specify whether to enable cross-tenant synchronization.
Disabled
If Cross-tenant sync is disabled, the synchronization is between instances under the same tenant. You need to complete the following fields.
Target Instance: target instance for data synchronization. You can select any instance in the root account.
Namespace: namespace where the repository is located after it is synchronized to the target instance. If this parameter is not specified, it is set to the namespace with the same name as that in the source instance by default. If such a namespace does not exist, a namespace is created.
Enabled
If Cross-tenant sync is enabled, you can sync between instances under different tenants. The following fields are required.
Target Instance: ID of the target instance for data synchronization. You can go to Instance Management to obtain it.
Namespace: namespace where the repository is located after it is synchronized to the target instance. If this parameter is not specified, it is set to the namespace with the same name as that in the source instance by default. If such a namespace does not exist, a namespace is created.
Username: The username used to log in to the target instance of synchronization.
Note:
The username can only be a user-level account. Service-level accounts are not supported currently. If a service-level account is entered, it will be invalid, and an error will be reported.
Password: The password used to log in to the target instance of synchronization.
Note:
Use long-term access credentials to avoid the unavailability of synchronization rules. The lifecycle of synchronization rules is consistent with that of the access credentials for the synchronization rules newly added to the target account.
Image Override: this indicates whether the container image with the same name in the target instance is overwritten. We recommend that you do not overwrite images with the same name.
4. Click OK.
Note:
Supplement to the scenario of multi-level image repository synchronization:
To implement multi-level image repository synchronization, ensure that the namespaces of the source instance and target instance are consistent.
If the repository name is not entered by default to achieve multi-level image repository synchronization, pay special attention to the namespace field of the target instance, which should be left blank (default effect ns/**) to ensure that all sub-repositories can be correctly synchronized to the corresponding namespaces of the target instance.
Example: Assume that the source instance has a namespace project with multi-level sub-repositories such as project/subrepo1/subrepo2. To synchronize the sub-repositories in the target instance, leave the namespace field in the target instance blank.

Managing synchronization rules

After a synchronization rule is created, you can check it on the Synchronization page. Then, you can perform the operations shown in the figure below to manage synchronization rules.


View Synchronization Logs: click an instance rule to view triggering logs of the rule. For more information, see Viewing synchronization logs.
Modify Rule Status:

indicates that a rule is enabled, and

indicates that a rule is disabled. A newly created synchronization rule is enabled by default, and you can change the status as needed.
Trigger Synchronization: manually trigger synchronization. All repositories in the instance that match the rule are scanned and synchronized.
Note:
After rules are created, newly pushed images will be automatically synchronized to other instances with no need for manual triggering.
Manual triggering is mainly for certain historic images and exceptions. The operation of manually triggered synchronization involves scanning of all repositories in an instance that meet the rules. This takes time depending on the number of your image tags. During synchronization, task execution may cause pressure on other image transmission actions. Try to avoid manually triggering multiple synchronization rules at the same time.
Configuration: re-configure an instance synchronization rule. You can configure all parameters.
Deletion: delete the instance synchronization rule.

Viewing synchronization logs

Click the name of an instance synchronization rule to go to the "Synchronization Logs" page of this rule, as shown in the figure below.


Task ID: synchronization task ID, which is unique in the instance.
Creation Time: time when the synchronization task was created.
Time Spent: time consumed to complete all the synchronization tasks.
Success Rate: resource synchronization completion ratio. Multiple repositories may be synchronized concurrently in the same synchronization task.
Number of Synced Repositories: number of repositories that need to be synchronized in the current task.
Synchronization Status: task status. If a large number of container images and Helm Charts need to be synchronized in a task, the task may remain in the InProgress status for a long time.

References

You can also use the ManageReplication API to manage instance sync.

Loading Container Images on Demand

Last updated：2025-12-22 17:33:20

Overview

When using container images to deploy and update business applications, the traditional scheme is to download and decompress the full amount of container image data. On the one hand, it takes a long time to start the container. On the other hand, it may also cause large network and disk read and write pressure due to the large scale of the cluster and the download and decompression process, which leads to large-scale container startup, failing to meet deployment expectations. In fact, container startup may use only part of the data inside the container image. TCR Enterprise supports on-demand loading of container images. During business deployment, you can use converted accelerated image tags to download image data without full loading and decompress the data online, greatly improving application distribution efficiency for ultimate elastic experience. This document introduces how to load container images on demand.

Prerequisites

You have created a container cluster. Currently, the on-demand loading feature is available only for Tencent Cloud TKE clusters that meet the following requirements:
The cluster Kubernetes version is 1.16 or later.
The cluster runtime component is containerd of version 1.4.3 (other versions are not supported currently). For existing clusters, the runtime configuration can be changed to containerd 1.4.3, which applies to any node added after the change by default. If the runtime component of a cluster cannot be changed to containerd 1.4.3, the image acceleration feature cannot be used. The image cache of Tencent Kubernetes Engine (TKE) Serverless clusters can be used to accelerate image pulling when an instance is created. For details, see Image Cache.
Note:
If the containerd version of a cluster node is not 1.4.3, installing the acceleration suite application specified in this document may pose a fatal risk, causing related nodes to be NotReady and significant impacts on the data plane of services. The adaptation to later versions of containerd is in progress.
The runtime component version of a cluster can be viewed in the TKE console. Click the cluster name in the console and select Basic Info on the Basic Info page of the cluster to view the runtime component and its version information, as shown below.
The cluster OS is Ubuntu, TencentOS, or CentOS. If the cluster OS is CentOS, you need to run the yum install -y fuse command on the cluster nodes to install FUSE.
You have purchased a TCR Enterprise Edition instance with premium specification. The feature of loading container images on demand can be enabled only for a premium instance.
The VPC of the container cluster has been connected to the TCR Enterprise Edition instance, and the cluster nodes can access the images in the instance via the private network. For information about the configuration details, see Configuring Private Network Access Control.

Preparing accelerated images

Enabling image acceleration

1. Log in to the TCR console and click Image Acceleration in the left sidebar.
2. On the Image Acceleration page, select the region and name of the instance for which image acceleration is to be enabled, and you can view the status of the current instance image acceleration and the list of image acceleration rules.
3. Click Enable Image Acceleration. In the Activate Image Acceleration window that pops up, read the notes carefully.
Once image acceleration is enabled, a new OCI-compatible accelerated image is generated after you upload a container image that complies with the acceleration rules.
Note that after this feature is enabled and used, storing both general and accelerated images will incur additional image storage costs.
4. Click Conform.

Adding an image acceleration rule

1. Click Add Image Acceleration Rule. In the Create Image Acceleration Rule window that pops up, configure a rule as prompted.
Name: Rule name.
Description: Rule description.
Triggering Rule:
Triggered Instance: The currently selected instance is the triggered instance.
Namespace: Namespace whose distribution needs to be accelerated within the current instance. Currently, you cannot select all namespaces.
Repository Name: Accelerated repository. You can use a regular expression to filter repositories. If this parameter is not specified, all repositories in the namespace are selected by default.
Tag: Accelerated tag. You can use a regular expression to filter tags. If this parameter is not specified, all tags in the repositories that meet the requirements are selected by default.
Validate Rule: Enter the address of the image to be accelerated to check whether the image under the current triggering rule meets the acceleration rule.
2. Click OK.

Pushing the image and automatically converting it

Check the added image acceleration rule on the Image Acceleration page. If the rule is enabled, push the new container image to the image repository that meets the rule. This will automatically trigger the image format conversion, and an accelerated image with the -apparate suffix will be generated. The default image artifact type is Docker-Image. After the conversion, the image artifact type is OCI-Image-v1.

Deploying an Acceleration Image

Tencent Kubernetes Engine (TKE) is a Kubernetes managed service that works closely with TCR. You can install the TCR acceleration application in a TKE cluster and deploy an acceleration image to increase the business startup speed.

Configuring cluster nodes

Cluster nodes do not support acceleration images by default. To enable a cluster node to use an acceleration image with priority, add the image acceleration label to the cluster node via the CLI or TKE console.
Adding the Image Acceleration Label via the CLI
Run the following command to add the image acceleration label to a cluster node:
kubectl label node xxx cloud.tencent.com/apparate=true
Adding the Image Acceleration Label via the TKE Console
1. Log in to the TKE console and select Cluster in the left sidebar.
2. On the Cluster page, click the cluster ID that requires the accelerated image distribution feature and go to the Basic Info page of the cluster.
3. In the left sidebar, select Node Management, and view the node list in the Node tab.
4. In the row where label needs to be configured for a node, select More > Edit Label.
5. In Edit Label, set the label to cloud.tencent.com/apparate=true.
6. Click OK.

Installing the acceleration application

A cluster does not support the use of acceleration images by default, so you need to install the TCR acceleration suite application on the cluster. After the TCR acceleration suite application is installed, the nodes that have been labeled as supporting the deployment of acceleration images will automatically deploy the DaemonSet process and can load the acceleration images normally. After the TCR acceleration suite application is installed, if you add a node and label it cloud.tencent.com/apparate=true, the node will also automatically deploy the DaemonSet process and can load acceleration images normally.

Installing the TCR acceleration suite application via the CLI

1. Install the Helm V3 CLI. For more information, see Using the Helm client to upload and download Helm Charts.
2. Add the Helm repository and pull the TCR acceleration application Chart package.
helm repo add tcr-helm-public https://helmhub.tencentcloudcr.com/chartrepo/public
helm pull tcr-helm-public/apparate --version 1.0.0
3. Decompress the downloaded Chart package and modify values.yaml.
tar -xzvf apparate-1.0.0.tgz  
vim apparate/values.yaml
Configure the following parameters:
3.1 imagePullSecretsCrs: This configuration is used for pulling acceleration images. You need to set dockerUsername, dockerPassword, and dockerServer to specify the TCR Enterprise Edition instance username, password, and access domain respectively.
3.2 image: Retain the default value. This configuration is used for pulling basic images during application installation on a cluster. If the cluster is not deployed in the Chinese mainland, change the value to the access domain name of the TCR Individual image repository in the corresponding region.
4. Build the Chart package again and install it to the specified cluster.
Note:
If the containerd version of a cluster node is not 1.4.3, installing the acceleration suite application specified in this document may pose a fatal risk, causing related nodes to be NotReady and significant impacts on the data plane of services. The adaptation to later versions of containerd is in progress.
helm package apparate/
helm install apparate apparate-1.0.0.tgz
Before running the helm install command, you need to configure the cluster access credentials locally in advance. For more information, see Connecting to a Cluster Using the Local Helm Client.
5. Go to the cluster application page and confirm the application's installation status and configuration.

Deploying an acceleration image

When creating a workload, select an image within the current instance. Only when the following conditions are met, the cluster loads the image on demand to quickly start the container:
The container image specified for the workload is a converted acceleration image, such as nginx:latest-apparate, and its artifact type is OCI-Image-v1.
The image acceleration label cloud.tencent.com/apparate=true is added to the node to which the workload Pod is scheduled.
Therefore, when creating a workload, select an accelerated image tag, add nodeSelector, and set cloud.tencent.com/apparate=true so that the workload will be scheduled to a node that supports accelerated images to implement accelerated startup.

FAQs

Can I delete regular and accelerated images?

Yes. When both regular and accelerated images exist in the repository, deleting one will not affect the pull and deployment of the other.

What should I do if no accelerated image is generated automatically after image push?

Check if the image matches the existing acceleration rules. If you are sure that the image meets the acceleration rules in the enabled state, you can submit a ticket for help.

Image Security

Container Image Security Scanning

Last updated：2025-12-22 17:33:20

Overview

The Tencent Container Registry (TCR) Enterprise Edition supports security scanning of managed container images and can generate scanning reports, expose potential security vulnerabilities in container images, and provide suggestions for fixing them. Container image security is an important part of cloud native application delivery security. Timely security scanning of uploaded container images and blocking application deployment based on the scanning results can effectively reduce the risk of vulnerabilities in the production environment.
The image security scanning feature is a built-in feature of image repositories. You can actively trigger the security scanning of the container image of the specified version after uploading the container image. Also, you can configure automatic scanning at the namespace level, so that newly pushed images in the namespace will be scanned automatically after upload. The current image security scanning service is based on the open-source Clair solution, and the relevant vulnerability information is from the official CVE vulnerability library and synchronized on a regular basis.

Prerequisites

Make sure that the following conditions are met before using the image security scanning feature,:
You have purchased a TCR Enterprise Edition instance.
If you are using a sub-account, the sub-account must have obtained operation permissions on the corresponding instance. For more information, see TCR Enterprise Authorization Management.

Directions

Configuring the scanning policy

1. Log in to the TCR console and click Namespace in the left sidebar.
2. On the Namespace page, click the name of the instance for which you want to enable the image security scanning feature to go to the namespace details page.
3. On the details page, select Auto-scan for security scanning, as shown in the figure below:


Manually triggering scanning

Step 1: Prepare a container image

Refer to Basic Image Repository Operations to upload a container image and view the image on the version management page of the corresponding image repository.

Step 2: Trigger image scanning

Select a specific image version in the image repository and click Scan to trigger image scanning. At this time, the security level is displayed as Scanning, as shown in the figure below:


Step 3: View the scanning results

After the security scanning is complete, the highest level and the number of vulnerabilities in the current image are displayed in the security level section. You can view the vulnerability details, as shown in the figure below:

When viewing the details of vulnerabilities, you can click a specific vulnerability ID to redirect to the details of the vulnerability so that you can assess its actual impact on business, as shown in the figure below:


Step 4: Re-trigger scanning

As the vulnerability library is updated regularly, you can refer to Step 2: Trigger image scanning to re-trigger the security scanning of the specified image and obtain the latest scanning results.

Configuring Image Tag Immutability

Last updated：2025-12-22 17:33:21

Overview

Tencent Container Registry (TCR) Enterprise Edition supports protection for the hosted container image tags. Container image security is a key part of cloud-native application delivery. It enables tag immutability feature for the images hosted in TCR, which ensures the images of the same tag will only be successfully pushed once, thus effectively reduce the risk of tag overwriting caused by misoperation in the production environment. TCR supports tag protection at the namespace level. Users can fine-grainily define the repositories and image tags covered by the feature according to service demands.

Directions

Creating tag immutability rule

1. Log in to the TCR console and select Tag Management > Tag Immutability on the left sidebar.
2. Select the region where the instance is located and the instance name on the “Tag Immutability” page.
3. Click Create Rule. In the Create Tag Immutability Rule window, configure the rule based on the following information. See the figure below:


Configuration Item
Description
Associated instance
The instance which has been selected currently.
Namespaces
The current instance needs to enable the namespace for tag protection. Only a rule can be created in a single namespace.
Immutability rule
latest: in all repositories in the current namespace, all image tags are not allowed to be overwritten except the latest tag.
Custom: customize the configuration of the repository and image tag that need to be matched.
Repository matching: select filter type for the image repository, and enter the name of the repository which needs to be filtered.
Tag matching: select filter type for the image tag, and enter the name of the tag which needs to be filtered.
Rule switch
The rule is effective as of creation by default.
Enabling means the rule takes effect. You can enable/disable the rule in the configuration.
4. Click Confirm to create the rule.

Managing tag immutability rule

You can view the rules on the “Tag Immutability” page after creation, and take the following actions to manage the rules.
Configuration: you can reconfigure the instance tag immutability rule but cannot modify the namespace for which it takes effect.
Delete: delete the tag immutability rule under the instance.

Blocking the Deployment of High-Risk Images

Last updated：2025-12-22 17:33:20

Overview

The Tencent Container Registry (TCR) Enterprise supports security scanning of managed container images and can generate scanning reports, expose potential security vulnerabilities in container images, and provide suggestions for fixing them. Container image security is an important part of cloud native application delivery security. Timely security scanning of uploaded container images and blocking application deployment based on the scanning results can effectively reduce the risk of vulnerabilities in the production environment.
The image deployment blocking feature is configured at the namespace level. You can enable it, and configure the blocking policy and the ignorable image vulnerabilities. Then, if a container client is trying to pull images that meet the blocking policy, the pulling will be denied and error reports will be returned.

Prerequisites

Before using the image deployment blocking feature, you need to perform the following operations:
Create a TCR Enterprise Instance.
If you are using a sub-account, you must have granted the sub-account operation permissions for the corresponding instance. For more information, see Example of Authorization Solution of TCR Enterprise.

Directions

Configuring the blocking policy

1. Log in to the TCR console and select Namespace in the left sidebar.
2. On the "Namespace" page, click the name of the instance for which you want to configure the blocking policy to go to the namespace details page.
3. On the "Deployment security" page, enable the blocking and configure the vulnerability level to be blocked.

Configure the allowlist of vulnerabilities

After enabling the blocking, you can configure the allowlist of vulnerabilities. Enter one or more CVE IDs and separate them with commas. Then, if the image ID is contained in the security scanning result, it will be ignored by the blocking policy. That means, if there is a high-risk vulnerability in the image, and the vulnerability is configured in the allowlist, the image can be pulled normally even if it is configured to block the pulling of images with high-risk vulnerabilities.

Container Image Signature

Last updated：2025-12-22 17:33:21

Image signing and signature verification can avoid man-in-the-middle attacks and the update and running of invalid images, ensuring image consistency across the entire linkage ranging from distribution to deployment. TCR Enterprise supports namespace-level automatic image signing. When an image is pushed to the repository, it will be automatically signed according to the matched signing policy to ensure image content trustworthiness in your repository.

Prerequisites

Before using the image signing feature, you need to perform the following operations:
Create a TCR Enterprise Instance.
If you are using a sub-account, you must have granted the sub-account operation permissions for the corresponding instance. For more information, see Example of Authorization Solution of TCR Enterprise.
Key Management Service (KMS) has been activated.

Directions

Creating an asymmetric signature verification key

1. Log in to the KMS console.
2. Choose Key Management > Customer Managed CMK and click Create.
3. In the Create Key window that pops up, set key parameters and click OK. The container signature feature requires that the KMS key usage be set to Asymmetric Signature Verification and the encryption algorithm be set to RSA_2048. For the settings of the other parameters, see Creating a Key.
Note: TCR supports obtaining user keys in all regions of the KMS service. To reduce the cross-region communication overhead, it is recommended that the KMS user key and the image repository instance be located in the same region.

Authorizing TCR to use the KMS key

To enable TCR to read the asymmetric signature verification key under your account, you need to configure a policy as follows under your account:
1. Log in to the CAM console.
2. On the Role page, click TCR_QCSRole.
3. On the TCR_QCSRole details page, associate the preset policy QcloudKMSFullAccess.



Creating an image signing policy

1. Log in to the TCR console.
2. On the instance management page, select a target image repository instance.
3. Select Image Security in the left sidebar to go to the image signing details page.
4. Click Create. In the signing policy creation window that pops up, set parameters as instructed.
Policy Name: Image signing policy name. The value must be 2 to 50 characters in length and can contain only lowercase letters, numbers, and separators, including periods (.), underscores (_), hyphens (-), and slashes (/). It can neither start or end with a separator nor contain consecutive separators.
Namespace: Namespace where the image signing policy takes effect. Only one signing policy is supported per namespace.
KMS Key: KMS customer managed CMK that supports signing. Only a key that is used for RSA2048 asymmetric key verification can be loaded.
Domain Name: Domain name used to access the repository instance service.
5. Click OK.
Note:
Once created, the signing policy takes effect for new images immediately. That is, when an image is pushed to the repository, it will be automatically signed according to the matched signing policy.
An enabled signing policy does not take effect for images that already exist in the repository. For existing images, you need to manually trigger signing on the Image Repository > Tag Management page in the console.

Viewing image signing status

You can check whether the signing policy is enabled on the Namespace page.
You can check whether the signing policy is enabled for images on the Image Repository > Tag Management page. For images that have been pushed to the image repository before the signing policy is enabled, you can manually trigger signing in the Operation column.

Deleting an image signing policy

On the Image Signature page, select the signing policy to delete and click Delete. In the window that pops up, click OK.
Note: Deleting the signing policy will also delete the image signing information in the existing namespace, which may cause signature verification failure.

Image Cleanup

Auto-Deleting Image Tags

Last updated：2025-12-22 17:33:21

Overview

Tencent Container Registry (TCR) supports the hosting and distribution of container images and provides the image building feature to enable image building, push, and hosting to be automatically triggered by code changes. If customers need to quickly iterate their applications, they can adopt an automated pipeline to generate images. Large number of image tags will be generated continuously, and the old image tags will no longer be used. If a single image repository contains too many image tags, the burden of tag management is huge, and the quota of image tags in the repository will be used up. Therefore, TCR provides the image tag retention feature to allow users to create custom rules for tag retention. Such rules can be triggered periodically to automatically delete the image tags that fall outside the retention scope.
Tag retention rules support two types of retention policies: retaining the latest # tags pushed and retaining the tags pushed within # days, and simulated execution is supported.

Must-Knows

1. The version retention feature can be used to delete image versions not covered by the retention rules.
2. The version retention feature deletes only the image version information and retains the underlying image data. To completely clean up image data, use Cloud Object Storage (COS) cleanup.

Directions

Creating tag retention rules

Note:
An image repository may contain multiple versions of an image that are exactly the same. For example, an image has different tags, but a new image layer is not generated. The image with different tags has the same and unique identifier Digest. Therefore, the image with different tags but the same Digest physically points to the same image content. When a tag is deleted, the image will be deleted, and the related tags and Digest will also be cleaned up.
The impact on Tencent Container Registry (TCR) version retention rules is as follows: If a repository contains images with different tags but the same Digest, and the two latest images are required to be retained, deleting one tag will cause all images in the repository to be deleted. Therefore, if your image repository contains images with the same Digest but different tags, use the version retention rules with caution or temporarily disable the existing rules.
1. Log in to the TCR console and select Tag Retention in the left sidebar.
2. On the Tag Retention page, view the tag retention rule list of the current instance. To switch to another instance, select the target instance from the Instance Name drop-down list at the top of the page.
3. Click Create Rule, and in the Create Tag Retention Rules window, configure the rules by seeing the prompts as shown below. There are two optional configuration modes:
Basic Configuration

Associated Instance: currently selected instance.
Namespace: The namespace where the version retention rule takes effect. Currently, only one rule can be created in a namespace.
Configuration mode: Basic configuration.
Retained tags: No tags are filtered out, that is, all repositories and tags in a namespace are retained by default.
Retention rule: Two modes are supported: Retain the most recently pushed # tags, or Retain tags pushed within the last # days. The number of tags or days needs to be specified.
Execution cycle: Execution cycle of the version retention rules. The tag retention rules can be manually executed or automatically executed on a daily, weekly, or monthly basis. The specific execution time is as follows: 00:00 on each day, 00:00 on each Monday, or 00:00 on the first day of each month.
Enabling rules: The rules are enabled by default.
Advanced Configuration

Associated Instance: currently selected instance.
Namespace: The namespace where the version retention rule takes effect. Currently, only one rule can be created in a namespace.
Configuration mode: advanced configuration.
Retention rules: Multiple retention rules can be configured, and their union set is applied, that is, an image version meeting any of the retention rules will be retained.
Repository filtering: Certain repositories are matched or excluded. Regular expressions are used for filtering repository names. An asterisk (*) and double asterisks (**) can match any long string, while an asterisk (*) cannot match a multi-level repository name. A question mark (?) can match any single character other than the slash (/).
Version filtering: Certain versions in a repository are matched or excluded. Regular expressions are used for filtering version names. The filtering rules are the same as those for repository filtering.
Retention rule: Two modes are supported: Retain the most recently pushed # tags, or Retain tags pushed within the last # days. The number of tags or days needs to be specified.
Execution period: Execution cycle of the tag retention rules. The tag retention rules can be manually executed or automatically executed on a daily, weekly, or monthly basis.
Enabling rules: The rules are enabled by default.
4. Click Confirm to create a tag retention rule.

Managing tag retention rules

After successfully creating tag retention rules, you can view the created tag retention rules on the Tag Retention page. You can also perform the following operations to manage the rules. See the figure below:

View the rule execution logs: You can click the name of a rule to view its triggering logs. For more information, see Viewing execution logs.
Configure: You can reconfigure a tag retention rule but cannot modify the namespace for which it takes effect.
Delete: You can delete a tag retention rule.

Viewing execution logs

1. Click the name of the target tag retention rule to view the triggering logs of the rule, as shown in the figure below:

Task ID: ID of a tag retention task, unique within the instance.
Creation Time: Time when a tag retention task was created.
Time Spent: Time consumed to complete all the tag retention tasks.
Execution Method: Manual or automatic. You can click Execute Now or Simulate Execution for manual execution. Automatic execution is based on the cycle specified in the tag retention rule.
Execution Type: Real execution or simulate execution. Simulate execution can be used to confirm whether the rule is effective, but it does not actually clear image tags.
Execution Status: Status of task completion.
2. You can click a task ID to view the task details and click a specific repository to view its execution log.

References

You can also use the CreateTagRetentionRule API to create tag retention rules. For more information, see CreateTagRetentionRule.

Releasing COS Storage Capacity

Last updated：2025-12-22 17:33:21

Overview

TCR allows users to set up rules to remove unused image tags of the Enterprise Edition instances in batch. However, after you delete the image tags, the image data stored in the COS bucket associated with the instance still exists. You can use the garbage collection feature to delete the invalid image tag data in COS bucket to release the occupied storage capacity, and reduce the storage costs. This document describes how to use the garbage collection feature to release the occupied storage capacity of a COS bucket.

Notes

Garbage collection will affect the instance service status and the data in your instance. Please note the following points:
During garbage collection, the instance becomes read-only. You can pull images from image repositories, but cannot push images to the image repositories.
The garbage collection task will clean up the image layer data that is no longer associated with valid image tags in all image repositories of the instance. The deletion operation is irreversible. We recommend that you perform a dry run to evaluate the impacts before performing garbage collection.
The time required for the garbage collection task depends on the image data size stored in the COS bucket and the number of historical image tags. Temporary suspension of tasks is not supported. We recommend that you perform the garbage collection tasks during non-business time, or perform a dry run to estimate the required time.
Note:
Important notes on storage types:
DEEP_ARCHIVE disabled: For the Cloud Object Storage (COS) bucket associated with an instance, DEEP_ARCHIVE cannot be enabled. Otherwise, image pulling will fail. The DEEP_ARCHIVE objects need to be manually retrieved. This takes a long time, during which images are unavailable.
Impact of STANDARD_IA: When STANDARD_IA is used, data retrieval fees are incurred by pulling images for the first time (see COS Pricing).

Directions

Performing a dry run

1. Log in to the TCR console and click Garbage Collection in the left sidebar.
2. On the Garbage Collection page, view the garbage collection tasks of the current instance. To change the instance, select the required instance name from the Instance Name drop-down list at the top of the page.
3. Click Dry run and read the notes carefully.
Note:
In a dry run, the instance is fully scanned for unused data. You can estimate the cleanup range and the required time. During the dry run, the instance's basic features are not affected. You can still pull and push images. However, the intensive computing tasks of the cleanup may affect the speed of image pulling and push.
4. Click OK.

Running garbage collection

1. Log in to the TCR console and click Garbage Collection in the left sidebar.
2. On the Garbage Collection page, view the garbage collection tasks of the current instance. To change the instance, select the required instance name from the Instance Name drop-down list at the top of the page.
3. Click Run Garbage Collection and read the notes carefully.
Note:
During garbage collection, the instance becomes read-only. You can pull images from image repositories, but cannot push images to the image repositories. The time required for the job depends on the data size and usage duration of the instance.
4. Click OK.

DevOps

Managing Triggers

Last updated：2025-12-22 17:33:21

Overview

Tencent Container Registry (TCR) allows users to configure and use the flexible trigger (Webhook) feature. By configuring a proper trigger in an instance, you can quickly integrate existing R&D processes and CI/CD platforms and realize container DevOps scenarios such as image updates automatically triggering application deployment.
The trigger feature allows users to create custom trigger rules and view triggering logs. Trigger actions support the push, pull, and deletion of container images and Helm charts. Triggering rules support flexible regular expression filtering and regular filtering based on specified namespaces in an instance and configured image repositories and tags. This allows the trigger to be triggered by only certain repositories or image tags that use special naming formats. The custom Header feature allows users to configure the Header for accessing the target URL in the Key:Value format, which is applicable to authentication and other scenarios.

Prerequisites

Before creating and managing a trigger in a TCR Enterprise Edition instance, complete the following tasks:
Purchase a TCR Enterprise Edition instance. The trigger feature is supported only in TCR Enterprise Edition.
If you are using a sub-account, you must have granted the sub-account operation permissions for the corresponding instance. For more information, see Example of Authorization Solution of TCR Enterprise.

Directions

Creating a trigger

1. Log in to the TCR console and click Trigger in the left sidebar. On the Trigger page, you can view the list of trigger rules for the current instance. To change the instance, select the desired instance name from the Instance Name drop-down list at the top of the page.
2. Click Create. In the Create Trigger pop-up window, specify the parameters and the trigger rule. You can use the following figure for reference:

Name: Instance name. The name can contain lowercase letters, digits, hyphens (-), periods (.), and underscores (_), and must start with a letter or digit. In this document, webhook-demo is used as an example.
Description: Rule description.
Action: Four trigger actions are supported: push images, delete images, upload Helm charts, and delete Helm charts. During the execution of the webhook, the initiated webhook request contains information about the trigger action.
Triggering Rule:
Triggered Instance: The instance to which the webhook belongs, which is the currently selected instance and cannot be changed.
Namespace: The namespace for which the webhook takes effect. If the list is empty, create a namespace in the instance.
Repository Name: The name of the repository for which the webhook takes effect. Regular matching of image repositories and Helm charts is supported.
Tag: The tag for which the webhook takes effect. It supports regular matching. If you want the webhook to take effect for all tags, leave this parameter empty.
URL: The target URL for request initiation after the trigger fires, which is the URL that you specified for the webhook server. The trigger will send a POST request to the URL, and the request body contains the trigger action, trigger rule, and other information.
Header: The Header information in the Key:Value format to be carried in a POST request initiated by the trigger. Example: Authentication: xxxxxxx.
3. Click OK.

Managing trigger rules

After a trigger rule is created, you can view the trigger rule on the Trigger page and perform the following operations to manage the trigger rule:



View Trigger Logs: You can click the name of the trigger rule or click Trigger Logs on the right side of the trigger rule to view the trigger logs of the rule. For more information, see Viewing trigger logs.
Modify Rule Status:

indicates that the rule is enabled, and

indicates that the rule is disabled. By default, a synchronization rule is enabled after it is created. You can change the status as needed.
Configuration: You can re-configure all parameters of the trigger rule.
Delete: You can delete the trigger rule.

Viewing trigger logs

You can click the name of a trigger rule or click Trigger Logs on the right side of the trigger rule to view the trigger logs of the rule. See the figure below:



A log contains the following information:
Task ID: Trigger task ID, which is unique in the instance.
Action: The action that launched the trigger, such as image push.
Triggered Repository: The repository resources that launched the trigger.
Status: Success status of the trigger in executing the webhook request.
Creation Time: The time when the trigger was launched, which is also the time when the webhook request was initiated.

More Information

Webhook request format for reference

When users perform a relevant action on resources that meet a trigger rule, for example, pushing new images to the specified image repository, the relevant trigger is triggered and sends an HTTP POST request to the URL configured in the rule. The request body contains information such as the trigger action and repository path. The following is the resolved information of a sample request body after the trigger is triggered by image pushing. This sample is for reference in webhook server development.
{
  "type": "pushImage",
  "occur_at": 1589106605,
  "event_data": {
    "resources": [
      {
        "digest": "sha256:89a42c3ba15f09a3fbe39856bddacdf9e94cd03df7403cad4fc105xxxx268fc9",
        "tag": "v1.10.0",
        "resource_url": "xxx-bj.tencentcloudcr.com/public/nginx:v1.10.0"
      }
    ],
    "repository": {
      "date_created": 1587119137,
      "name": "nginx",
      "namespace": "public",
      "repo_full_name": "public/nginx",
      "repo_type": "public"
    }
  },
  "operator": "332133xxxx"
}

Using regular expressions to create rules

Regular matching rules

The following are the matching rules supported by the regular expression when you enter “repository name” or “version tag”:
*: matches all strings of any length that do not contain the path separator (/).
**: matches all strings of any length that contain the path separator (/).
Note:
** must be used as a complete relative path. If you use /path**, it will be the same as /path* and will only match the first-level repositories whose names are prefixed with path. To match all repositories under path, you should use /path/**. To match all repositories whose names are prefixed with path, you should use /path*/**.
?: matches any single character except ‘/’.
{alt1, alt2, …}: matches multiple regular expressions at the same time.

Use cases

Matches all repositories in the specified namespace
** or leave it empty
Matches all first-level repositories whose names are prefixed with path in the specified namespace
/path*
Matches all first-level repositories whose names are prefixed with path1 and path2 in the specified namespace
/{path1, path2}*
Matches all repositories under the path1 and path2 directories in the specified namespace
/{path1, path2}/**
Matches all repositories whose names are prefixed with path1 and path2 in the specified namespace
/{path1, path2}*/**
Matches all 1.x version tags in the specified repositories
1.?
Matches all version tags whose names are prefixed with env1 and env2 in the specified repository
{env1*, env2*}


OCI Artifacts Management

OCI Artifacts Management Overview

Last updated：2025-12-22 17:33:21

Overview

Tencent Container Registry (TCR) is compatible with OCI standard and supports hosting of multiple cloud-native artifacts including Docker Image, meeting the requirements of advanced users for hosting and distribution of Helm Chart, CNAB and custom OCI artifacts.
Currently, TCR Enterprise and TCR Individual instances support hosting of OCI artifacts. You can push OCI artifacts to image repositories, check the artifact type and pull commands.
For more about OCI artifacts and the usage, please see the official project opencontainers/artifacts on the GitHub.

Prerequisites

You must complete the following preparations before you can upload and manage OCI artifacts in the TCR instances.
Create a TCR Enterprise instance or initialize the TCR Individual.
If you are using a sub-account, you must have granted the sub-account required permissions for the instance. For more information, see Example of Authorization Solution of the TCR Enterprise.

Directions

Managing OCI artifacts in the console

1. Log in to the TCR console and select Image Repository in the left sidebar.
2. On the page that appears, you can view the list of image repositories in the current instance. It supports hosting of OCI artifacts by default. You can build OCI artifacts using the specific client tools and push the artifacts to the image repository.
3. Click the name of the desired image repository to go to the details page, where you can view the existing artifacts in the image repository.

References

Helm Charts Management

If you want to use Helm Charts, you can push them as OCI artifacts to the image repository for unified management. The Helm V3 tools are required if you choose this management method. Also, you can use the Helm Chart hosting feature provided by TCR Enterprise instances based on the Chart Museum open source project. For more information, see Helm Chart Hosting.

Management Helm Chart

Last updated：2025-12-22 17:33:21

Overview

Tencent Container Registry (TCR) can host Helm Charts to meet requirements for hosting and distribution of cloud-native applications. You can manage both container images and Helm Charts in the same namespace so that cloud-native deliverables of both container images and Helm Charts can be used in a business project.
Currently, only TCR Enterprise Edition instances support Helm Chart hosting and the use of the console or a Helm client to upload and download Helm Charts. Helm Chart repositories inherit the public or private attribute from their namespaces, and no extra configuration is needed. In terms of permission management, Helm Charts and container images share the repository resource type. This means the resource description qcs::tcr:$region:$account:repository/tcr-xxxxxx/project-a/* contains all image repositories and Helm Charts in the project-a namespace. You can flexibly use these image repositories and Helm Charts during resource permission management.

Prerequisites

Make sure that the following conditions are met before uploading and managing Helm Charts in a TCR Enterprise Edition instance:
You have purchased a TCR Enterprise Edition instance.
If you are using a sub-account, the sub-account must have obtained operation permissions on the corresponding instance. For more information, see TCR Enterprise Authorization Management.

Directions

Managing Helm Charts in the console

1. Log in to the TCR console and click Helm Chart in the left sidebar.
2. On the Helm Chart page, view the list of Helm Charts in the current instance. To change the instance, select the required instance name from the Instance Name drop-down list at the top of the page, as shown in the figure below:

The Chart list contains the following information and supported operations:
Name: Helm Chart name. You can click it to enter the Chart details page, where you can view and manage each version of the Chart. You can also view the file details of each version of the Chart package on the Basic Information tab.
Namespace: Namespace to which a Helm Chart belongs.
Create Time: Time when the Helm Chart was pushed to the repository for the first time.
Operation: Click Use commands to obtain the commands for the current repository. For more information, see Using the Helm client to upload and download Helm Charts. Click Delete to delete the current repository.
3. Click the name of the specified Helm Chart repository to enter the repository details page.
Version Management: This page displays the existing Chart versions in the current repository, and you can download or delete the specified versions, as shown in the figure below:

Basic Information: This page displays the Chart version details, such as Chart.yaml, as shown in the figure below:


Using the console to upload and download Helm Charts

Uploading a local Helm Chart package

1. Log in to the TCR console and click Helm Chart in the left sidebar. On the Helm Chart page, you can view the list of Helm Chart repositories in the current instance. To change the instance, select the required instance name from the Instance Name drop-down list at the top of the page.
2. Click Upload. In the Upload Helm Chart pop-up window, configure settings as shown in the figure below:


Associated Instance: Current instance selected.
Namespace: Namespace to which the Helm Chart repository belongs. If the list is empty, create a namespace in the instance.
Chart Package: Click to select a Helm Chart package that has been downloaded to the local system.
Note:
Only Helm Chart packages in .tgz format are supported. Please avoid uploading other types of files. Note that uploading a file will overwrite the existing Chart with the same name.
3. Click Upload to start uploading the Helm Chart package. After uploading, you can view the uploaded Helm Chart on the repository list page. If the uploaded package does not have a corresponding Helm Chart repository, a new repository will be created automatically.

Downloading a Helm Chart package to the local system

1. View the Helm Chart repository list in the current instance on the Helm Chart page. Click the specified repository to enter its version management page.
2. Select the specified version in the Chart repository, click Download on the right of the row where the version is located, and the Chart package on this version will be automatically downloaded to the local system. Depending on the browser and configuration, you can choose to specify the download path.

Using the Helm client to upload and download Helm Charts

Installing a Helm client

Note:
Note that, if you wish to use Helm in Tencent Kubernetes Engine (TKE), you need to select a v3.x.x version. You can run the helm version -c command to check the version of the installed client.
This document takes the installation on a Linux node as an example. For installation on other operating systems, download the corresponding installation package.
Run the following commands in sequence to download and install the Helm client. For more information, see Installing Helm.
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

Adding a Helm repository

1. Log in to the TCR console and go to the Instance list page. On this page, click the name of the target instance to go to the details page.
2. 
Obtain the username and password used
to log in to the instance. For more information, see Obtaining an Instance Access Credential.
3. Run the following command on the node to add the namespace, which is used to manage Helm Charts, to the local Helm repository.
Note:
Ensure that the server running this command is in the Internet allowlist or connected VPC of the corresponding instance. For more information, see Configuring Public Network Access Control and Configuring Private Network Access Control.
helm repo add $instance-$namespace https://$instance.tencentcloudcr.com/chartrepo/$namespace --username $username --password $instance-token
$instance-$namespace: Name of the Helm repository. We recommend that you use the combination of instance name + namespace name for naming so as to distinguish between instances and namespaces.
https://$instance.tencentcloudcr.com/chartrepo/$namespace: Remote address of the Helm repository.
$username: Username obtained in Step 2.
$instance-token: Password obtained in Step 2. If the add operation is successful, the following message will be prompted.
"$instance-$namespace" has been added to your repositories

Pushing Helm Charts

1. Install the helm-push plugin.
Note:
Install the helm-push plugin of the v0.10.0 or a later version. Otherwise, version incompatibility may cause Helm Chart package pushing to fail.
If the version of the helm-push plugin you use is earlier than v0.10.0, replace helm cm-push with the helm push command.
To upload Chart packages by using the Helm CLI, you need to install the helm-push plugin. The plugin supports using the helm push command to push Helm Charts to the specified repository, as well as uploading directories and compressed packages.
helm plugin install https://github.com/chartmuseum/helm-push
2. Run the following command on the node to create a Chart:
helm create tcr-chart-demo
3. (Optional) Run the following command to directly push the specified directory to the Chart repository:
helm cm-push tcr-chart-demo $instance-$namespace
Here, $instance-$namespace is the name of the added local repository.
4. Run the following commands to compress the specified directory and push it to the Chart repository:
tar zcvf tcr-chart-demo-1.0.0.tgz tcr-chart-demo/
helm cm-push tcr-chart-demo-1.0.0.tgz $instance-$namespace
Here, $instance-$namespace is the name of the added local repository.

Pulling Helm Charts

1. Run the following command on the node to obtain the latest Chart information:
helm repo update
2. Run the following command to pull the Helm Chart of the specified version:
helm fetch <Local repository name>/<Chart name> --version <Chart version>
In the following example, tcr-chart-demo 1.0.0 in the project-a namespace is pulled from the tcr-demo TCR Enterprise Edition instance:
helm fetch tcr-demo-project-a/tcr-chart-demo --version 1.0.0


Operation Guide for TCR Individual

Resetting the Login Password

Last updated：2025-12-22 17:33:21

Overview

This document describes how to reset the login password for a TCR Individual instance.

Notes

The login password for a TCR Individual instance is a fixed password, which is consistently applied among all regions.

Directions

1. Log in to the TCR console and select Instance Management in the left sidebar. On the page that appears, you can view the list of instances under the current account. Select a TCR Individual instance in any region.

2. Click More > Reset the login password, as shown in the following figure.

Username: The current Tencent Cloud account ID.
New password: The new password you want to use. It is recommended that you configure a strong password.
Confirm password: Enter the password again.
3. Click Confirm to complete the process.

Configuring Access Permission

CAM APIs for Personal Edition

Last updated：2025-12-22 17:33:21

Namespace APIs

APIs and Description
ResourceType
Six-segment Example of Resource
CreateNamespacePersonalCreating a namespace of Personal Edition
repo
qcs::tcr:$region:$account:repo/$namespace
DeleteNamespacePersonalDeleting a namespace of Personal Edition
repo
qcs::tcr:$region:$account:repo/$namespace


Image Repository APIs

APIs and Description
ResourceType
Six-segment Example of Resource
DescribeRepositoryOwnerPersonalQuerying all repositories of Personal Edition
repo
qcs::tcr:$region:$account:repo/*
CreateRepositoryPersonalCreating an image repository of Personal Edition
repo
qcs::tcr:$region:$account:repo/$namespace/$repo
DeleteRepositoryPersonalDeleting an image repository of Personal Edition
repo
qcs::tcr:$region:$account:repo/$namespace/$repo
BatchDeleteRepositoryPersonalDeleting the image repositories of Personal Edition in batches
repo
qcs::tcr:$region:$account:repo/$namespace/*
DeleteImagePersonalDeleting the repository tag of Personal Edition
repo
qcs::tcr:$region:$account:repo/$namespace/$repo
BatchDeleteImagePersonalDeleting the repository tags of Personal Edition in batches
repo
qcs::tcr:$region:$account:repo/$namespace/$repo
PullRepositoryPersonalPulling the images in the image repository of Personal Edition
repo
qcs::tcr:$region:$account:repo/$namespace/$repo
PushRepositoryPersonalPushing the images in the image repository of Personal Edition
repo
qcs::tcr:$region:$account:repo/$namespace/$repo


Example of Authorization Solution of TCR Individual

Last updated：2025-12-22 17:33:21

Policy Configuration in Typical Scenarios

Note:
The following scenario policies are only used for TCR Individual use cases.
Grant a sub-account the full read/write permissions for all resources in TCR Individual.
{
  "version": "2.0",
  "statement": [{
      "action": [
          "tcr:*"
      ],
      "resource": [
          "qcs::tcr:::repo/*"
      ],
      "effect": "allow"
  }]
}
Grant a sub-account the read-only permission for all resources in TCR Individual (former Image Repositories in TKE).
{
  "version": "2.0",
  "statement": [{
      "action": [
          "tcr:Describe*",
          "tcr:PullRepository*"
      ],
      "resource": [
          "qcs::tcr:::repo/*"
      ],
      "effect": "allow"
  }]
}
Grant a sub-account permissions to manage the specific namespace in the specific region. For example, the namespace team-01 in the default region.
{
  "version": "2.0",
  "statement": [{
          "action": [
              "tcr:*"
          ],
          "resource": [
              "qcs::tcr:::repo/team-01",
              "qcs::tcr:::repo/team-01/*"
          ],
          "effect": "allow"
      }
  ]
}
Grant a sub-account the read-only permission for an image repository, which means that the sub-account can only pull the images in the image repository instead of deleting the repository, modifying repository attributes, or pushing images. For example, the image repository repo-demo in the namespace team-01 in the default region.
{
  "version": "2.0",
  "statement": [{
          "action": [
              "tcr:Describe*",
              "tcr:PullRepositoryPersonal"
          ],
          "resource": [
              "qcs::tcr:::repo/team-01",
              "qcs::tcr:::repo/team-01/repo-demo",
              "qcs::tcr:::repo/team-01/repo-demo/*"
          ],
          "effect": "allow"
      }
  ]
}


Update Guide of Resource Level APIs and Authorization Solution of Personal Edition

Last updated：2025-12-22 17:33:21

Overview

TCR provides container image hosting and distribution services to enterprise users and personal users. The Personal Edition provides users with simple and free basic services, that is, the image repository in TKE. To provide users with more standardized interface definitions and significantly reduced access delay API services, the APIs of the original Personal Edition image repository (CCR) has been upgraded from version 2.0 to the latest version 3.0, and the API name and authorization solutions have updated accordingly. This document describes the mappings between the new and legacy APIs after the upgrade of the APIs that support resource-level authentication and how to use the new authorization solution.

Mappings Between the v2.0 and v3.0 APIs

API Name of v2.0
API Name of v3.0
Description
Latest Resource Description Method
CreateCCRNamespace
CreateNamespacePersonal
Creates a namespace of Personal Edition
qcs::tcr:$region:$account:repo/$namespace
DeleteUserNamespace
DeleteNamespacePersonal
Deletes a namespace of Personal Edition
qcs::tcr:$region:$account:repo/$namespace
GetUserRepositoryList
DescribeRepositoryOwnerPersonal
Queries all repositories of Personal Edition
qcs::tcr:$region:$account:repo/*
CreateRepository
CreateRepositoryPersonal
Creates an image repository of Personal Edition
qcs::tcr:$region:$account:repo/$namespace/$repo
DeleteRepository
DeleteRepositoryPersonal
Deletes an image repository of Personal Edition
qcs::tcr:$region:$account:repo/$namespace/$repo
BatchDeleteRepository
BatchDeleteRepositoryPersonal
Deletes image repositories of Personal Edition in batches
qcs::tcr:$region:$account:repo/$namespace/*
DeleteTag
DeleteImagePersonal
Deletes the repository tag of Personal Edition
qcs::tcr:$region:$account:repo/$namespace/$repo
BatchDeleteTag
BatchDeleteImagePersonal
Deletes the repository tags of Personal Edition in batches
qcs::tcr:$region:$account:repo/$namespace/$repo
pull
PullRepositoryPersonal
Pulls the images in the image repository of Personal Edition
qcs::tcr:$region:$account:repo/$namespace/$repo
push
PushRepositoryPersonal
Pushes the images in the image repository of Personal Edition
qcs::tcr:$region:$account:repo/$namespace/$repo

Mappings Between the legacy and new Authorization Solutions

Due to the upgrade and update of the product name and API version, the original resource description methods and actions of the TCR Personal Edition have been updated accordingly. Please use the latest resources and action authorization solutions while using the v3.0 APIs. During the upgrade of APIs, CAM APIs will be compatible with both the legacy and new resource description methods and actions to ensure that the custom policies are still effective. To make it easier for you to manage the APIs and authorization solutions uniformly, we recommend that you upgrade the authorization solution to the latest version. For more information, please see Example of Authorization Solution of the Personal Edition.

The legacy resource-level authorization solution

Action: use ccr as the product prefix, and the API name is version 2.0. For example, create a namespace as ccr:CreateCCRNamespace.
Resource description: use ccr as the product name, and there is only a repo resource type. For example, to describe the image repository repo-b under the namespace namespace-a, it would be qcs::ccr:::repo/namespace-a/repo-b. If $region and $account are left empty, all regions will be used by default, and the account will be the root account of the CAM user who created the policy by default. For more information on authorization solution, see TKE Image Registry Resource-level Permission Settings.

The new resource-level authorization solution

Action: use tcr as the product prefix, and the API name is version 3.0. For example, create a namespace of Personal Edition as tcr:CreateNamespacePersonal.
Resource description: use tcr as the product name, and there are three resource types: instance, repository and repo. Among them, repo is a dedicated resource type of the Personal Edition. For example, to describe the image repository repo-b under the namespace of Personal Edition namespace-a, it would be qcs::tcr:$region:$account:repo/namespace-a/repo-b. If $region and $account are left empty, all regions will be used by default, and the account will be the root account of the CAM user who created the policy by default. For more information on authorization solution, see CAM APIs for Personal Edition and Example of Authorization Solution of the Personal Edition.

The compatible example of legacy and new authorization solutions

For example, the authorized sub-account can read the image repository of repo-b (an image repository of Personal Edition) under the namespace namespace-a in the default region. Then this account can only query the repository information and pull the image in the repository, but cannot modify the repository attributes, push images, and delete the repository.
Legacy authorization solution:
{
    "version": "2.0",
    "statement": [{
        "action": [
            "ccr:pull"
        ],
        "resource": "qcs::ccr:::repo/namespace-a/repo-b",
        "effect": "allow"
    }]
}
New authorization solution:
{
    "version": "2.0",
    "statement": [{
        "action": [
            "tcr:PullRepositoryPersonal"
        ],
        "resource": "qcs::tcr:::repo/namespace-a/repo-b",
        "effect": "allow"
    }]
}


Configuring Garbage Collection

Last updated：2025-12-22 17:33:21

Overview

This document describes how to configure/update a garbage collection policy for TCR Individual instances.

Notes

A garbage collection policy for TCR Individual instances is only applicable for the instances in the specified regions. For example, TCR Individual instances deployed in Guangzhou and Silicon Valley regions can be configured with other different garbage collection policies.

Directions

1. Log in to the TCR console and select Instance Management in the left sidebar. On the page that appears, you can view the list of instances under the current account. Select a TCR Individual instance in any region.

2. Click More > Configure garbage collection, as shown in the following figure.

On/Off: Select Enable Global Image Lifecycle Management.
Global rules:
Retain the latest XX image tag: Enter a number based on your actual needs. The number cannot exceed the default quota of image tags under the current root account.
Retain the image tags in the last XX day: Enter a number based on your actual needs.
3. Click OK.

Terminating/Returning Instances

Last updated：2025-12-22 17:33:21

Overview

This document introduces how to terminate or return Enterprise Edition instances in Tencent Container Registry (TCR).

Prerequisites

You have purchased a TCR Enterprise Edition instance, and the current account has the permissions to delete this instance.
Note:
Terminating and returning an instance is a high-risk action. To prevent accidental deletion, you are advised to delete all namespaces and repositories under an instance before deleting it. Otherwise, the instance cannot be deleted successfully.

Directions

Terminating or returning an instance in the TCR console

1. Log in to the TCR console.
2. Click Instance management in the left sidebar to go to the Instance management page.
3. Find the instance and choose More > Terminate/Return on the right side.
4. In the confirmation pop-up window, select Delete associated COS Bucket based on your needs, as shown in the figure below:


Note:
Please read the notes for terminating and returning the instance carefully. Deleting an instance will completely and irrecoverably erase the user data and relevant configuration stored during the use of the instance.
If you are sure that you no longer need the container images, Helm charts, and other underlying data stored during the use of TCR Enterprise Edition, you can select Delete associated COS Bucket to avoid unnecessary fees.
If the current account has overdue payments, the COS service does not allow you to directly delete the associated COS bucket. In this case, do not select that option. Instead, you need to delete the instance, and then go to the COS console to manage the COS bucket.
The billing of pay-as-you-go instances stops once they are terminated.
5. Select I have read and agreed to Refund Rules and click Confirm to delete the instance. No fees will be charged for this instance after deletion.
Note:
If it takes an unusually long time to delete an instance or the displayed status is Abnormal, please submit a ticket.

Terminating or returning an instance by calling an API

You can also call the DeleteInstance API to delete an instance. For more information, see DeleteInstance.