Skip to main content
Selectors are Ctrlplane’s powerful filtering system for targeting resources, environments, and deployments. They allow dynamic, rules-based matching instead of static assignments.

Why Selectors?

Traditional deployment tools require manually assigning resources to environments. Ctrlplane uses selectors for dynamic matching:

Without Selectors (Traditional)

With Selectors (Ctrlplane)

Selector Types

Ctrlplane supports several types of selectors:
  1. Metadata Selector - Match on resource metadata
  2. Kind Selector - Match on resource kind
  3. Identifier Selector - Match on resource identifier
  4. Name Selector - Match on resource/environment name
  5. CEL Selector - Complex expressions using CEL (Common Expression Language)
  6. Composite Selectors - Combine selectors with AND/OR logic

Metadata Selector

Match resources based on metadata key-value pairs using CEL expressions.

Simple Equality

Matches resources where metadata.environment === "production".

Supported Operators

equals

Exact match:

not_equals

Does not match:

contains

Value contains substring:
Matches: prod-cluster-1, k8s-prod, production-server.

matches (Regex)

Regular expression match:
Matches: prod-cluster-1, prod-server-42.

exists

Key exists with any value:
Matches any resource with a team metadata key.

not_exists

Key does not exist:

in

Value is in a list:

not_in

Value is not in a list:

Kind Selector

Match resources by their kind field.
Common Use Cases:
  • Kubernetes-only deployments: resource.kind == "KubernetesCluster"
  • VM-only deployments: resource.kind == "VirtualMachine"
  • Exclude certain kinds: resource.kind != "DeprecatedResource"

Identifier Selector

Match resources by their identifier.
Use Cases:
  • Match specific naming patterns
  • Filter by identifier prefix/suffix
  • Regex matching on identifiers

Name Selector

Match by the resource or environment name field.
Use Cases:
  • Policy selectors targeting specific environments
  • Matching resources by name patterns

Composite Selectors (AND/OR)

Combine multiple conditions with boolean logic using CEL operators.

AND Logic

All conditions must match:
Matches: Resources with BOTH environment=production AND region=us-east-1.

OR Logic

Any condition can match:
Matches: Resources in EITHER us-east-1 OR us-west-2.

Nested Logic

Combine AND and OR:
Matches: environment=production AND (region=us-east-1 OR region=us-west-2).

CEL Expressions

Ctrlplane uses CEL (Common Expression Language) for all selectors:

CEL Basics

Field Access:
  • resource.metadata["environment"] - Access metadata field
  • resource.kind - Access kind field
  • resource.name - Access name field
  • resource.identifier - Access identifier field
Operators:
  • ==, != - Equality
  • &&, || - Logical AND/OR
  • ! - Logical NOT
  • <, >, <=, >= - Comparison
  • in - List membership
  • .matches() - Regex match
Examples:

CEL Best Practices

Do:
  • ✅ Use CEL for complex nested logic
  • ✅ Keep expressions readable with line breaks
  • ✅ Test selectors before applying
  • ✅ Reference the CEL Reference for syntax
Avoid:
  • ❌ Overly complex expressions that are hard to understand
  • ❌ Expressions that might accidentally match wrong resources

Selector Use Cases

Environment Resource Selectors

Define which resources belong to an environment:

Deployment Resource Selectors

Limit which resources a deployment can target:

Policy Selectors

Target policies to specific deployments/environments/resources:
This policy applies to critical deployments going to production.

Testing Selectors

Via CLI

Test a selector against your resources:
Returns all resources matching the selector.

Via Web UI

Most selector configuration screens have a “Test Selector” or “Preview Resources” button that shows which resources match.

Common Selector Patterns

Pattern 1: Environment-Based

Use Case: Standard environment separation (dev/staging/prod).

Pattern 2: Region-Based

Use Case: Multi-region deployments, gradual regional rollout.

Pattern 3: Team-Based

Use Case: Team-specific resources and deployments.

Pattern 4: Tier-Based

Use Case: SLA-based resource grouping.

Pattern 5: Canary

Use Case: Canary deployment pattern.

Pattern 6: Percentage-Based (using identifier)

Use Case: Target resources with even-numbered identifiers (50% rollout).

Best Practices

Metadata Schema Design

Design your resource metadata with selectors in mind: Good Metadata Schema:
Why Good:
  • Consistent key names
  • Enumerated values (not free-form)
  • Multiple dimensions for targeting
  • Clear, hierarchical organization

Selector Simplicity

Prefer Simple Selectors:
Over Complex Ones:
Simple selectors are:
  • Easier to understand
  • Less error-prone
  • More performant

Document Complex Selectors

If you must use complex selectors, document them:

Test Before Applying

Always test selectors before using them:
  1. Use the query API to see matched resources
  2. Verify count matches expectations
  3. Check for unexpected matches
  4. Test in lower environment first

Avoid Over-Matching

Be specific to avoid accidentally matching wrong resources: Too Broad:
Might match: prod-cluster, product-server, reproduction-env. Better:
Only matches identifiers starting with prod-.

Troubleshooting

Selector matches too many resources

  • Make selector more specific (add conditions)
  • Use AND instead of OR
  • Add negation conditions
  • Check resource metadata for unexpected values

Selector matches too few resources

  • Check metadata key names match exactly (case-sensitive)
  • Verify resources have the expected metadata
  • Use OR logic if resources vary
  • Test with simpler selector first

Selector matches nothing

  • Verify selector syntax is correct
  • Check resources exist with expected metadata
  • Test each condition independently
  • Review resource metadata in UI

CEL expression errors

Advanced Topics

Selector Evaluation Order

When multiple selectors apply (e.g., environment + deployment):
  1. Environment selector filters resources
  2. Deployment selector (if present) filters further
  3. Final set is intersection of both

Selector Performance

Selectors are evaluated:
  • When resources are created/updated
  • When environments/deployments are created/updated
  • When querying resources
Performance Tips:
  • Simple selectors are faster than complex ones
  • Metadata equality checks are very fast
  • Regex matching is slower
  • CEL expressions have some overhead

Selector Caching

Ctrlplane caches selector evaluation results:
  • Cache invalidated on resource/metadata changes
  • Improves performance for repeated queries
  • No manual cache management needed

Next Steps