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
With an Azure identity configured, the connection string is ignored (a warning is logged if one is still set) and the identity needs the Storage Blob Data Contributor role on the account. See Microsoft Entra ID passwordless auth.
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
Declaring external OIDC clients (native mobile apps)
Besides the studio, whoseredirect_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:
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.
Example — override with a custom client (keeping the default mobile client too):
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.Bounding silent peers.
FETCH_HEADERS_TIMEOUT and FETCH_BODY_TIMEOUT are inactivity bounds, not total duration caps, so a long streaming completion is never cut off. Their purpose is the opposite case: a host that accepts the connection and then says nothing, which used to hold the calling automation for the full 300s without emitting anything. Authors can tighten a single call with the fetch instruction’s timeout option, see Automations → fetch.WORKER_STREAM_FIRST_CHUNK_TIMEOUT and slow models. When a model takes longer than this to emit its first token, the run now ends on an explicit time-to-first-token error, rather than on the generic “LLM gateway stream returned no data”. Large generations on some providers legitimately exceed 60s to start; raise the variable rather than reading the error as a platform failure.Cancelled executions.
WEBHOOKS_ABORT_ON_CLOSE and EXECUTION_ABORT_GRACE_PERIOD govern how the runtime stops an execution nobody waits for anymore, such as an agent answer the user stopped: the provider request is closed, so its tokens stop being generated and billed. See Automations → Cancelling an execution for what automations see.FETCH_EMIT_REQUEST_EVENT for outbound-traffic auditing. Off by default. When enabled, every fetch instruction emits a runtime.fetch.requested event just before the request is dispatched — so a call that hangs, times out or crashes still leaves a trace of the URL it targeted. The payload carries request metadata only (method, URL, header names, content-type, body size) and never any request body nor any header value, so it is safe to persist and search. Failures are still reported separately by runtime.fetch.failed. Intra-platform workspace→workspace calls (webhook direct calls) are not audited. Platform-wide switch only — it cannot be toggled per fetch.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.
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.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.