Tags

A tag is a key=value label on a resource, such as env=prod or cost-center=eu-42. Use tags to organize and filter your resources — by environment, owning team or cost centre.

This page covers:

tags on a resource, including Kubernetes clusters and node pools and databases, caches, message brokers, web servers and application gateways, plus VPC gateways and DNS records;
tenant default tags, which the platform adds to every resource created in a tenant;
tag colours, which make a tag look the same in every tenant of your organization;
Terraform: the provider's default_tags and the tags_all attribute.

Tag a resource

You can tag these resources:

VPCs, subnets and security groups
VPC gateways
Public IPs
Load balancers, and their listeners, pools, pool members and health monitors
Instances, scale groups and launch templates
Volumes and volume snapshots
Object storage buckets
DNS zones and DNS records
Secrets
Kubernetes clusters and node pools
Databases, caches, message brokers, web servers and application gateways, and the resources you create under them (see below)

Container registries have no tags. Instance snapshots take plain labels rather than key=value tags.

Each resource type has its own rules for tag keys and values, and some have a maximum number of tags. The portal checks them as you type, and the platform refuses a tag that breaks them.

Portal. Add tags in the Tags section of a create form. On most resources you can edit them later from the resource's page.

fm CLI. Pass --tag key=value (repeatable) when you create a resource (secrets take --tags instead; see below), and use tags get and tags set to read and replace the tags later:

bash

fm network security-group create --name web --vpc <vpc-id> --tag env=prod --tag team=web
fm network security-group tags get <security-group-id>
fm network security-group tags set <security-group-id> --tag env=prod --tag team=payments
fm network security-group tags set <security-group-id> --clear

tags set replaces the whole set: a tag you leave out is removed. Pass --clear to remove every tag. The same tags get and tags set commands exist for instances, volumes, buckets, VPCs, public IPs, load balancers and their pools and health monitors, scale groups and launch templates. DNS zones and secrets have no tags get or tags set: they take tags when you create them, and you change them with update. DNS zones use --tag (fm dns zone update --tag …, or --clear-tags to remove every tag). Secrets use --tags, comma-separated, on both create and update (fm secrets update --tags …, or --clear-tags). See DNS and Secrets.

Some resources also carry keys the platform manages, such as keys that start with frostmoln_. You cannot set them. tags get lists them separately as read-only, and the platform keeps them when you replace your tags.

Terraform. Set the tags argument:

hcl

resource "frostmoln_security_group" "web" {
  name   = "web"
  vpc_id = frostmoln_vpc.main.id

  tags = {
    env  = "prod"
    team = "web"
  }
}

Kubernetes clusters and node pools

A managed Kubernetes cluster and each of its node pools carry their own tags. Tags are your metadata for search and filtering, and the platform stores them only: they are not Kubernetes labels, and they never reach the cluster or its nodes. A node pool's labels — the Kubernetes node labels applied to every node in the pool — are a separate setting, and a tag filter never matches them.

Rule	Limit
Number of tags	At most 32 per cluster or node pool, including the tenant's default tags
Key	1 to 64 bytes of letters, digits and `.` `_` `:` `/` `-`; must start and end with a letter or digit
Value	At most 256 bytes, without control characters. A value may be empty.
Reserved key prefixes, in any case	`frostmoln_`, `frostmoln-`

Changing tags never touches the running cluster or its nodes.

The initial node pool gets a one-time copy. The node pool you create together with the cluster cannot be given its own tags in the create request. Instead, it gets a copy of the cluster's tags — the ones you set plus the tenant's default tags — once, when the cluster is created. Later changes to the cluster's tags do not reach it; edit the pool's own tags instead. A node pool you add later gets no copy of the cluster's tags: give it its own when you add it. The tenant's default tags are added to it, as to every new resource.

Portal. Set the cluster's tags in the Tags section of the create form. On the cluster's Overview tab, the Tags card shows them and Edit changes them. On the Node Pools tab, each pool shows its tags and has Edit tags, and the Add Pool form has its own tags. Filter the cluster list by tag with the tag filter above the list.

