This configuration applies to FastGPT v4.17.0.
What the data for this category looks like
The data for this category covers the full lifecycle of personal information processing that identifies natural persons. Typical sources include business system operation logs, app permission lists, official privacy policy texts, and user request records. Daily generated documents include personal information inventories, processing rules, impact assessment reports, and user authorization agreements. Data is updated quarterly or each time product functions are modified. Data fields include information type, processing purpose, legal basis, storage duration, and other items. There is no unified fixed format, so adjustments must be made flexibly based on business scenarios. Errors may result in complaints, administrative penalties, or removal for rectification. The key difference from other data security categories is the focus on end-to-end compliance verification for natural person information.
What constraints these characteristics impose on the deployment and upgrade phase
Because data sources are scattered and formats vary widely, the deployment phase must support custom multi-source data import and field mapping configurations. This avoids hardcoding to adapt to compliance document structures across different businesses. Data update frequency shifts with product changes. The upgrade phase must support migration of legacy compliance tickets and documents, preventing historical data from becoming invalid. Given the severe consequences of errors in compliance scenarios, an additional verification step must be added during deployment. This blocks import of sensitive non-compliant formatted data. Additionally, compliance-related tickets and documents must be stored separately. During deployment, clear boundaries must be established between storage resources for compliance data and other business data.
How to Configure the Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
MONGODB_URI | mongodb://[compliance database username]:[compliance database password]@[database host]:[port]/fastgpt_compliance?authSource=admin | Stores sensitive data such as compliance tickets and personal information inventories. Requires a dedicated database and authentication source to isolate from regular business data |
REDIS_URL | redis://:[cache password]@[cache host]:[port]/1 | Caches intermediate results of compliance verification and ticket session information. Uses an independent database number to avoid confusion with business caches |
DB_MAX_LINK | 80–120 | Concurrent queries for tickets and documents are high in compliance scenarios. Adapts the connection pool upper limit to avoid connection exhaustion |
STORAGE_S3_ENDPOINT | Fill in the endpoint address provided by the compliance storage service provider | Stores sensitive documents such as user authorization agreements and impact assessment reports. Must use object storage services that meet compliance requirements |
FILE_TOKEN_KEY | Custom random string with a length of no less than 32 characters | Generates file access tokens. Used to securely pass parameters of compliance-related files uploaded by users. Prevents unauthorized access |
Three Common Misconfigurations
- After adding a custom compliance plugin to a workflow, input and output parameters do not appear in the node, and no error logs are generated. This occurs because the plugin has not been granted call permissions for compliance scenarios in the permission configuration corresponding to
ROOT_KEY, preventing the front end from loading the plugin setup. - When using the HTTP module to send compliance-related files uploaded by users to an external processing end, complete file parameters cannot be obtained. This occurs because
FILE_TOKEN_KEYwas not configured correctly, causing the file access token to expire or be invalid and making it impossible to read file content. - After deployment, the compliance ticket page crashes frequently, and data cannot be loaded after refresh. This occurs because
DB_MAX_LINKis set too low. Concurrent queries for compliance documents exhaust the database connection pool, triggering service exceptions.
How to Verify the Configuration is Complete
- Log in to the front-end console, go to the system configuration page, check the connection status of
MONGODB_URIandREDIS_URL, and confirm whether a normal connection prompt is displayed. - Upload a personal information inventory document, trigger the compliance verification process, and confirm that intermediate results have been normally written to Redis through cache monitoring.
- Call the custom compliance plugin, check whether the input and output parameters of the workflow node load normally, and confirm that the plugin permission configuration takes effect.
- Simulate multiple concurrent ticket query requests, confirm through system monitoring that the database connection count does not exceed the
DB_MAX_LINKconfiguration value, and that no service crashes or timeouts occur.
The values listed here are common starting points. They should be evaluated against samples appropriate for the target deployment.
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.