What the data for this category looks like
The data for this category primarily comes from CRM systems, contract order databases, identity management systems, and product backends. Daily produced documents include customer provisioning application forms, tenant configuration sheets, administrator account lists, and delivery confirmation forms. Data is updated per order or once daily. Fields include customer unique identifier, tenant exclusive identifier, permission configuration scope, administrator account list, provisioning status, and more. All data flows through the full process from customer application to completed tenant initialization, and only covers the single customer tenant scope currently being delivered, and does not involve cross-tenant general configuration data.
What constraints these characteristics impose on the deployment and upgrade phase
The data sources for this category are scattered. During deployment, interfaces from multiple systems must be connected to ensure that customer information and administrator accounts can be automatically synchronized from CRM and identity management systems, avoiding configuration errors caused by manual entry. The data update frequency is per order or once daily. The post-deployment upgrade process must support incremental updates, and cannot fully overwrite the configurations of already provisioned tenants, as this will disrupt normal use of active tenants. Document fields are fixed. Configuration items during deployment must strictly match the fields in the provisioning application form and tenant configuration sheet, otherwise the provisioning process will stall or data misalignment will occur. The core time-consuming links of this category are customer information verification, permission initialization, and provisioning result confirmation. During deployment, automatic synchronization tools must be configured to reduce manual operation costs. In addition, errors in this category will directly affect customer login and delivery acceptance. Multiple layers of verification logic must be added during the deployment phase to ensure that the data fields corresponding to each configuration item are complete and valid.
How to set the configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
DB_MAX_LINK | 100–150 connections | Matches concurrent database connection requests during tenant initialization, preventing connection pool exhaustion |
MONGODB_URI | Customer tenant-specific database connection address | Ensures isolated storage of initialization data for each tenant, complying with data flow requirements |
PG_URL | Calibrated based on actual testing | Supports structured storage requirements for administrator account lists and delivery confirmation forms |
REDIS_URL | redis://:{password}@{address}:{port}/0 | Caches tenant permission verification data, reducing latency from repeated queries |
FE_DOMAIN | Frontend access domain name for the customer tenant | Ensures that the administrator login redirect address matches the customer-side configuration |
ROOT_KEY | Generated using the preset key from the delivery confirmation form | Used for initializing super administrator permission configurations for tenants |
Three common mistakes
- The symptom is inability to access the oneAPI management page after local deployment, with the interface returning a 404 status code. The cause is that the
FE_DOMAINparameter was not configured correctly, resulting in a mismatch between the frontend route and the backend service address. - The symptom is a configuration error prompt after adding a third-party model, and the API key cannot be saved. The cause is that the
FILE_TOKEN_KEYparameter was not bound in the configuration items of the corresponding tenant, causing the key storage verification to fail. - The symptom is a prompt that the number of collaborators has exceeded the limit after tenant provisioning, and members cannot be added. The cause is that the permission threshold was not adjusted based on the number of collaborators configured in the customer’s contract order, causing the system verification to fail.
How to confirm that the configuration is correct
- Run the deployment startup command for FastGPT v4.17.0, and check that the connection status of
MONGODB_URI,PG_URL, andREDIS_URLin the console logs all show normal. - Log in to the tenant administrator backend, try to add a test administrator account, and confirm that the account can log in normally and the permission scope matches the requirements of the tenant configuration sheet.
- Submit a simulated provisioning application form, and check whether the fields in the tenant configuration sheet are automatically filled in completely after the system automatically synchronizes customer information.
- Trigger an upgrade process, and confirm that the configurations of already provisioned tenants have not been accidentally overwritten, and the initialization process for new tenants can execute normally.
The values provided are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.