Skip to main content

Expression Examples

Codiac expressions are JSONata expressions evaluated against a structured context object. They work in three places:

  • Config setting values — the expression result becomes the setting's value at deploy time
  • Config setting conditions — controls whether a setting is included in a deployment
  • Asset deploy conditions — controls whether an asset is deployed at all

For the full list of available fields and functions, see Expression Context Reference.

Deploy conditions​

Deploy conditions gate whether an asset is deployed at all. A falsy result skips the asset with a reason message included in the deploy output.

Limit an asset to the dev environment​

environment.name = "dev"

The asset deploys only when the environment is named dev. In all other environments it is skipped with its condition reason.

Limit an asset to a specific cloud provider​

cluster.provider = "azure"

Useful when an asset depends on a cloud-specific service not available elsewhere.

Deploy only when ingress is enabled​

cluster.ingress.enabled = true

Useful for assets that are only meaningful when the cluster has external routing active, such as API gateways or public frontends.

Deploy only when ingress is public​

cluster.ingress.private = false

Skips the asset on clusters configured with private-only ingress.

Config setting conditions​

Setting conditions control whether a specific config entry is included in a deployment. A falsy result omits the setting entirely — as if it were never set at that scope.

Include a setting only in production​

environment.name = "prod"

Useful for production-only flags such as analytics tokens, rate limits, or feature gates.

Exclude a setting from a specific enterprise​

enterprise.name != "sandbox"

Apply a setting only when ingress is private​

cluster.ingress.private = true

Config setting values​

In a config value, the expression result becomes the value itself. Use this to build values dynamically from the deployment context rather than maintaining them per-environment.

Embed the asset name in a URL​

"https://" & asset.name & ".internal.example.com"

If asset.name is "payments-api", this resolves to https://payments-api.internal.example.com.

Use the cluster region in a config​

cluster.location.code

Resolves to the cloud region code at deploy time (e.g., "eastus" or "us-east-1").

Build a scoped logging tag​

asset.name & " [" & cabinet.namespace & "]"

Produces a prefix like payments-api [prod-us-east] — useful as a log source label when the same config template is shared across cabinets.

Using $hostmap() in config values​

$hostmap(strategy, domain) resolves a concrete hostname from the cabinet's ingress configuration. Use it to wire a fully-resolved domain into a config value at deploy time, so you don't have to maintain per-environment hostnames manually.

Set an API base URL from the cluster's ingress​

"https://" & $hostmap("svc.cab.domain", "example.com")

If the cabinet resolves to api.dev-cabinet.example.com, this produces https://api.dev-cabinet.example.com.

Path-routed service prefix​

$hostmap_path("svc.cab.domain", "example.com")

Returns the path prefix for clusters configured with path-based routing instead of subdomain routing.

See Ingress and Domain Routing for details on host naming strategies.

Inline secrets​

Use @{secrets.<storeName>.<secretKey>} to embed a secret from a KVP store directly within a config value at deploy time. Codiac fetches each referenced store once before expression evaluation begins, so all references to the same store are batched into a single call.

Supported stores: Azure Key Vault, AWS Secrets Manager.

Connection string with an embedded password​

"Server=prod-db;Database=myapp;Password=" & secrets.myVault.DB_PASS

The value stored in Codiac is the expression above. At deploy time, Codiac fetches DB_PASS from myVault and writes the fully resolved connection string into the config.

Inline secret in a post-deploy job spec​

postDeployJob:
  connectionString: "Server=prod-db;Password=@{secrets.myVault.DB_PASS}"
  apiKey: "@{secrets.myVault.API_KEY}"

Both secrets are fetched from myVault in a single call and embedded in the rendered config before the job runs.

Mix context fields and secrets in one value​

"https://" & asset.name & ".example.com?token=" & secrets.myVault.SERVICE_TOKEN

Context fields and secret values can be combined in a single expression.

When to use inline secrets vs. sourcedSettings​

Two mechanisms exist for pulling secret values into configs:

MechanismUse when
@{secrets.<store>.<key>}The secret is one part of a larger composite string (connection string, job argument, URL)
sourcedSettings (#REF|store|key)The setting's entire value is the secret

If API_KEY is the whole value of a setting, use sourcedSettings. If it needs to be embedded in Bearer @{secrets.myVault.API_KEY}, use an inline expression.

Error behavior​

If the referenced store or key cannot be resolved, the deploy fails immediately with a clear error message identifying the unresolved expression. There is no fallback or silent empty value.

Pre-deploy init container: logging setup​

When configuring a pre-deploy hook — for example, an init container that sets up log shipping — you can use context fields to scope the logging output to the specific asset and cabinet without hard-coding those values.

Log source label (config value):

asset.name & "-" & cabinet.namespace

Environment scope label (config value):

enterprise.name & "/" & environment.name

Condition — only inject the logging config outside dev:

environment.name != "dev"

Because config conditions are evaluated at deploy time, the logging init container config is automatically omitted when deploying to dev and injected everywhere else — with no per-environment duplication.

What's next​