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

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, the driver stores all uploads inside the same bucket for both public and private files. This bucket must allow public access and enable object-level ACLs, letting the driver selectively set objects as public or private. If these options are restricted in your environment, you can configure two separate buckets for public/private objects:
  1. Both buckets can maintain default settings (which prohibit public access and disable object-level ACLs)
  2. The public bucket could be served through a CDN allowed to access all objects (or any more restrictive pattern you prefer)
In this setup, UPLOADS_STORAGE_S3_* variables configure the private bucket, while UPLOADS_PUBLIC_STORAGE_S3_* variables configure the “public” bucket (i.e dedicated to public assets, but not necessarily public itself). You can provide separate credentials for the public bucket or simply set these two variables to use the same credentials:
Equivalent variables exist for GCS :
To avoid public buckets / CDN, you can force all file download requests to go through the Prisme.ai API by not providing the UPLOADS_STORAGE_*_BASE_URL environment variable.

Authentication & Security

OIDC Configuration

Session & Token Configuration

Security Settings

Service-Specific Configuration

API Gateway

Console

None of *_ENDPOINT, *_WEBHOOK or *_OVERRIDE should be configured if the generic WORKSPACE_OPS_MANAGER environment variable is set (recommended). In helm, it can be tuned from prismeai-console.workspace_ops_manager and prismeai-pages.workspace_ops_manager environment variables.

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

Integration & APIs

Examples

S3 Storage Configuration

Authentication and Rate Limiting for Production