fm CLI.

bash

fm kubernetes cluster create --name prod --vpc <vpc-id> --subnet <subnet-id> \
  --node-flavor k8s.gp1.medium --tag env=prod --tag team=platform
fm kubernetes cluster list --tag env=prod
fm kubernetes cluster tags get <cluster-id>
fm kubernetes cluster tags set <cluster-id> --tag env=prod --tag team=payments
fm kubernetes node-pool create <cluster-id> --flavor k8s.gp1.large --name gpu --tag team=ml
fm kubernetes node-pool list <cluster-id> --tag team=ml
fm kubernetes node-pool tags get <cluster-id> <node-pool-id>
fm kubernetes node-pool tags set <cluster-id> <node-pool-id> --clear

tags set replaces the whole set, and --clear removes every tag. On list, repeat --tag to filter: a cluster or pool is listed only when it carries every tag you name.

Terraform. frostmoln_kubernetes_cluster and frostmoln_kubernetes_node_pool take tags and report tags_all, like every taggable resource (see Terraform). A cluster's tags do not manage its initial node pool's tags, and that pool cannot be managed as a frostmoln_kubernetes_node_pool: change its tags in the portal or with fm kubernetes node-pool tags set.

Databases, caches, message brokers, web servers and application gateways

These managed services carry tags on the service itself and on the resources you create under it:

Service	Taggable resources
Databases	Instances, read replicas, backups and parameter groups
Caches	Instances and backups
Message brokers	Instances
Web servers	Instances, domains and content deploys
Application gateway	Gateways, listeners, routes, backend pools, backends, certificates, allowed paths, firewall rule sets, published rule-set versions and firewall test runs (dry runs)

They follow the same rules as Kubernetes clusters: at most 32 tags per resource, including the tenant's default tags; keys of 1 to 64 bytes of letters, digits and . _ : / -, starting and ending with a letter or digit; values of at most 256 bytes without control characters; and the reserved prefixes frostmoln_ and frostmoln-, in any case.

Tags are your metadata for search and filtering, and the platform stores them only. Changing them never restarts, reconfigures or redeploys anything: on an application gateway, a tag is not configuration, so it needs no apply and does not change what the gateway serves. Each resource keeps its own tags:

Read replicas get the tags you give them plus the tenant's default tags. They do not copy the primary's tags, and a later change on either side does not reach the other.
A restore creates a new instance. It gets the tags you give it in the restore request plus the tenant's default tags. The source instance's tags are not copied.
Backups you create get the tags you give them plus the tenant's default tags. Scheduled backups get the tenant's default tags only. They are read from a copy that can be up to 30 seconds old, and if the platform cannot read them at all, the backup is still taken, without tags. Use Apply to existing resources on the Default tags page, or fm tenant default-tags apply, to add the defaults to such a backup later.
A web server content deploy is a resource of its own, and the tenant's default tags are added to it. A deploy therefore cannot start while the platform cannot read the tenant's defaults: it is refused with default_tags_unavailable (HTTP 503), and you can try again shortly.
An allowed path on an application gateway is shared by every backend in the same security group, protocol and port. Its tags are set when it is first created. Allowing the same path again reuses it and keeps its tags.

On the application gateway's listeners, routes, backends, certificates, allowed paths, rule-set versions and test runs, the tags are the only thing you can change after creation. A change request that names any other field is refused with field_not_updatable.

Portal. Set tags in the Tags section of the service's create form, and in the create dialogs of its resources (a replica, a backup, a restore, a domain, a deploy, a listener, a route, a pool, a backend, a certificate, an allowed path or a rule set). The service's page has a Tags card with Edit, and each resource in its tabs and sections shows its tags and has Edit tags. Filter a service's list by tag with the tag filter above it.

fm CLI. Every one of these resources except database parameter groups has tags get and tags set, and their create and list commands take --tag. Use fm v0.97.0 or newer. Parameter-group tags are set through the API:

bash

