Overview
When Qovery provisions infrastructure on a cloud provider (cluster, network, IAM roles, security groups, and related resources), it automatically applies a set of system tags to every resource it creates. These tags are used for traceability, cost allocation, and to identify Qovery-managed resources within a cloud account. This is distinct from the Labels & Annotations feature, which lets you define your own Kubernetes label/annotation groups and optionally propagate them as cloud provider tags on specific resources (managed databases and AWS clusters). The tags described on this page are applied unconditionally by Qovery, independently of any labels/annotations configuration.On AWS, custom tags and Qovery’s system tags can coexist on the same resource. If a custom tag key collides with a system tag key, the system tag always takes precedence and cannot be overridden.
AWS (EKS)
Additional resource-specific tags are applied where required by AWS itself, for example
kubernetes.io/cluster/qovery-<id>=shared and kubernetes.io/role/elb/kubernetes.io/role/internal-elb on VPC subnets, so that the AWS cloud controller and load balancer controller can discover them.
Nodes provisioned by Karpenter receive the same ClusterId, ClusterLongId, OrganizationId, OrganizationLongId, and Region tags.
Google Cloud (GKE)
On GCP, these are applied as resource labels rather than free-form tags.
A reduced label set (
cluster_long_id, organization_long_id, region, creation_date, ttl) is used on resources with tighter metadata limits, such as service accounts.
Azure (AKS)
These tags are applied to the AKS cluster and node pools, managed identities, the resource group, the virtual network and subnets, and the storage account.
Scaleway (Kapsule)
Scaleway resources take tags as a flat list ofkey=value strings rather than a key/value map.
Worker nodes additionally receive
QoveryNodeGroupName and QoveryNodeGroupId, identifying the node group and instance type/index they belong to.