.env file).
Core Application Settings
The variables defined here are strictly required to start the web and worker processes successfully.Build-Time Production Settings
Production web image builds also require stable build metadata. These values are consumed while building the Next.js app and must be supplied by the build system without committing secrets.Initial Seeding Settings
When you launch a fresh Corgtex instance, the database must be seeded with an initial workspace and an administrative user.Model Provider Settings
By default, the platform relies on external Large Language Models to power the Organization Brain and agents. While these are optional at startup, they are recommended for full functionality.Setting
MODEL_PROVIDER allows Corgtex’s internal abstractions to handle the LLM routing without baking a specific vendor dependency into your infrastructure.Performance and Session Coordination
Production instances need a shared state backend across web and worker processes. Redis remains the default. Low-load deployments can explicitly select PostgreSQL to avoid a separate cache service. Durable jobs and sessions continue to use PostgreSQL.
On Railway, add a Redis service in the same project and environment as the app, then set
REDIS_URL on every runtime service that handles requests or jobs, normally web and worker. Use Railway reference variables, for example:
PostgreSQL shared state
Apply the additive migration before selectingSHARED_STATE_BACKEND=postgres. Keep existing deployments on their current backend until a coordinated transition. The PostgreSQL path uses shared transactional rate limits and version counters, encrypted cache payloads, and workspace-bound encrypted pending uploads. Database failure denies security-sensitive requests; it never silently switches to process memory or Redis. PostgreSQL cache invalidation commits with PostgreSQL knowledge-source updates.
The Core/Ops low-load runtime profile requires connection_limit=5&pool_timeout=10 in each application database URL. Qualify total connections and database load including rollout overlap; fewer services does not prove sufficient capacity.
Pending transcript tokens stop working after 20 minutes. This is an application access deadline, not a backup erasure promise: encrypted rows can remain in database backups for the configured retention period, and the long-lived encryption key can decrypt retained ciphertext. Expired pending uploads are swept globally in bounded batches when any workspace stores a new upload. Cleanup is activity-driven; expiration does not schedule a timed database deletion. Evaluate this retention behavior before opting into the PostgreSQL backend.
Pending uploads belong to their workspace and are deleted with it. The opaque rate-limit, cache and version keys are shared runtime state: individual tenant exports omit them and tenant deletion preserves them. Encrypted cache rows remain until expiry cleanup, and hashed version counters persist; backup retention applies to both.
Do not switch a running deployment between backends: that would lose effective rate-limit counters and pending uploads. Fence writers and settle or preserve source state first. Core/Ops migration requires an empty, independently observed source Redis plus a migrated, empty PostgreSQL state schema. Once PostgreSQL state is active, rollback must use a PostgreSQL-capable application image and retain the additive schema. After restoring a backup, remove restored retrieval-cache and pending-upload rows before reopening traffic, and assess rate-limit continuity rather than silently resetting counters.
Demand-based workers
WORKER_EXECUTION_MODE defaults to continuous, preserving the existing combined queue and scheduler loop. Low-load deployments can separate the two responsibilities:
A queue-only deployment needs an independent scheduler; setting its minimum replicas to zero alone would stop scheduled work. Run the same immutable worker image as a one-minute UTC scheduled job. A dedicated one-connection PostgreSQL advisory lock prevents overlapping scheduler executions within the database. A lock skip exits successfully but is not proof that a scheduling cycle ran. Failures and interrupted executions exit nonzero. Include the extra advisory connection and scheduler pool in database capacity planning.
The managed Azure demand profile uses one queue worker at most, Single revision mode, a PostgreSQL demand query every 10 seconds, a 30-second cooldown and internal HTTP wake for release health checks. Due eligible events and jobs wake it, including retries that become due without another insert. Existing event claims and running jobs keep it awake. A stuck claim can therefore keep a worker allocated and needs investigation; do not clear claims merely to reduce cost.
Use a separate scaler database login and a versioned Key Vault connection secret. The create-only
provisionWorkerScalerRole helper in scripts/release/worker-demand.mjs grants only the queue eligibility columns and validates the query under that role. The caller must bind the exact database/server, verify TLS, hold shared database maintenance custody, and preserve credentials through the existing secret store. The helper refuses existing roles and excessive inherited PUBLIC access; it does not rotate credentials or change other roles. Never reuse the application writer credential for the scaler or expose the scaler secret as a container environment variable. Before activation, reread the exact Key Vault secret version: validateWorkerScalerConnection binds its value to the expected Azure hostname, database and dedicated login with sslmode=verify-full; verifyWorkerScalerAccess checks a verified TLS connection, actual role, inherited privileges and demand query. Retain that evidence with the exact secret-version URI. A versioned URI alone does not prove its contents or permissions.
The schema-version-2 Core/Ops activation and update plans opt in through workerDemand; legacy plans retain continuous behavior. Keep the scheduler under the same release custody as web and queue worker. A release must suspend scheduled executions, drain them, and prove the exact new scheduler execution and live worker before resuming scheduling. Do not use another release runner that updates only the worker image: that would leave a stale scheduler writer. The scheduler job has its own bounded resource allocation, so queue-worker memory headroom does not silently double scheduled-job costs.
A successful local test or merged configuration is not evidence of Azure scaling or a monthly cost ceiling. Before production activation, qualify native cold starts, zero-to-work-to-zero, delayed retries, in-flight work, scheduler overlap, scaler failures and release recovery. Measure total allocated time, including startup, cooldown, failed executions and termination; scheduled jobs incur usage even when they find no work. See Azure scale rules and the PostgreSQL scaler contract.
Intercom Support Settings
These variables enable Intercom Messenger and Fin support on hosted Corgtex site/app surfaces. Leave them unset for customer-owned or self-managed runtimes unless that customer explicitly wants Intercom enabled.Corgtex Connector Settings
These variables configure the remote MCP connector used by ChatGPT, Claude, Cursor, and other MCP clients.Azure public URL release contract
Fleet releases derive a canonical origin from each Azure target URL. Before any ACR import or Container App update, both the web and worker apps must exposeAPP_URL, NEXT_PUBLIC_APP_URL, and MEETING_RECORDER_PUBLIC_BASE_URL as that exact origin and MCP_PUBLIC_URL as ${origin}/mcp. Missing values, secret references, origin-only MCP URLs, and URLs for another customer block the release instead of being normalized.
After the Azure update, the release runner repeats the runtime check and verifies the public OAuth protected-resource metadata, authorization-server issuer and endpoints, default scopes, and unauthenticated challenges on /mcp and /api/mcp. A mismatch blocks verified-release recording.
Google Workspace Integration
These variables enable Google Calendar sync and selected-file Google Drive ingestion.
Corgtex requests
https://www.googleapis.com/auth/calendar.readonly for calendar sync and https://www.googleapis.com/auth/drive.file for selected Drive files. Do not add broad Drive scopes unless a separate product requirement and Google verification justification are approved.
Object Storage
File uploads and Brain source downloads use an S3-compatible storage backend. Client instances that allow uploads must configure this for every runtime service that touches uploads, normally web and worker.
On Railway, create or reuse a project bucket, read its S3-compatible credentials with the Railway dashboard or CLI, and set the variables above on web and worker. Do not print access keys or secret keys in logs, PRs, tickets, or support messages.
Hosted Control Plane Settings
These variables are only needed by the dedicated Corgtex Ops control plane or by product/customer runtimes that need to link back to it. The canonical public Ops host ishttps://ops.corgtex.com; raw Railway service URLs are implementation URLs only.
The dedicated Ops control plane exposes operator-only routes for automation. These routes return unavailable outside
CONTROL_PLANE_MODE=true, even if the code is deployed on app.corgtex.com or a customer runtime:
Old UI links under
/control-plane/customers/:deploymentId are kept as compatibility redirects only. New operator links must use /control-plane/deployments/:deploymentId.
Recall recorder credentials
For a single provider workspace, configureRECALL_API_KEY, RECALL_WEBHOOK_SECRET,
and RECALL_REGION in both web and worker runtimes. The webhook URL is
/api/integrations/meeting-recorders/recall/webhook.
For shared hosting with separate Recall accounts, store RECALL_WORKSPACE_BINDINGS_JSON
as a secret in both runtimes. It is a JSON object keyed by Corgtex workspace UUID.
Each entry requires apiKey, webhookSecret, region (for example us-east-1),
and providerWorkspaceId for the corresponding Recall workspace. Keep this object
in the deployment secret store, never in workspace provider settings or source control.
Configure each Recall dashboard webhook to call
/api/integrations/meeting-recorders/recall/<corgtex-workspace-uuid>/webhook on the
public application origin. Use the signing secret for that endpoint and the API key
from the same Recall workspace and region. Subscribe to bot.joining,
bot.in_call_recording, bot.done, bot.fatal, recording.done,
recording.failed, transcript.done, and transcript.failed.
When the map is present, missing workspace entries and unscoped Recall webhooks
fail closed; global Recall credentials are not used as a fallback. Unmatched scoped
callbacks are retried for up to ten minutes while a recording is being published;
permanently unmatched events are then acknowledged with a diagnostic. Deploy support
for scoped routing before enabling the map. Preserve existing provider account
bindings for scheduled bots, and verify callbacks and transcript processing before
removing old endpoints. The enable, smoke and cleanup commands use the same binding
map. A scoped cancellation returning 404 is treated as unverified rather than
successful, because an incorrect provider account can also return 404.
Reverting to a release without scoped routing requires
restoring the prior compatible credential and endpoint configuration as well.