Skip to main content
When Self-Hosting, you configure Corgtex using environment variables (typically stored in a .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 and client instances should use Redis for shared short-lived state. Postgres remains the permanent source of truth. 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:

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 expose APP_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 is https://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.

Example .env File