fm database postgres instance create --name orders ... --tag env=prod
fm database postgres instance list --tag env=prod
fm database postgres instance tags set <instance-id> --tag env=prod --tag team=payments
fm database postgres replica tags get <instance-id> <replica-id>
fm database postgres backup tags set <instance-id> <backup-id> --clear
fm cache redis instance tags set <instance-id> --tag env=prod
fm messaging lavinmq instance tags get <instance-id>
fm webserver nginx domain tags set <instance-id> <domain-id> --tag site=shop
fm webserver nginx deploys tags get <instance-id> <deploy-id>
fm appgw tags set <gateway-id> --tag env=prod
fm appgw listener tags set <listener-id> --gateway <gateway-id> --tag team=web

tags set replaces the whole set, and --clear removes every tag. On list, repeat --tag to filter: a resource is listed only when it carries every tag you name.

Terraform. These resources take tags and report tags_all, like every taggable resource (see Terraform): frostmoln_postgres_instance, frostmoln_mysql_instance, frostmoln_postgres_read_replica, frostmoln_mysql_read_replica, frostmoln_postgres_backup, frostmoln_mysql_backup, frostmoln_redis_instance, frostmoln_valkey_instance, frostmoln_messaging_instance, frostmoln_apache_instance, frostmoln_nginx_instance, frostmoln_webserver_domain, frostmoln_webserver_deployment, frostmoln_application_gateway, frostmoln_appgw_listener, frostmoln_appgw_route, frostmoln_appgw_backend_pool, frostmoln_appgw_backend, frostmoln_appgw_certificate, frostmoln_appgw_backend_authorization and frostmoln_appgw_waf_policy. See Provider versions for the provider they need.

VPC gateways and DNS records

A VPC's gateway and each DNS record carry their own tags. They follow the same rules as Kubernetes clusters: at most 32 tags per resource, including the tenant's default tags; keys of 1 to 64 bytes of letters, digits and . _ :/ -, starting and ending with a letter or digit; values of at most 256 bytes without control characters; and the reserved prefixes frostmoln_ and frostmoln-, in any case.

Tags are your metadata for search and filtering, and the platform only stores them. Changing a gateway's tags never touches its address or the VPC's connectivity, and needs no acknowledgement. A DNS record's tags are never published in DNS, and changing only the tags does not change the zone.

Portal. On a VPC's page, the Gateway card has a tags editor when you add a gateway, and the Gateway tags card shows and edits the tags of an existing one. On a DNS zone's page, the record dialog has a Tags section, the record list shows each record's tags, and the tag filter above the list narrows it.

API. The create requests take tags. On an update (PATCH for a gateway, PUT for a DNS record), tags replaces the whole set and {} removes every tag. A request that carries only tags changes nothing else. The gateway list, the DNS record list and the router list take a repeatable ?tag=key=value filter: a resource is listed only when it carries every tag you name.

Terraform. frostmoln_gateway and frostmoln_dns_record take tags and report tags_all, like every taggable resource (see Terraform). So do the load-balancer children frostmoln_lb_listener and frostmoln_lb_member. See Provider versions for the provider they need.

Existing resources. When the tenant's default tags are added to the resources a tenant already has (Apply to existing resources on the Default tags page, or fm tenant default-tags apply), VPC gateways and DNS records are included once the platform enables those types. Until then they get the tenant's default tags only when they are created.

Load-balancer pool members. A pool member carries its own tags, under the same rules as the other load-balancer resources. Set them when you add the member (in the portal, the Tags section of the add-member form); the tenant's default tags are added. Change them later with Edit tags on the member, or in the API with PUT on the member: tags replaces the whole set, and clearTags: true removes every tag (do not send both). Pool members are included when the tenant's default tags are added to existing resources.

Routers. A router's tags can be changed after it is created through the API: PUT /v1/tenants/{tenant-id}/routers/{router-id} takes tags, which replaces the whole set, or clearTags: true to remove every tag.

Tags in access policies

