Environment Variables

Many application frameworks use environment variables to indicate the current deployment environment. shellfirm reads these variables and escalates protection when it detects a production environment.

How it works

shellfirm checks a configurable set of environment variable name-value pairs. For each configured pair, it reads the environment variable and compares the value (case-insensitive). If the value matches, the variable is recorded as a production signal and the risk level is set to Critical.

Default environment variables

Variable	Trigger value	Used by
NODE_ENV	production	Node.js, Next.js, Express, and most JavaScript frameworks
RAILS_ENV	production	Ruby on Rails
ENVIRONMENT	production	Generic convention used by many tools and platforms

All comparisons are case-insensitive: Production, PRODUCTION, and production all match.

Context labels

When production environment variables are detected, shellfirm records them as environment signals:

NODE_ENV=production

Multiple signals can appear if more than one variable matches:

NODE_ENV=production
ENVIRONMENT=production

Escalation behavior

Any matching production environment variable sets the risk level to Critical, escalating challenges to at least Yes:

Configured challenge	With production env var
Math	Yes
Enter	Yes
Yes	Yes

Adding custom environment variables

Edit ~/.shellfirm/settings.yaml to add your own environment variables:

context:
  production_env_vars:
    NODE_ENV: production
    RAILS_ENV: production
    ENVIRONMENT: production
    DJANGO_SETTINGS_MODULE: myapp.settings.production
    FLASK_ENV: production
    MIX_ENV: prod
    APP_ENV: production
    SPRING_PROFILES_ACTIVE: prod

Each entry maps a variable name to the expected production value. You can add as many as you need for the frameworks and tools your team uses.

Removing default variables

To override the defaults entirely, specify only the variables you want:

context:
  production_env_vars:
    # Only check these two — NODE_ENV, RAILS_ENV, and ENVIRONMENT defaults are replaced
    APP_ENV: production
    DEPLOY_TARGET: live

When you explicitly set production_env_vars in your settings file, it replaces the default set rather than merging with it.

Practical examples

Node.js production server

# NODE_ENV=production is set
npm run db:migrate:reset

# ============ RISKY COMMAND DETECTED ============
# Severity: HIGH
# Context: NODE_ENV=production
# Description: Resets database migrations, which can cause data loss.
# Alternative: npm run db:migrate:status
#   (Shows the current migration status without making changes.)
# Challenge ESCALATED: Math -> Yes
#
# ? Type `yes` to continue Esc to cancel ›

Rails production console

# RAILS_ENV=production is set
rails db:drop

# ============ RISKY COMMAND DETECTED ============
# Severity: CRITICAL
# Context: RAILS_ENV=production
# Description: Drops the entire database, destroying all data.
# Alternative: rails db:schema:dump
#   (Exports the current schema to a file for backup before any destructive operation.)
# Challenge ESCALATED: Math -> Yes
#
# ? Type `yes` to continue Esc to cancel ›

Multiple signals stacking

# Both NODE_ENV=production and ENVIRONMENT=production are set
rm -rf node_modules/ dist/

# ============ RISKY COMMAND DETECTED ============
# Severity: HIGH
# Context: NODE_ENV=production, ENVIRONMENT=production
# Description: Recursively deletes files and directories.
# Alternative: rm -ri node_modules/ dist/
#   (Prompts before each file removal so you can confirm individually.)
# Challenge ESCALATED: Math -> Yes
#
# ? Type `yes` to continue Esc to cancel ›

Team policy integration

Production environment variables can also be configured in .shellfirm.yaml project policies:

# .shellfirm.yaml
version: 1
context:
  production_env_vars:
    DEPLOY_ENV: production
    SERVICE_TIER: critical

Policy-level variables are merged with your global configuration.