Skip to content

Solution Variables

Variables allow solutions to have environment-specific configuration without modifying the underlying actions or sequences.

Variables are placeholders in your solution that can have different values per environment:

VariableDevelopmentStagingProduction
database_hostdev-db.localstaging-db.company.comprod-db.company.com
log_leveldebuginfowarn
replica_count125

Variables are defined as templates on the solution, then values are set per environment.

PropertyDescriptionRequired
NameIdentifier (e.g., database_host)Yes
LabelDisplay nameYes
Help TextGuidance for operatorsNo
Control TypeInput type (text, select, etc.)Yes
Default ValueFallback if not setNo
RequiredMust have a valueYes

Single-line text input:

┌─────────────────────────────────────────────────────────┐
│ Database Hostname │
│ ┌───────────────────────────────────────────────────┐ │
│ │ db.example.com │ │
│ └───────────────────────────────────────────────────┘ │
│ Enter the primary database server address │
└─────────────────────────────────────────────────────────┘

Use for: Hostnames, URLs, paths, simple values

Multi-line text area:

┌─────────────────────────────────────────────────────────┐
│ Configuration JSON │
│ ┌───────────────────────────────────────────────────┐ │
│ │ { │ │
│ │ "feature_flags": { │ │
│ │ "new_checkout": true │ │
│ │ } │ │
│ │ } │ │
│ └───────────────────────────────────────────────────┘ │
│ JSON configuration for the application │
└─────────────────────────────────────────────────────────┘

Use for: JSON, YAML, configuration files, scripts

Dropdown selection:

┌─────────────────────────────────────────────────────────┐
│ Log Level │
│ ┌───────────────────────────────────────────────────┐ │
│ │ info ▼ │ │
│ └───────────────────────────────────────────────────┘ │
│ • debug │
│ • info │
│ • warn │
│ • error │
└─────────────────────────────────────────────────────────┘

Use for: Predefined options, log levels, regions

Boolean toggle:

┌─────────────────────────────────────────────────────────┐
│ Enable Debug Mode │
│ ┌───┐ │
│ │ ✓ │ Enable │
│ └───┘ │
│ Turn on detailed logging for troubleshooting │
└─────────────────────────────────────────────────────────┘

Use for: Feature flags, on/off settings

Masked input for secrets:

┌─────────────────────────────────────────────────────────┐
│ API Key │
│ ┌───────────────────────────────────────────────────┐ │
│ │ •••••••••••••••••••••••••• │ │
│ └───────────────────────────────────────────────────┘ │
│ API key for external service integration │
└─────────────────────────────────────────────────────────┘

Use for: Passwords, API keys, tokens, secrets

  1. Open solution detail page
  2. Navigate to Variables tab
  3. Click Add Variable Template
  4. Configure template properties
  5. Save
┌─────────────────────────────────────────────────────────┐
│ Add Variable Template │
├─────────────────────────────────────────────────────────┤
│ │
│ Name: [database_host ] │
│ Label: [Database Hostname ] │
│ Help Text: [Primary PostgreSQL server ] │
│ │
│ Control Type: [Text ▼] │
│ │
│ Default: [localhost ] │
│ Required: [✓] │
│ │
│ [Cancel] [Add] │
└─────────────────────────────────────────────────────────┘
  1. Navigate to the environment detail page
  2. Find the solution in the list
  3. Click Configure Variables
  4. Enter values for each variable
  5. Save
┌─────────────────────────────────────────────────────────┐
│ Configure Variables: customer-portal │
│ Environment: Production │
├─────────────────────────────────────────────────────────┤
│ │
│ Database Hostname │
│ ┌───────────────────────────────────────────────────┐ │
│ │ prod-db.company.com │ │
│ └───────────────────────────────────────────────────┘ │
│ │
│ Log Level │
│ ┌───────────────────────────────────────────────────┐ │
│ │ warn ▼ │ │
│ └───────────────────────────────────────────────────┘ │
│ │
│ Replica Count │
│ ┌───────────────────────────────────────────────────┐ │
│ │ 5 │ │
│ └───────────────────────────────────────────────────┘ │
│ │
│ [Cancel] [Save] │
└─────────────────────────────────────────────────────────┘

Resolved variables reach an action in two ways during deployment:

  1. {{...}} substitution in command arguments, the script file name, and the working directory. The supported placeholder syntaxes are {{variable}} (mustache) and ${variable} (shell-style).
  2. MANTIS_* environment variables injected into the executed process. Each resolved variable is exposed as an uppercased, MANTIS_-prefixed environment variable (for example, database_host becomes MANTIS_DATABASE_HOST).

Command payloads are structured (a binary plus ordered arguments), so reference variables inside individual arguments with {{...}}:

  • Binary: docker
  • Argument 1: run
  • Argument 2: --env
  • Argument 3: DB_HOST={{database_host}}
  • Argument 4: --env
  • Argument 5: LOG_LEVEL={{log_level}}
  • Argument 6: myapp

When using the DefaultShell executor (the default), arguments are passed directly to the binary without any shell interpretation, so shell metacharacters are treated as literal values. When using the Sh, Bash, Pwsh, or Zsh executors, Mantis rejects shell metacharacters (;, |, $, `, etc.) in arguments before execution, preventing chaining, piping, or $VAR expansion; the arguments are then safely quoted and passed to the shell as a single composed command.

A script’s content is not substituted. Read resolved variables from their MANTIS_* environment variables instead:

#!/bin/bash
echo "Connecting to $MANTIS_DATABASE_HOST"
docker compose up -d --scale web="$MANTIS_REPLICA_COUNT"

During deployment, Mantis resolves variables through five precedence levels. Later levels override earlier ones:

Default values defined on the solution template (precedence level 1).

Tenant-wide variables that apply across all projects. A value set without an environment applies to every environment (level 2); a value scoped to a specific environment overrides that for that environment only (level 3).

Variables tied to this specific project within the tenant. An unscoped value applies to all environments (level 4); an environment-scoped value provides the final, highest-priority override (level 5).

Good: database_primary_host, api_gateway_url
Bad: db, host1, var1

Help operators understand what values to provide:

Variable: connection_string
Help: PostgreSQL connection string in format:
postgres://user:pass@host:5432/dbname

Provide defaults for development/testing:

Variable: log_level
Default: info
(Production can override to "warn")

Always use the sensitive control type for:

  • Passwords
  • API keys
  • Tokens
  • Certificates
  • Connection strings with credentials

Set variables as required when they must have values:

Variable: database_host
Required: true
(Deployment fails if not set)
VariableTypeExample
database_hostTextdb.example.com
database_portText5432
database_nameTextmyapp_production
database_userTextapp_user
database_passwordSensitive•••••••
VariableTypeExample
feature_new_uiCheckboxtrue
feature_beta_apiCheckboxfalse
feature_analyticsCheckboxtrue
VariableTypeExample
web_replicasText3
worker_replicasText2
max_connectionsText100

Symptom: Seeing {{variable_name}} in output

Solutions:

  • Check variable is defined on solution
  • Check environment has a value set
  • Verify spelling matches exactly
  • Remember that script content is never substituted — a script should read the value from its MANTIS_* environment variable instead

Deployment Fails: Missing Required Variable

Section titled “Deployment Fails: Missing Required Variable”

Symptom: Deployment fails with “required variable not set”

Solution: Set the value on the target environment before deploying

Symptom: Secret appears in deployment logs

Solution: Ensure variable is marked as sensitive control type