Skip to main content
While the standard Docker Compose method is perfect for evaluation and small setups, larger enterprises deploying Corgtex often need total data isolation, region-specific hosting, specific seeded configurations, and auditable operator support. For hosted customers, Corgtex uses a customer deployment model. Each real customer receives a dedicated runtime stack with its own web service, worker service, Postgres database, Redis service, object storage, custom domain, and region. Shared multi-tenant deployments are reserved for demos and trials. Corgtex uses three distinct runtime concepts in production:
  • app.corgtex.com is the Corgtex internal dogfood product app.
  • ops.corgtex.com is the dedicated Ops control plane for customer deployment management and support.
  • Customer domains, such as customer.corgtex.com, are customer runtimes.
The internal dogfood app is intentionally a mutable Railway branch deployment for main. Its web and worker services watch the full repository and redeploy on every main-branch commit, including docs-only or workflow-only commits. The production smoke gate must then wait for /api/health on app.corgtex.com to report the merge commit SHA before considering the deployment current.

​
Hosted Customer Deployments

The public Apache-licensed Corgtex repository remains the complete core product. Customer data, customer-specific seed content, private deployment metadata, and operational credentials never live in this public repository. Corgtex operators manage customer deployments through the dedicated Ops control-plane deployment at ops.corgtex.com. The control plane stores operational metadata such as customer slug, region, release image tag, Railway resource IDs, custom domain, health status, and bootstrap status. It does not store raw seed bundle content or provider API tokens.

​
Release images

Hosted customer deployments use immutable release images for the web and worker services. These images are published from tagged releases and pinned by release tag or git SHA. Mutable branch deployments are for internal dogfood and staging only. The control plane records the target release and checks it against /api/health. Operators upgrade customers by selecting the next pinned web and worker image tags, letting Railway redeploy both services, probing health, and auditing the result.

​
Control-plane APIs

The operator UI and internal automation both use the same global-operator domain layer. Internal API routes under /api/admin/customer-deployments can list and provision managed customers, and per-deployment routes can trigger health probes, bootstrap, suspension, and release upgrades. These APIs are active only on the Corgtex Ops deployment and are disabled on the dogfood product app and customer runtimes.

​
Support operations

The Ops deployment also exposes a dedicated /control-plane surface for pilot customer support. Corgtex operators can register an encrypted support connector credential for each customer deployment, inspect live customer state through that connector, and run support operations such as member invites, integration diagnostics, data-feed syncs, document uploads, agent-run inspection, and failed-job repair. Support operations are intentionally first-class records. The control plane stores the operator, customer deployment, action, reason, redacted input summary, status, and result summary. Mutating support actions also write support.* audit entries into the customer deployment. Direct infrastructure or database work remains a break-glass path and should be recorded as a break-glass support note rather than treated as the normal support workflow.

​
Private bootstrap bundles

Customer bootstrap data is delivered through a private signed bundle reference. The customer runtime accepts a one-time internal bootstrap request, verifies that the bearer token hashes to the runtime-configured CORGTEX_CUSTOMER_DEPLOYMENT_BOOTSTRAP_TOKEN_HASH, verifies the request signature and bundle SHA-256 checksum, applies the generic stable-client seed logic, and records only status metadata in the database. The bundle contains configuration and seed content required for that customer. The control plane stores only the bundle URI, checksum, schema version, and status. Runtime secrets remain in the deployment platform or private bundle delivery system, and the bootstrap bearer token is stored only as a hash plus consumed-at metadata in the customer runtime.

​
Configuration-only customization

Hosted v1 supports customization through configuration: feature flags, workspace seed config, policies, branding/copy, connectors, region, domains, and model/provider settings. Customer-specific code forks and dynamic private packages are not part of hosted v1.

​
Configuration Repo Pattern

Customer-owned or self-hosted deployments may later use a private Configuration Repo. That lane is intentionally separate from hosted v1. If used, the private repo must stay thin and contain deployment overlays or bundle references only, not a fork of the core application.

​
Why this pattern works

  • Security: Your specific organizational setup data remains in private storage or private operational systems.
  • Upgradability: Hosted customers run pinned release images, so upgrades can be planned, probed, rolled back, and audited.
  • Isolation: Real customers do not share a database or runtime stack by default. Region-specific customers can be hosted in-region.
  • Agent safety: Public-repo guardrails scan ignored files as well as tracked files, so private seed files cannot safely sit inside the public checkout.