Skip to main content
Variables allow you to define reusable values that can be referenced across your stacks. Define them at the organisation, cluster, or stack level and use them in manifests and add-on configurations.

Overview

Ankra supports variables at three levels with a clear precedence hierarchy: Precedence Order (highest to lowest):
  1. Stack variables - Variables defined for a specific stack (highest precedence)
  2. Cluster variables - Variables defined for a specific cluster
  3. Organisation variables - Variables defined for the entire organisation (lowest precedence)
Lower-level variables override higher-level ones. A stack variable with the same name as a cluster or organisation variable will take precedence for that stack.

Variable Syntax

Reference variables in your stacks using the following syntax:
${{ ankra.variable_name }}
Examples:
# In a manifest
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: default
data:
  domain: ${{ ankra.domain_name }}
  api_url: https://${{ ankra.domain_name }}/api
# In Helm values
ingress:
  enabled: true
  hosts:
    - host: ${{ ankra.domain_name }}

Organisation Variables

Organisation variables apply to all clusters and stacks within your organisation. Use them for values that are consistent across your entire infrastructure.

Creating Organisation Variables

1

Navigate to Variables

Go to Organisation SettingsVariables.
2

Add a Variable

Click Add Variable to open the creation form.
3

Enter Variable Details

Fill in the required fields:
  • Variable Name: Must start with a letter, containing only letters, numbers, and underscores (e.g., domain_name, api_key)
  • Value: The variable’s value
  • Description (optional): A brief description for documentation
  • Secret: Check this box to mask the value in the UI
4

Create

Click Create Variable to save.

Common Organisation Variables

Variable NameExample ValueUse Case
domain_nameexample.comBase domain for all services
registry_urlghcr.io/myorgContainer registry URL
environmentproductionEnvironment identifier
alert_email[email protected]Notification email address
log_levelinfoDefault logging level

Cluster Variables

Cluster variables apply to all stacks deployed to a specific cluster. Use them for cluster-specific configurations that differ between environments.

Creating Cluster Variables

1

Navigate to Cluster Settings

Go to your cluster → SettingsVariables.
2

Add a Variable

Click Add Variable to open the creation form.
3

Enter Variable Details

Fill in the required fields:
  • Variable Name: Must start with a letter, containing only letters, numbers, and underscores
  • Value: The variable’s value
  • Description (optional): A brief description
  • Secret: Check this box to mask the value in the UI
4

Create

Click Create Variable to save.

Common Cluster Variables

Variable NameExample ValueUse Case
cluster_domainprod.example.comCluster-specific subdomain
storage_classgp3Default storage class
node_selectorapp=productionNode selector labels
replica_count3Default replica count
resource_quotahighResource allocation tier

Stack Variables

Stack variables are specific to a single stack and have the highest precedence. Use them for stack-specific configurations that should override cluster and organisation variables.

Creating Stack Variables

1

Open the Stack Builder

Navigate to your cluster → Stacks and open an existing stack or create a new one.
2

Go to Variables Tab

Click the Variables tab in the Stack Builder.
3

Add a Variable

Click Add Variable to create a new variable entry.
4

Enter Variable Details

Fill in the fields:
  • Variable Name: Must start with a letter, containing only letters, numbers, and underscores
  • Value: The variable’s value
5

Save

Click Save Variables to persist the changes.
Stack variables are saved as part of the stack configuration. When you deploy the stack to GitOps, the variables are resolved before manifests are written.

Common Stack Variables

Variable NameExample ValueUse Case
app_versionv2.1.0Application version tag
replicas5Stack-specific replica count
feature_flagenabledFeature toggles
log_leveldebugStack-specific logging
custom_config{"key": "value"}JSON configuration

When to Use Stack Variables

Use stack variables when:
  • A specific stack needs values that differ from cluster defaults
  • You want to override cluster or organisation variables for one stack
  • You’re testing different configurations on the same cluster
  • You need stack-specific feature flags or version tags

Secret Variables

Mark variables as secrets when they contain sensitive values like API keys, passwords, or tokens.
Secret variables are masked in the UI but are still stored as-is on the server. For encrypted storage, use SOPS encryption instead.

Secret Variable Features

  • Masked Display: Values show as •••••••• in the UI
  • Reveal Option: Click the eye icon to temporarily reveal the value
  • Copy Protection: Values can still be copied for use in configurations

When to Use Secrets vs SOPS

FeatureSecret VariablesSOPS Encryption
UI MaskingYesN/A
Git StoragePlaintextEncrypted
Runtime DecryptionNoYes
Best ForUI-only protectionFull encryption at rest
Use secret variables for convenience in the UI. Use SOPS when you need values encrypted in your Git repository.

Using Variables in Stacks

In Manifests

Reference variables anywhere in your Kubernetes manifests:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: ${{ ankra.replica_count }}
  template:
    spec:
      containers:
        - name: app
          image: ${{ ankra.registry_url }}/myapp:latest
          env:
            - name: DOMAIN
              value: ${{ ankra.domain_name }}

In Add-on Values

Use variables in Helm chart values:
# Grafana add-on values
grafana:
  adminPassword: ${{ ankra.grafana_password }}
  ingress:
    enabled: true
    hosts:
      - grafana.${{ ankra.cluster_domain }}

Variable Resolution

When you deploy a stack, Ankra resolves variables in this order:
  1. Check for a matching stack variable (highest priority)
  2. If not found, check for a matching cluster variable
  3. If not found, check for a matching organisation variable
  4. If still not found, the literal ${{ ankra.variable_name }} is left in place (which will likely cause deployment errors)
This precedence allows you to define sensible defaults at the organisation level, environment-specific overrides at the cluster level, and stack-specific customizations when needed.

Managing Variables

Copying Variable Syntax

Click the Copy icon next to any variable to copy its full syntax:
${{ ankra.variable_name }}
This copies the ready-to-use syntax for pasting into your manifests.

Deleting Variables

Deleting a variable that is in use by stacks will cause deployment failures. Review stack usage before deleting.
  1. Click the Delete (trash) icon next to the variable
  2. The variable is immediately removed

Variable Naming Rules

Variable names must follow these rules:
  • Start with a letter (a-z, A-Z)
  • Contain only letters, numbers, and underscores
  • Be unique within their scope (organisation or cluster)
Valid names: domain_name, API_KEY, replica_count_v2 Invalid names: 123_name, my-variable, name with spaces

Best Practices

Use descriptive names: Choose names that clearly indicate the variable’s purpose. prod_db_host is better than host1.
Document with descriptions: Add descriptions to help team members understand each variable’s purpose.
Organize by scope: Use organisation variables for global values, cluster variables for environment-specific values.
Use consistent naming conventions: Adopt a convention like snake_case and stick to it across your organisation.

AI Prompts

Press ⌘+J to open the AI Assistant and use these prompts:
I need to deploy the same stack to dev and prod clusters with
different domain names. Help me set up variables.
Review my stack and suggest which values should be
converted to variables.