Skip to main content
Prisme.ai services can be configured through various environment variables. This reference provides a comprehensive list of available configuration options for your deployment.

Configuration Methods

Docker Setup

In a Docker deployment, configure these variables in the root docker-compose.yml file. See the Docker Compose documentation for more details.

Developer Setup

In a development environment, create a services/*/.env file containing key/value pairs:
To run a service directly from its Docker image, add an env_file option to its services/*/docker-compose.yml file:
Note 1: Default values may differ depending on the selected start mode (Docker or Developer), especially URL-related variables. Note 2: Relative paths start from the executing service directory.

Variable Categories

Domains & URLs

Configure the URLs and domains used by Prisme.ai services.

Databases & Storage

Redis Configuration

MongoDB/PostgreSQL Configuration

Elasticsearch Configuration

Storage Configuration

Prisme.ai supports multiple storage backends for workspaces and uploads. Available storage types are:
  • FILESYSTEM: Local file system storage
  • S3_LIKE: Amazon S3 or compatible services (MinIO, etc.)
  • AZURE_BLOB: Azure Blob Storage
  • GCS : Google Cloud Storage

Workspaces Storage

Do not use FILESYSTEM for workspaces models in production. Filesystem writes are not atomic, so concurrent writes to the same workspace (multiple runtime / workspaces replicas, or an RWX volume shared across pods) can interleave and leave corrupted model YAML files. Use an object storage backend (S3_LIKE, AZURE_BLOB or GCS) instead, which writes each object atomically. Reserve FILESYSTEM for local development or single-replica evaluation setups.

S3-Compatible Storage for Workspaces

Azure Blob Storage for Workspaces

GCS Storage for Workspaces

If WORKSPACES_STORAGE_GCS_KEYFILEPATH or GOOGLE_APPLICATION_CREDENTIALS is provided, only WORKSPACES_STORAGE_GCS_BUCKET is required.

File Uploads Storage

S3-Compatible Storage for uploads

Azure Blob Storage for uploads

GCS Storage for uploads

If UPLOADS_STORAGE_GCS_KEYFILEPATH or GOOGLE_APPLICATION_CREDENTIALS is provided, only UPLOADS_STORAGE_GCS_BUCKET is required. Notes on uploads bucket: By default, a single private bucket holds both public and private uploads. Every download is proxied by the api-gateway, which checks the file’s visibility and serves public files without requiring authentication. No CDN, no public bucket, and no object-level ACLs are required. The default applies as long as UPLOADS_STORAGE_*_BASE_URL is left unset. If you want public files to be served directly from a CDN instead of through the api-gateway, you can opt into a two-bucket setup:
  1. Keep the private bucket as-is (UPLOADS_STORAGE_S3_*).
  2. Add a second bucket dedicated to public assets (UPLOADS_PUBLIC_STORAGE_S3_*), exposed through a CDN.
  3. Set UPLOADS_STORAGE_S3_LIKE_BASE_URL (and/or UPLOADS_PUBLIC_STORAGE_S3_LIKE_BASE_URL) to the CDN’s public base URL — that is what tells the platform to hand out direct CDN URLs instead of proxying through the api-gateway.
You can reuse the same credentials for both buckets or provide separate ones:
Equivalent variables exist for GCS:
To switch back to “everything through the api-gateway”, simply unset the UPLOADS_STORAGE_*_BASE_URL variables.

Authentication & Security

OIDC Configuration

Session & Token Configuration

Security Settings

Service-Specific Configuration

API Gateway

Console

Events Service

Runtime Service

Workspaces Service

Platform Repositories

Platform repositories are shared repositories automatically available to all workspaces for versioning (push/pull). They are configured entirely through environment variables and require no per-workspace setup. Each workspace’s files are stored in a subdirectory named after the workspace slug within the repository. This allows a single repository to serve as a centralized versioning backend for every workspace on the platform. Multiple platform repositories can be configured by using the following naming convention:
Where {repoId} is a unique identifier for the repository (e.g., prismeai, backup) and {FIELD} is one of the supported fields listed below.
The filesystem type is reserved for platform repositories and cannot be used in workspace-level repository configurations.
Example — single platform Git repository:
Example — filesystem platform repository (like the one embedded in prismeai-workspaces Docker image):
With this configuration, the platform expects workspace directories directly inside /www/platform-workspaces/ (e.g., /www/platform-workspaces/ai-knowledge/, etc.). Example — with a custom directory path (Git):
With this configuration, a workspace with slug myapp would be stored under workspaces/myapp/ in the repository. Example — multiple platform repositories:
Notes:
  • Platform repositories are returned in the platformRepositories field of the workspace API response — they do not include auth details, and are never persisted into the workspace configuration.
  • Authentication credentials are never exposed in API responses.
  • For GitHub HTTPS authentication, use your username as AUTH_USER and a personal access token (PAT) with read-write permissions on Contents as AUTH_PASSWORD.

Workspace Groups

Workspace groups define logical sets of workspaces that can be imported together via bulk import. Groups are configured through environment variables:
A workspace belongs to a group if at least one of its labels matches one of the group’s labels. When a workspace is pushed to a platform repository, the groups it belongs to are recorded in its .import.yml file. Example:
These group names are then used in:
  • The bulk import API (groups body parameter): POST /v2/workspaces/platform/versions/latest/pull
  • The bulk push API (groups body parameter): POST /v2/workspaces/platform/versions
  • STARTUP_IMPORT_GROUPS to select which workspaces to import automatically on startup

Automatic Import at Startup

The workspaces service can automatically trigger a bulk import when it starts. This is useful for initial deployments and platform upgrades, ensuring that reference workspaces from a platform repository are always up to date. Example:
At startup, the service:
  1. Ensures the platform workspace exists (creates it if needed)
  2. Waits for the platform to be ready (checks the /v2/readiness endpoint, with a 5-minute timeout)
  3. Imports each group sequentially using the bulk import mechanism, with a 30s pause between each group
  4. Skips workspaces already at the correct version (based on .import.yml version matching)
When multiple replicas start simultaneously (e.g., during a rollout), only one replica acquires the write lock on the Platform workspace and performs the import. Other replicas skip the import entirely.

Performance & Limits

Rate Limiting

The variables below are the api-gateway-side rate limits: requests above the threshold are rejected with HTTP 429. For automation rate limits (also RATE_LIMIT_* but on prismeai-runtime), see API Reference — Rate Limits. Unlike the gateway limits, those don’t break execution — they deliberately slow automations down instead of failing them.

Integration & APIs

Examples

S3 Storage Configuration

Authentication and Rate Limiting for Production