What Data for This Category Includes
Core data sources for this category include package managers, code repositories, public vulnerability databases, and license databases. Standardized documents produced regularly include SBOM lists, dependency risk reports, license lists, and repair work orders. Fields covered include third-party dependency package names, version numbers, associated vulnerability IDs, license types, risk ratings, and repair statuses. Data updates occur daily or when each software version is released. Core data items use standard package management and general security rating dimensions, with no custom special units.
Constraints for Deployment and Upgrade Workflows
Data sources are scattered and update frequently. Ensure stable connections to multiple external data sources during deployment to avoid dependency identification interruptions from configuration errors. Multiple daily produced document types require accompanying storage and indexing configurations, otherwise risk reports and repair work orders cannot be retrieved quickly. High computational load in dependency asset identification and vulnerability matching steps requires reasonable database connection pool parameter configuration during deployment, to prevent service blocking due to insufficient resources after upgrade. In scenarios of unexpected power outages or restarts, ensure persistent storage is mounted correctly to avoid service startup failure caused by invalid database connection configurations.
Configuration Settings
All following configuration items are compatible with FastGPT v4.17.0:
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
DB_MAX_LINK | 100–200 | Supports concurrent requests for dependency identification and vulnerability matching, prevents service lag caused by exhausted connections |
MONGODB_URI | Fill in the actual deployed MongoDB instance address, including authentication information | Stores unstructured business data such as SBOM lists and risk reports, ensures data persistence and retrievability |
PG_URL | Fill in the actual deployed PostgreSQL instance address, including authentication information | Stores structured business data such as dependency package metadata and repair work orders, supports efficient queries and statistics |
STORAGE_S3_ENDPOINT | Fill in the endpoint for self-built or cloud service provider object storage | Stores documents and log files generated by scans, supports shared access in multi-node deployments |
REDIS_URL | Fill in the actual deployed Redis instance address, including authentication information | Caches dependency matching results and temporary scan tasks, improves response speed for batch processing |
ROOT_KEY | Generate a random string of 32 or more characters per security requirements | Used for system administrator permission verification, prevents unauthorized access to deployment configurations and core data |
Three Common Misconfigurations
- Symptoms include failure to create new users after deployment via Docker Compose, with interface prompts of insufficient permissions or API returning 403 status code. The cause is incorrect configuration of the
ROOT_KEYparameter, or failure to enable the administrator registration process, resulting in regular users being unable to obtain registration permissions. - Symptoms include failure to start PostgreSQL or MongoDB services after an unexpected power outage and restart, with logs showing connection refused or permission errors. The cause is failure to mount the database data directory to a persistent storage volume during deployment, resulting in loss of locally cached configurations and data due to power outage.
- Symptoms include partial requests remaining in a loading state with no response when more than 7 concurrent user requests are initiated. The cause is an excessively low
DB_MAX_LINKconfiguration value, which cannot support concurrent dependency scanning and data query requests.
How to Verify Successful Configuration
- Run service status check commands to confirm that databases, Redis, and core FastGPT services are all running normally, with no abnormal exit logs.
- Access the domain specified by the configured
FE_DOMAIN, use the generatedROOT_KEYto complete administrator registration, and verify that permission configurations take effect. - Upload a test dependency list file to trigger a dependency scan task, confirm that generated risk reports and SBOM lists can be viewed in the interface after the task completes.
- Simulate an unexpected restart scenario, restart all deployed services, confirm that database connections function normally with no connection refused errors.
The values provided are common starting points, and should be evaluated 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.