Access-policy constraints on frn:resourceTag/<k> (see Constraints) are not evaluated for the managed services: Kubernetes clusters and node pools, databases, caches, message brokers, web servers and application gateways, and the resources under them. Such a constraint counts as unknown, and an unknown constraint fails closed: an allow rule scoped by a resource tag never matches, and a deny rule scoped by a resource tag always applies. Do not use tag-scoped rules to grant access to these resources.

Tenant default tags

Tenant default tags are a set of tags that the platform adds to every taggable resource created in the tenant — whoever creates it: the portal, the fm CLI, the API or Terraform. Use them for tags every resource in a tenant should carry, such as its environment or cost centre.

How defaults are applied

They are copied when a resource is created. After that they are ordinary tags on the resource. You can change or remove them like any other tag, and nothing links them back to the tenant's defaults.
The resource's own tags win. A default is added only when the create request does not set that key itself. A key set to an empty value counts as set.
Only new resources get them. Changing the defaults never changes a resource that already exists.
A change takes up to 30 seconds. A resource created within 30 seconds of a change can still receive the previous set.
They count towards the resource's tag limit. If the defaults push a resource over its maximum number of tags, the create is refused. The error (tag_limit_exceeded_by_defaults) names the default keys. Remove some tags from the request, or ask an organization admin to reduce the tenant's defaults. On a create form, the portal shows the defaults that will be added and how many tags you can still add yourself.
A create never goes ahead without them. If the platform cannot read the tenant's defaults, the create is refused with a retryable error (default_tags_unavailable, HTTP 503). Try again shortly.

Instances that a scale group launches get the tenant's defaults as they are when the scale group scales out. A key in the launch template's metadata (the Terraform metadata argument) wins over a default; the template's own tags stay on the template and are not copied to the instances. If the platform still cannot read the defaults after retrying, the instances are launched without them, so that scaling does not stop.

Default tags are not added to:

container registries, which have no tags (every other managed service, and the resources you create under it, gets them);
resources the platform creates for a managed service;
instance snapshots, whose tags are plain labels.

Rules for default tags

A default lands on every kind of resource, so it has to be accepted by all of them. That makes the rules stricter than for the tags you set on a single resource.

Rule	Limit
Number of default tags	At most 10 per tenant
Key	1 to 64 bytes of letters (`a-z`, `A-Z`), digits and `.` `_` `:` `-`; must start and end with a letter or digit. No `/`, no spaces.
Value	0 to 255 bytes of letters, digits, spaces and `+` `-` `.` `_` `:` `/` `@` `=`. A value may be empty.
Reserved key prefixes, in any case	`frostmoln_`, `frostmoln-`, `os_`, `instance_`, `nova_`
Reserved keys, in any case	`request-id`, `customer-id`, `project-id`, `tenant-id`, `created-at`, `acl`, `storage-class`, `quota-bytes`, `cors-config`

Who can change them

Any member of the organization that owns the tenant can read its default tags. Changing them needs the admin or owner role in that organization. An API key needs the organizations:read scope to read them and organizations:write to change them; see API Key Scopes.

Each tenant has one set of default tags, empty until someone sets it. Every change replaces the whole set, and there is no locking: the last write wins, so manage the set from one place.

Set default tags

Portal. Open your account menu (top right) and choose Default tags. The page shows the defaults of the tenant you have selected. Admins and owners can add, change and remove tags and then Save; other members see a read-only list.

fm CLI. The commands act on the active tenant; pass --tenant for another.

bash

fm tenant default-tags get
fm tenant default-tags set --tag env=prod --tag cost-center=eu-42
fm tenant default-tags set --tag owner=team-a --merge
fm tenant default-tags clear

set replaces the whole set. With --merge it adds your tags to the current set instead. clear asks for confirmation; pass --yes when fm is not running in a terminal.

Terraform. The frostmoln_tenant_default_tags resource manages the whole set for the provider's tenant:

hcl

resource "frostmoln_tenant_default_tags" "this" {
  tags = {
    env         = "prod"
    cost-center = "eu-42"
  }
}

