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

Declaring external OIDC clients (native mobile apps)

Besides the studio, whose redirect_uris are web console URLs, the api-gateway also ships a default native client for the Prisme.ai mobile app so it works out of the box — no configuration needed:
Set OIDC_EXTERNAL_CLIENTS to override this default and declare your own public clients — the variable replaces the built-in mobile client entirely, so re-add it if you still need it. The value is a JSON array of oidc-provider client metadata objects. Only client_id and redirect_uris are required; the api-gateway applies defaults so every entry is treated as a public PKCE native client: PKCE is automatically required for these public clients — no extra setting needed.
For a native client, oidc-provider validates the redirect_uris per RFC 8252:
  • Custom URI scheme → must be reverse-domain (the scheme must contain a .). ai.prisme.app://oauth/callback is accepted, prisme://oauth/callback is rejected.
  • https → accepted (universal / claimed link), non-loopback hostname.
  • http → only for loopback addresses (127.0.0.1, [::1]).
An invalid redirect_uri makes the api-gateway fail to boot, so validate the value before deploying.
Example — override with a custom client (keeping the default mobile client too):
The mobile app then drives the flow with PKCE (e.g. ASWebAuthenticationSession(callbackURLScheme: "ai.prisme.app") on iOS). Universal / app links (Apple apple-app-site-association, Android assetlinks.json) are not required for a custom scheme.

Session & Token Configuration

Security Settings

Service-Specific Configuration

API Gateway

Console

Events Service

Runtime Service

FETCH_ALLOW_H2 and LLM streaming. Some corporate egress proxies and TLS-inspecting gateways buffer entire HTTP/1.1 response bodies before forwarding them. This breaks Server-Sent Events from LLM providers: the agent’s answer reaches the browser in one block at the end of generation instead of token by token. HTTP/2 usually traverses those same proxies unbuffered.

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.

Credentials replayed without a user

A run that carries no user cannot read a workspace secret under anyone’s permissions. That matters for connectors: the OAuth token a member deposited when connecting their account is exactly what a nightly synchronisation needs to replay. There is nothing to configure here, and no operator gesture at all. A workspace declares a role in its own security rules, grants it read over a family of its secrets, and its automations take that role on where they need it. See RBAC and secure secrets.
Such a role can read, and overwrite, every credential in the family it names. It is meant to be assumed by an automation and nothing else: granting it to a person, or attaching an API key to it, hands those credentials to whoever holds them. The platform does not prevent it, so treat it as a rule of your own.

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