Server Resource Specifications
When deploying qOntology, choose a consolidated single-server setup or separate component servers according to your use case, data volume, and budget. The following minimum suggested test configuration and recommended production resource list are intended to support server selection and capacity planning.
Minimum configuration
For functional testing, demonstrations, and trials with small amounts of data. The default Docker Compose stack places Nginx, qOntology API, MySQL, Redis, Neo4j, and kkFileView together on one server.
This is a minimum suggested starting point for a test environment, not a load-tested minimum operating threshold. It excludes local large-model inference and a standalone vector service. AI features use an external model endpoint configured separately.
| No. | Server | Purpose | OS | CPU | Memory | Storage | Quantity |
|---|---|---|---|---|---|---|---|
| 1 | Consolidated qOntology server | Nginx, qOntology API, MySQL, Redis, Neo4j, kkFileView | Ubuntu | 4 vCPU | 16GB | 200GB SSD | 1 |
All services share host resources in this setup. Concurrent batch extraction, graph queries, and file conversion increase demand. Limit task concurrency during testing and monitor total memory and disk usage. With Docker Desktop, check the resources allocated to Docker as well as the host specifications.
Recommended configuration
For routine production planning covering team modeling, graph queries, and a moderate volume of extraction tasks. The following is an example procurement list with separate component servers. AI features use external model endpoints; local GPUs and large-model inference servers are excluded.
CPU, memory, and storage figures are suggested specifications per server. Choose an Ubuntu environment compatible with the actual component versions and image architectures.
| No. | Server | Purpose | OS | CPU | Memory | Storage | Quantity |
|---|---|---|---|---|---|---|---|
| 1 | Application server | Nginx, frontend resources, and qOntology API | Ubuntu | 8 vCPU | 16GB | 200GB SSD | 1 |
| 2 | Relational database server | MySQL business data storage | Ubuntu | 4 vCPU | 16GB | 500GB SSD | 1 |
| 3 | Graph database server | Neo4j graph storage and queries | Ubuntu | 8 vCPU | 32GB | 500GB SSD | 1 |
| 4 | Cache server | Redis caching | Ubuntu | 2 vCPU | 4GB | 100GB SSD | 1 |
| 5 | File preview server | kkFileView file conversion and previews | Ubuntu | 4 vCPU | 8GB | 200GB SSD | 1 |
| 6 | Vector server (optional) | Weaviate vector storage and retrieval | Ubuntu | 4 vCPU | 16GB | 300GB SSD | Add 1 if needed |
The base list totals 5 servers, 26 vCPU, 76GB RAM, and 1.5TB SSD (using 1000GB = 1TB for storage). The optional vector server is additional. If a suitable Weaviate service already exists, plan to connect to it rather than purchasing another server. Assess vector-service needs based on vector count, dimensions, and index configuration.
Separate component deployment
The default Compose stack runs on one host; it does not automatically distribute services across multiple machines. For the layout above, update the API's database, cache, and graph database addresses and Nginx's upstream addresses. Verify inter-service networking, authentication, and file access paths.
Each role above is a single node. Separating components isolates resources; it does not provide high availability by itself. If high availability is required, plan redundant nodes, failover, and backup/recovery separately, then recalculate resources.
Recommendations
- Storage and backups: prefer SSDs. Listed capacity includes the OS, applications, and local data; plan separate backup storage. Account for graph data and indexes, uploaded files, preview caches, and logs in addition to business data, and reserve capacity based on growth and retention periods.
- Memory allocation: the current backend image sets the API's maximum JVM heap to 2GB; Compose sets kkFileView's maximum heap to 1GB. Heap limits are not total process usage or total host memory requirements. Reserve memory for databases, graph caches, conversion processes, and the OS so the combined settings do not exhaust host memory.
- Compute and scaling: adjust CPU and memory to query complexity, concurrent extraction tasks, and file conversion volume. Test daily operations and batch workloads before rollout, then monitor CPU, memory, disk capacity, and I/O to decide whether to expand resources or separate services.
- AI and vector services: external model calls do not require a local GPU, but do require networking, a working endpoint, and credentials. Assess local large-model inference separately based on model size, quantization, and concurrency targets. Weaviate is not included in the default Compose stack and must be prepared separately if needed.
- OS and architecture: check the version, CPU architecture, and runtime requirements of every component and image. ARM and Chinese domestic environments such as Kylin require adaptation and validation on the target hardware/software combination.
- Networking and persistence: use controlled internal networks for application and data-service communication where possible, exposing only required ports. Confirm persistent storage locations for databases, graph data, and uploads, and verify that backups can be restored.
View deployment architecture · View Docker Compose deployment steps