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, 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:
- Both buckets can maintain default settings (which prohibit public access and disable object-level ACLs)
- The public bucket could be served through a CDN allowed to access all objects (or any more restrictive pattern you prefer)
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:
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:{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.