Environment Variables

Slasha allows you to securely pass configuration and secrets to your applications at runtime using environment variables.

Application Environment Variables

You can define custom environment variables for your application either through the Settings tab in the Slasha Web Dashboard, or by using the CLI. For a detailed guide on managing environment variables via your terminal, refer to the CLI Env Reference.

Variable Interpolation

Slasha supports powerful variable interpolation syntax, allowing you to dynamically construct values from other variables at deployment time using the ${{ VAR_NAME }} syntax.

For example, if you have already set a base configuration variable, you can reference it to build another variable:

# Set a base domain variable
slasha env set my-app API_BASE_DOMAIN=api.example.com

# Interpolate API_BASE_DOMAIN to construct a full endpoint URL
slasha env set my-app API_ENDPOINT=https://${{ API_BASE_DOMAIN }}/v1

You can reference any of your custom application environment variables, platform-injected variables, system variables, or attached backing service variables.

System Variables (SLASHA namespace)

You can interpolate platform-level system details into your environment variables using the SLASHA namespace:

  • ${{ SLASHA.data_dir }}: The persistent storage directory path (resolves to /data).
  • ${{ SLASHA.app_slug }}: The URL-safe slug of the application.
  • ${{ SLASHA.app_name }}: The display name of the application.
  • ${{ SLASHA.app_id }}: The unique system identifier of the application.
  • ${{ SLASHA.app_container_name }}: The resolved runtime container name of the application's primary web process.
  • ${{ SLASHA.network_name }}: The internal bridge network name allocated for the application.

Attached Backing Service Variables

You can reference any attached backing service (such as PostgreSQL, MySQL, MongoDB, or Redis) using the service's display name as the namespace. This is extremely useful for building custom URLs or configuring service integrations:

  • Hostname / Container Name: Reference the internal network hostname using ${{ <service_name>.service_container_name }} (e.g. ${{ db.service_container_name }}).
  • Service Port: Reference the internal port the backing service runs on using ${{ <service_name>.PORT }} (e.g. ${{ db.PORT }}).
  • Service Credentials & URL: Reference any variables exposed by the service kind (e.g. ${{ db.DATABASE_URL }}, ${{ db.POSTGRES_USER }}, or ${{ cache.REDIS_PASSWORD }}).
# Example: Build a custom analytics connection string referencing an attached Redis service named 'cache'
slasha env set my-app ANALYTICS_URL=redis://default:${{ cache.REDIS_PASSWORD }}@${{ cache.service_container_name }}:${{ cache.PORT }}/0

Service Environment Interpolation

Backing services also support variable interpolation in their environment variables. When provisioning a service, you can define custom variables that reference other variables defined on the service using ${{ VAR_NAME }}, or reference platform-level details using the SLASHA namespace:

  • ${{ SLASHA.service_container_name }}: The container name of the service.
  • ${{ SLASHA.service_id }}: The unique system identifier of the service.
  • ${{ SLASHA.service_name }}: The display name of the service.
  • ${{ SLASHA.app_id }}: The unique system identifier of the application the service is attached to.
  • ${{ SLASHA.network_name }}: The internal bridge network name allocated for the application and service.

Platform-Injected Variables

If not explicitly defined in your custom environment variables, Slasha automatically determines and injects the PORT environment variable (defaulting to 8080 or the port specified in your Dockerfile's EXPOSE instruction) so that your application container knows which port to listen on.

Service Environment Variables

When you provision a backing service (PostgreSQL, MySQL, MongoDB, Redis) and associate it with your application, its connection credentials, URLs, and environment variables are not automatically injected into your application's environment. Instead, you must explicitly define application environment variables and reference these service-exposed values using variable interpolation (e.g., DATABASE_URL=${{ db.DATABASE_URL }}).

You can configure custom environment variables on the backing service itself when creating or provisioning it. These custom service variables, along with the standard service credentials and the special injected service_container_name variable, can all be referenced by your application via interpolation.

For the full list of variables exposed per service type, please refer to the Services Reference.

Litestream BackupsServer Configuration