Skip to main content
Variables let you parameterize your monitors so the same monitor file can run against different environments. Unlike secrets, variable values are baked into the monitor definition when you run griffin apply — they’re not resolved at execution time.

​
Using variables

import { variable } from "@griffin-app/griffin";

builder.request("check", {
  method: GET,
  base: variable("API_HOST"),
  response_format: Json,
  path: "/health",
})
When you run griffin apply production, the CLI resolves variable("API_HOST") using the value set for the production environment.

​
Template interpolation

Use a template string to embed a variable within a larger value: 
variable("API_VERSION", "/api/${API_VERSION}/health")
The template must contain ${key} matching the variable key.

​
Managing variables with the CLI

# Set a variable for an environment
griffin variables add API_HOST=https://api.staging.example.com --env staging
griffin variables add API_HOST=https://api.example.com --env production

# List variables
griffin variables list --env staging

# Remove a variable
griffin variables remove API_HOST --env staging

​
Variables vs secrets

VariablesSecrets
ResolvedAt deploy time (griffin apply)At execution time (by the executor)
Stored in monitorYes — the resolved value is baked inNo — only a reference is stored
Visible in hubYesNo — values never leave the secret provider
Use forBase URLs, paths, non-sensitive configAPI keys, tokens, passwords

​
Common patterns

​
Per-environment base URLs

builder.request("check", {
  method: GET,
  base: variable("API_HOST"),
  response_format: Json,
  path: "/health",
})

griffin variables add API_HOST=https://api.staging.example.com --env staging
griffin variables add API_HOST=https://api.example.com --env production

​
Versioned API paths

builder.request("check", {
  method: GET,
  base: variable("API_HOST"),
  response_format: Json,
  path: variable("API_VERSION", "/api/${API_VERSION}/users"),
})