Skip to main content

Overview

The Runlayer platform supports automatic fetching of Sentry Relay credentials from WorkOS Vault for both EKS (Helm) and ECS (Terraform) deployments. This eliminates the need to manually manage relay credentials and ensures they are securely retrieved at deployment time. Deployment Methods:
  • EKS/Helm: Uses an init container to fetch credentials on pod startup
  • ECS/Terraform: Uses Terraform’s external data source to fetch credentials during deployment

How It Works

EKS/Helm Deployments

When relay.vault.enabled is set to true, an init container runs before the Sentry Relay starts:
  1. The init container executes the fetch script from a ConfigMap
  2. The script fetches relay credentials from WorkOS Vault using the AUTH_API_KEY from backend secrets
  3. Credentials are written as credentials.json and config.yml to a shared in-memory volume (emptyDir at /.relay)
  4. The main relay container starts with --config /.relay flag to read the fetched credentials
  5. Relay processes telemetry events with the fetched credentials
If credentials are not available in the vault, the init container gracefully exits after writing a minimal config file, allowing the relay to start successfully but remain non-functional until credentials are provisioned.

ECS/Terraform Deployments

Terraform uses an external data source to fetch credentials during the deployment:
  1. Terraform calls the vault-fetch-relay.sh script as an external data source
  2. The script fetches credentials from WorkOS Vault and returns them as JSON
  3. Terraform creates ECS task definition environment variables with the credentials
  4. ECS tasks start with the credentials already configured
If credentials are not available, Terraform receives empty values and deploys without Sentry Relay functionality.

Prerequisites

1. WorkOS Vault Setup (Both EKS and ECS)

Ensure your Sentry Relay credentials are stored in WorkOS Vault with the following structure: Secret Name: runlayer-sentry-credentials Secret Value (JSON):
The sentry_dsn field is optional and can be overridden per environment via the backend.secrets.SENTRY_DSN value (EKS) or Terraform variables (ECS).

2. Provide WorkOS API Key

Ensure your backend.secrets.AUTH_API_KEY is set in your Helm values:
The relay init container will automatically use this API key to fetch credentials from WorkOS Vault.
Keep your WorkOS API key secure. This key has access to your vault secrets.

Configuration

EKS/Helm Configuration

In your Helm values file, configure the vault integration:

Deploy with Vault Integration

The init container will automatically run before each relay pod starts and fetch credentials.

How the Init Container Works

When a relay pod starts with relay.vault.enabled: true:
  1. ConfigMap Creation: Helm creates a ConfigMap named <release-name>-relay-fetch-script containing the fetch script
  2. Init Container Starts: The init container mounts:
    • The ConfigMap at /scripts/fetch-relay-credentials.sh (read-only)
    • An empty memory volume at /.relay (read-write)
    • The backend-secret to read AUTH_API_KEY
  3. Credential Fetch: The init container executes the script which:
    • Installs curl, jq, and ca-certificates in the Alpine container
    • Fetches credentials from WorkOS Vault using the API key
    • On success: Writes credentials.json and config.yml to /.relay
    • On failure: Writes minimal config.yml only (prevents relay crashes)
  4. Main Container Starts: After the init container completes:
    • The relay container mounts /.relay as read-only
    • Relay starts with --config /.relay flag
    • Relay reads credentials and begins processing events

ECS/Terraform Configuration

In your Terraform configuration, the vault integration is automatic when you provide the WorkOS API key:
Customization via Environment Variables: You can customize the vault fetch behavior by setting environment variables before running Terraform:

Graceful Degradation

EKS/Helm

If credentials are not available in WorkOS Vault:
  • The init container exits successfully (exit code 0)
  • A minimal config.yml is written to the shared volume (prevents relay crashes)
  • No credentials are written (relay starts but remains non-functional)
  • Relay pods start successfully but cannot process telemetry
  • The backend continues to work without Sentry telemetry

ECS/Terraform

If credentials are not available in WorkOS Vault:
  • The external data source returns empty values
  • Terraform creates the task definition with empty credential environment variables
  • ECS tasks start but relay remains non-functional
  • The backend continues to work without Sentry telemetry
This allows deployments to proceed even when Sentry credentials are not yet provisioned.

Security Considerations

Credential Storage

When relay.vault.enabled is true:
  • The fetch script is stored in a ConfigMap and mounted into the init container
  • Credentials are fetched by an init container on each pod start
  • Credentials are written as credentials.json and config.yml to /.relay directory
  • The /.relay directory is an in-memory emptyDir volume (never written to disk, 1Mi size limit)
  • The volume is shared only between the init container and relay container (read-only for relay)
  • Credentials are automatically cleared when the pod terminates
  • No RBAC permissions required - init container only writes to local volume

Network Access

The init container needs network access to reach the WorkOS Vault API at https://api.workos.com. Ensure your cluster’s network policies allow outbound HTTPS traffic.

Troubleshooting

Check Init Container Status

Common Issues

Init Container Fails with “WORKOS_API_KEY not found”Ensure AUTH_API_KEY is set in your backend.secrets:
Relay Pod Starts but Relay is Non-FunctionalCheck the init container logs to see if credentials were fetched:
If you see warnings about missing credentials, they may not be available in WorkOS Vault.
Credentials Not Found in Vault (Both) Contact Runlayer support to provision relay credentials for your deployment.

Configuration Reference

EKS/Helm Vault Settings

Note: When relay.vault.enabled is true:
  • The init container mounts a ConfigMap containing the fetch script at /scripts/fetch-relay-credentials.sh
  • Credentials are written to /.relay directory (in-memory emptyDir volume)
  • The relay container uses --config /.relay flag to load credentials on startup
  • The sentry-relay-secret Kubernetes secret is not created (vault takes precedence)

ECS/Terraform Environment Variables

The vault-fetch-relay.sh script supports the following environment variables: Usage:

Script Locations

Script Differences:
  • ECS script: Reads API key from stdin (JSON), outputs credentials to stdout (JSON), uses curl with retry logic
  • EKS init container script: Reads API key from environment variables, writes credentials to files (credentials.json and config.yml), uses curl with retry logic
  • EKS external script: Calls the ECS script internally, converts JSON output to Helm values file format
The external Helm script (scripts/helm-fetch-vault-credentials.sh) uses the ECS script internally to avoid code duplication, then transforms the JSON output into a Helm values YAML file.