Configuration Methods
Docker Setup
In a Docker deployment, configure these variables in the rootdocker-compose.yml file. See the Docker Compose documentation for more details.
Developer Setup
In a development environment, create aservices/*/.env file containing key/value pairs:
env_file option to its services/*/docker-compose.yml file:
Variable Categories
- Domains & URLs
- Databases & Storage
- Authentication & Security
- Service-Specific Configuration
- Performance & Limits
- Integration & APIs
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, 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:
- Keep the private bucket as-is (
UPLOADS_STORAGE_S3_*). - Add a second bucket dedicated to public assets (
UPLOADS_PUBLIC_STORAGE_S3_*), exposed through a CDN. - Set
UPLOADS_STORAGE_S3_LIKE_BASE_URL(and/orUPLOADS_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.
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:{repoId} is a unique identifier for the repository (e.g., prismeai, backup) and {FIELD} is one of the supported fields listed below.
Example — single platform Git repository:
/www/platform-workspaces/ (e.g., /www/platform-workspaces/ai-knowledge/, etc.).
Example — with a custom directory path (Git):
myapp would be stored under workspaces/myapp/ in the repository.
Example — multiple platform repositories:
- Platform repositories are returned in the
platformRepositoriesfield 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_USERand a personal access token (PAT) with read-write permissions on Contents asAUTH_PASSWORD.
Workspace Groups
Workspace groups define logical sets of workspaces that can be imported together via bulk import. Groups are configured through environment variables:.import.yml file.
Example:
- The bulk import API (
groupsbody parameter):POST /v2/workspaces/platform/versions/latest/pull - The bulk push API (
groupsbody parameter):POST /v2/workspaces/platform/versions STARTUP_IMPORT_GROUPSto 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:
- Ensures the
platformworkspace exists (creates it if needed) - Waits for the platform to be ready (checks the
/v2/readinessendpoint, with a 5-minute timeout) - Imports each group sequentially using the bulk import mechanism, with a 30s pause between each group
- Skips workspaces already at the correct version (based on
.import.ymlversion 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 (alsoRATE_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.