This resource owns the set. Every apply writes exactly tags, so a default added in the portal is removed by the next apply. Creating the resource replaces the set the tenant already has, and destroying it clears the set. Import an existing set by tenant id: terraform import frostmoln_tenant_default_tags.this <tenant-id>. The frostmoln_tenant_default_tags data source reads the set without managing it.

Tag colours

A tag colour rule shows a tag in a colour you choose, in the portal and in fm. Colours are set per organization and apply in every tenant of it, so env=prod looks the same everywhere. They are for display only: they change nothing about the resources.

A rule matches a key and one exact value (env=prod), or a key with any value (env).
For a tag key=value, the rule for exactly that value wins over the key's any-value rule.
A rule for the empty value is a different rule from the any-value rule: it matches only tags whose value is empty.
Keys and values are compared case-sensitively.
The colour is the tag's background, as #RRGGBB. The text is black or white, whichever contrasts better. The tag text is always shown, so colour is never the only signal.

Rule	Limit
Rules	At most 200 per organization, and one per key and value
Key	1 to 255 characters, without control or formatting characters
Value	At most 256 characters, without control or formatting characters; or none, to match any value
Reserved key prefixes	`frostmoln_` and `frostmoln-`, lower case only: a key such as `Frostmoln_Team` can be coloured
Colour	`#RRGGBB`, for example `#1f6feb`

Any member of the organization can read its colour rules. Adding, changing and deleting them needs the admin or owner role. An API key needs the organizations:read scope to read them and organizations:write to change them.

Portal. Go to Organizations, open your organization and choose the Settings tab. In the Tag colours card, choose Add colour, enter the tag key, then either tick Any value or enter a value, and pick a colour with the colour picker or type it as hex. Members who are not admins or owners see the list read-only.

fm CLI. fm organization tag-colors works on the organization that owns your active tenant; pass --organization for another. Exactly one of --value and --any-value is required. Quote the colour, because an unquoted # starts a shell comment, or leave the # out.

bash

fm organization tag-colors list
fm organization tag-colors set --key env --value prod --color '#d73a49'
fm organization tag-colors set --key team --any-value --color 1f6feb
fm organization tag-colors delete --key env --value prod

Running set again for the same key and value changes the rule's colour. On a terminal with 24-bit colour, fm also prints tags in their colours. It prints plain tags with --no-color or NO_COLOR, and when the output is not a terminal.

Terraform. Each frostmoln_tag_color resource manages one rule. Leave out value for an any-value rule. Without organization_id, the rule goes to the organization that owns the provider's tenant.

hcl

resource "frostmoln_tag_color" "prod" {
  key   = "env"
  value = "prod"
  color = "#d73a49"
}

resource "frostmoln_tag_color" "team" {
  key   = "team"
  color = "#1f6feb"
}

The frostmoln_tag_colors data source lists the organization's rules, with the ids you need to import one that was created in the portal.

Terraform: default_tags and tags_all

The provider's default_tags block adds tags to every taggable resource that this provider configuration manages:

hcl

provider "frostmoln" {
  default_tags {
    tags = {
      managed-by = "terraform"
      env        = "prod"
    }
  }
}

resource "frostmoln_vpc" "app" {
  name = "app"
  cidr = "10.1.0.0/16"

  tags = {
    env = "staging" # a resource tag wins over a default of the same key
  }

  # Create the VPC after the tenant defaults are set.
  depends_on = [frostmoln_tenant_default_tags.this]
}

output "app_vpc_tags" {
  value = frostmoln_vpc.app.tags_all
}

Each taggable resource has two tag attributes:

tags holds exactly what the resource's configuration sets.
tags_all is read-only and holds every tag on the resource: the provider's default_tags, the resource's own tags, the tenant's default tags, and anything set outside Terraform. Reference tags_all when you need the full set.

Keys set outside Terraform — in the portal, with fm, or by the tenant's default tags — appear only in tags_all, and the provider keeps them on every apply. It removes only the keys it manages: those in a resource's tags and those it applied from default_tags.

