Environment Variables

Environment variables let you inject configuration values and secrets into the sandbox. The assistant's code can read these values at runtime, enabling access to APIs, databases, or other services during investigations.

What environment variables are for

Environment variables provide runtime configuration to code executing in the sandbox. Common uses include:

• API credentials: Keys for internal services, third-party APIs, or databases that investigation scripts might query.
• Endpoint URLs: Base URLs for staging, production, or internal services.
• Feature flags: Configuration values that change script behavior.
• Authentication tokens: Service account tokens or access keys.

Configuring environment variables

Importing from .env files

You can paste .env file content directly into any field in the add form. Sazabi detects the format and imports multiple variables at once.

# Paste content like this into any key or value field
DATABASE_URL=postgresql://user:pass@host/db
API_KEY=sk-live-abc123
FEATURE_FLAGS={"beta": true}

The parser handles quoted values, comments, and multiline content.

Key naming rules

Environment variable keys must follow these conventions:

Keys are case-sensitive. API_KEY and api_key are treated as different variables.

How variables are used

In sandbox code

The assistant can read environment variables in any code it runs. Variables are available through standard language APIs:

import os

api_key = os.environ.get("API_KEY")
db_url = os.environ.get("DATABASE_URL")

const apiKey = process.env.API_KEY;
const dbUrl = process.env.DATABASE_URL;

echo $API_KEY
curl -H "Authorization: Bearer $API_KEY" https://api.example.com

In init scripts

Environment variables are available during init script execution. Use them to configure tools or authentication during sandbox setup:

# Configure a CLI tool with credentials from environment variables
echo "export API_KEY=$API_KEY" >> ~/.bashrc
company-cli configure --token $SERVICE_TOKEN

Variable scoping

Environment variables are configured at the project level. All sandboxes created for a project share the same environment variable configuration.

Precedence and merging

When you add new variables, they merge with existing ones:

• New keys: Added to the configuration.
• Existing keys: Updated with the new value.
• Unlisted keys: Remain unchanged.

This means you can add variables incrementally without affecting existing configuration.

Security considerations

Storage

• Values are encrypted at rest using application-level encryption.
• Values are decrypted only when provisioning a sandbox.
• The encryption key is managed separately from the database.

Access

• Only project members can view or modify environment variables.
• Values are masked in the dashboard UI by default.
• Variables are not logged or captured in conversation history.

Best practices

Use read-only credentials: When connecting to databases or APIs, use credentials with minimal permissions. Investigation scripts should observe, not modify.

Rotate credentials regularly: If a variable contains a secret, rotate it periodically and update the configuration.

Avoid production write access: Use staging environments or read-only replicas when possible. The sandbox should not be able to modify production data.

Scope credentials narrowly: Use service accounts or API keys with limited scope rather than personal credentials or admin tokens.

Common use cases

Database access

Provide read-only database credentials so the assistant can query your data directly:

DATABASE_URL=postgresql://readonly:password@db.example.com/production

Internal API access

Enable access to internal services for deeper investigation:

INTERNAL_API_URL=https://api.internal.example.com
INTERNAL_API_KEY=key-abc123

Third-party service credentials

Let the assistant query external services that might have relevant data:

DATADOG_API_KEY=your-api-key
DATADOG_APP_KEY=your-app-key
PAGERDUTY_TOKEN=your-token

Feature configuration

Control script behavior with configuration values:

DEFAULT_REGION=us-west-2
LOG_LEVEL=debug
MAX_QUERY_ROWS=1000

Troubleshooting

Variables not available in sandbox

If environment variables are not accessible:

1. Check timing: Variables are loaded when the sandbox is created. If you update variables, new threads will use the updated values, but existing sandboxes keep their original configuration.

2. Verify key names: Keys are case-sensitive. API_KEY and api_key are different variables.

3. Check for typos: Review the key name in both the settings and your code.

Variables not available in init script

If variables are not accessible during init script execution:

1. Source bashrc if needed: Some environment variable mechanisms require sourcing the shell configuration:

   source ~/.bashrc
   echo $MY_VAR
   

2. Check execution order: Variables are set before the init script runs, but the script runs as root in a fresh shell.

Import parsing issues

If .env paste import fails to parse correctly:

1. Check format: Lines should be KEY=value with no spaces around =.
2. Remove comments inline: Use # comments on their own lines.
3. Quote complex values: Wrap values with special characters in quotes.