This document is written based on FastGPT v4.17.0.
What the data for this category looks like
Data for this category comes from formula and process libraries, raw material batches, reactor DCS systems, weighing systems, LIMS, and warehouse systems. Updates are triggered per production batch or each critical step. Daily documents include batch production instructions, feeding verification slips, reaction process records, cleaning records, inspection reports, deviation and change orders. Fields cover feeding parameters, reaction temperature, cleaning verification results, batch numbers, and more. There are no universal standard units, so native field formats of each system must be matched. The characteristic of switching between multiple product varieties by batch requires data to be linked to the entire single-batch production process. Access permission isolation for formula-related documents must also be ensured.
What constraints do these characteristics impose on deployment and upgrade
This category’s data is scattered across multiple systems. During deployment, permission configurations for multi-source data docking must be adapted to avoid synchronization failures caused by incompatible cross-system field formats. High-frequency updates triggered per batch require near-real-time data synchronization mechanisms to be configured during deployment. Full offline synchronization is not recommended. The business characteristic of switching between multiple product varieties by batch requires single sessions to be bound to single-batch production contexts during deployment. This avoids cross-batch data mixing. Compliance requirements for formula confidentiality and cleaning verification require presetting permission isolation rules during deployment. During upgrades, production data synchronization must be maintained without interruption. This avoids impacting ongoing batch production processes.
How to set the configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
REDIS_URL | redis://:custom password@redis service address:6379/0 | Stores session context and temporary synchronization markers, adapts to high-frequency data caching requirements for single-batch production |
MONGODB_URI | mongodb://username:custom password@mongodb service address:27017/fastgpt?authSource=admin | Stores batch production documents and equipment inspection records. authSource ensures valid permission verification |
DB_MAX_LINK | 50–80 connections | Matches high-frequency data read/write volumes for single-batch production, avoids connection pool exhaustion |
FE_DOMAIN | https://enterprise-specific inspection service domain | Configures valid domains for frontend access, ensures correct permission verification and callback links |
ROOT_KEY | Cryptographically secure random string generated per enterprise internal permission rules | Controls global platform permissions, prevents unauthorized access to sensitive formula and production data |
STORAGE_S3_ENDPOINT | http://enterprise internal object storage address:9000 | Stores large files such as cleaning records and inspection reports, adapts to enterprise internal storage architectures |
Three common mistakes
- Symptom: After a Docker container starts, it always listens on port 3000, and the listening port cannot be modified via the configuration file. Cause: The default FastGPT port configuration was not properly overridden, and container network mapping rules were not adjusted for multi-system docking requirements.
- Symptom: Field mismatch errors occur when batch importing batch production documents. Cause: The exclusive field formats for batch fine chemical synthesis were not adapted, a generic import template was used directly, and the document structure for categories such as feeding verification slips and reaction process records was not associated.
- Symptom: Multiple sets of API keys cannot be configured to isolate model combinations. Cause: Environment variables for multiple keys were not properly configured in docker-compose.yml, and configuration items were not adjusted to meet the requirement of managing one set of model combinations per key.
How to confirm the configuration is correct
- The
docker pscommand is executed to check if the container port mapping matches the access port configured inFE_DOMAIN. - A single batch’s feeding verification slip and reaction process record are imported, and the data is verified to display normally in the retrieval interface after synchronization.
- Multiple sets of API keys are attempted to be configured, and different keys are verified to bind to specified model combinations.
- A key other than
ROOT_KEYis used to access the platform backend, and confirmation is made that sensitive data cannot be accessed without authorization.
The values provided here are common starting points, and should be evaluated against the reader’s own samples.