When the same key comes from more than one place, the most specific one wins:

Source	Precedence
The resource's `tags`	Highest
The provider's `default_tags`	Middle
The tenant's default tags	Lowest

Provider default_tags and tenant default tags differ in scope and timing:

	Tenant default tags	Provider `default_tags`
Applies to	Every resource created in the tenant, by any client	The resources one provider configuration manages
When	Once, when a resource is created	On every create and update
Changing them	Affects only resources created afterwards	Plans an in-place update of every taggable resource in the configuration
Shown in Terraform	In `tags_all` only	In `tags_all`
Rules	The rules for default tags	The same rules, checked when the provider is configured

Changing default_tags updates every taggable resource the provider manages. Nothing is replaced, but review the size of the plan before you apply it to a large configuration.

Snapshots are updated in place too, but the platform refuses a snapshot tag update (HTTP 409) while the snapshot is not available (it is still being taken, or is being restored; apply again once it is), and on some older snapshots that carry no owner tag. Manage such a snapshot with a second, aliased provider configuration that has no default_tags, and leave its tags unchanged, or take a new snapshot to replace it.

Provider versions

To use	You need provider
Terraform in a tenant that has default tags	v0.62.0 or newer
`default_tags` and `tags_all`	v0.62.0 or newer
`frostmoln_tag_color` and the `frostmoln_tag_colors` data source	v0.63.0 or newer
`frostmoln_tenant_default_tags` (resource and data source)	v0.65.0 or newer
`tags` on `frostmoln_kubernetes_cluster` and `frostmoln_kubernetes_node_pool`	v0.81.0 or newer
`tags` on the database, cache, message broker, web server and application gateway resources	v0.82.0 or newer
`tags` on `frostmoln_gateway`, `frostmoln_dns_record`, `frostmoln_lb_listener` and `frostmoln_lb_member`	v0.83.0 or newer

Once a tenant has default tags, older providers fail when they create a taggable resource in it, with "Provider produced inconsistent result after apply": the resource comes back with tags they did not expect. Upgrade the provider before you set default tags on a tenant that Terraform manages.

Upgrading from a version without tags_all changes one behaviour: a key set outside the configuration used to show as a difference on tags that the next apply removed. It now stays, in tags_all.

Migrating from another cloud

When you convert a configuration with fm terraform convert, the AWS provider's default_tags and the Google provider's default_labels become the Frostmoln provider's default_tags. The Azure provider has no provider-level default tags. Nothing is converted into tenant default tags, and no source cloud has tag colours. See the AWS, Azure and Google Cloud matrices for the details.

API Key Scopes · Cloud Migration
fm CLI Reference: fm organization · fm tenant
Terraform: frostmoln_tag_color · frostmoln_tag_colors data source

Compute / Instances

DNS

Databases

Kubernetes

IAM Access Policies

Container Registry

Tags

Tag a resource

Kubernetes clusters and node pools

Databases, caches, message brokers, web servers and application gateways

VPC gateways and DNS records

Tags in access policies

Tenant default tags

How defaults are applied

Rules for default tags

Who can change them

Set default tags

Tag colours

Terraform: default_tags and tags_all

Provider versions

Migrating from another cloud

DNS

Tags ​

Tag a resource ​

Kubernetes clusters and node pools ​

Databases, caches, message brokers, web servers and application gateways ​

VPC gateways and DNS records ​

Tags in access policies ​

Tenant default tags ​

How defaults are applied ​

Rules for default tags ​

Who can change them ​

Set default tags ​

Tag colours ​

Terraform: default_tags and tags_all ​

Provider versions ​

Migrating from another cloud ​

Related ​

Tags

Tag a resource

Kubernetes clusters and node pools

Databases, caches, message brokers, web servers and application gateways

VPC gateways and DNS records

Tags in access policies

Tenant default tags

How defaults are applied

Rules for default tags

Who can change them

Set default tags

Tag colours

Terraform: default_tags and tags_all

Provider versions

Migrating from another cloud

Related