> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getgriffinapp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Secrets

> Keep sensitive values out of your monitor files

Use `secret()` to reference sensitive values like API keys and tokens in your monitors. Secrets are resolved at runtime by the executor — the actual values never appear in your monitor files or monitor definitions stored in the hub.

## Using secrets

```typescript theme={null}
import { secret } from "@griffin-app/griffin";

builder.request("authenticated-call", {
  method: GET,
  base: "https://api.example.com",
  response_format: Json,
  path: "/protected",
  headers: {
    "Authorization": secret("API_KEY"),
    "X-API-Token": secret("SERVICE_TOKEN"),
  },
})
```

The `secret()` function accepts a name (alphanumeric and underscores, must start with a letter or underscore):

```typescript theme={null}
secret("API_KEY")                              // Simple reference
secret("DB_CREDENTIALS", { field: "password" }) // Extract a field from a JSON secret
secret("API_KEY", { version: "2" })             // Pin to a specific version
```

## Managing secrets with the CLI

Secrets are stored per-environment on the hub:

```bash theme={null}
# Set a secret (prompts for value)
griffin secrets set API_KEY

# Set with a specific value
griffin secrets set API_KEY --value "sk-1234..." --env production

# List secrets (names only — values are never shown)
griffin secrets list --env production

# View secret metadata
griffin secrets get API_KEY --env production

# Delete a secret
griffin secrets delete API_KEY --env production
```

## Secret providers

The hub resolves secrets using configurable providers. The provider determines where secret values are stored.

### Environment variables (default)

The simplest provider. Secrets are resolved from environment variables on the hub or executor process.

```bash theme={null}
# On the hub/executor machine
export API_KEY="sk-1234..."
```

### AWS Secrets Manager

Store secrets in AWS Secrets Manager for production workloads.

Hub configuration:

```bash theme={null}
SECRET_PROVIDER=aws
AWS_SECRETS_PREFIX=griffin/          # Optional prefix for secret names
AWS_SECRETS_ROLE_ARN=arn:aws:iam::123:role/griffin  # Optional cross-account role
```

### HashiCorp Vault

Store secrets in Vault for enterprise environments.

Hub configuration:

```bash theme={null}
SECRET_PROVIDER=vault
VAULT_ADDR=https://vault.example.com
VAULT_TOKEN=hvs.your-token
```

## Best practices

* **Never hardcode secrets** in monitor files — always use `secret()`
* **Use different secrets per environment** — staging and production should have separate credentials
* **Rotate secrets regularly** — update via the CLI or your secret provider's rotation mechanism
* **Use descriptive names** — `STRIPE_API_KEY` is better than `KEY1`