Configuration Advisor
BabelBird Enterprise Drive private deployment can be planned by licensed-user count, concurrent access, total file volume, preview/transcoding load, sync-client count, Zhichao AI usage, object-storage capacity and disaster-recovery requirements. This page provides a configuration advisor for presales teams, IT administrators and integration partners to obtain an initial deployment architecture and server sizing recommendation.
Configuration Advisor
Enter the licensed-user count, deployment model and identity-integration method. The page will generate an adaptive logical architecture diagram, server sizing table and implementation notes.
This tool is for presales and early solution sizing. Final configuration should be confirmed against concurrency, total file volume, daily growth, preview/transcoding ratio, sync-client count, AI modules, disaster-recovery level and existing infrastructure.
Logical Deployment Architecture
Server Sizing Recommendation
| Role | Qty | Recommended Configuration | OS / Platform | Purpose |
|---|
Implementation Notes
Recommendation Logic
The advisor combines licensed-user count, deployment model and optional modules. Licensed users determine the base sizing tier. The deployment model determines whether active/standby, cluster, K8S or dual-active architecture is required. The SSO option adds identity authentication and organization-sync links to the architecture diagram.
| Factor | Impact |
|---|---|
| Licensed users | Determines baseline sizing for application, database, search, cache and storage nodes |
| Standard deployment | Fits small and medium single-site deployments with lower cost and simpler maintenance |
| High availability | Fits enterprises requiring business continuity, typically with active/standby application, database, independent search, transcoding and object storage |
| K8S high availability | Fits enterprises that already operate a container platform and need elastic scaling and unified operations |
| Dual-active data centers | Fits core business systems requiring cross-site access, data synchronization, disaster recovery and higher continuity |
| SSO / organization sync | Adds AD, LDAP, WeCom, DingTalk, Feishu, OAuth2/OIDC or OA integration to the architecture |
| Zhichao AI / OCR | Adds AI and OCR compute nodes; fully private AI usually requires a dedicated GPU server |
| Online editing and transcoding | Adds OnlyOffice, transcoding, Tika text extraction and related file-processing services |
Deployment Model Selection
| Deployment model | Suitable scenario | Typical characteristics |
|---|---|---|
| POC / trial deployment | Product evaluation, short-term testing, light use within about 100 users | Optimized for fast launch; application and storage may be combined; not recommended as a long-term production architecture |
| Standard deployment | Single-site production within roughly 100-5000 users | Application, database, transcoding and storage can be split by scale; lower cost and maintenance complexity |
| High availability | Enterprises requiring stability and business continuity | Active/standby application and database, independent search, transcoding and object storage; supports failover and maintenance windows |
| K8S high availability | Existing Kubernetes platform or unified container operations | Multi-replica application engines; database, search, cache and storage planned as clusters |
| Dual-active data centers | Groups, finance, government and enterprise core services across sites | Both sites can carry traffic, with proxy, database sync, object-storage sync and disaster-recovery strategy |
| Cloud deployment | Huawei Cloud, Alibaba Cloud, Tencent Cloud or other cloud platforms | Uses ECS, OBS/S3, cloud databases, load balancers, backup and monitoring services to reduce hardware operations |
Sizing Tiers
The following sizing tiers come from BabelBird private-deployment experience and recommendation sheets. They are suitable for early estimation. Actual projects should be confirmed against concurrency, file volume, preview formats, sync-client count, bandwidth, storage growth, backup strategy and existing infrastructure.
| Scale / plan | Main server recommendation | Storage recommendation | Notes |
|---|---|---|---|
| POC deployment | 1 application server, 16-core CPU, 32GB RAM, 960GB SSD system disk; optional transcoding server, 8-core CPU, 16GB RAM, 200GB system disk | Mount required storage directly, such as 10TB-40TB | Used to validate functions, permissions, preview, sync and integration flows |
| 100-1000 users standard | 1 application server, 16-core CPU, 64GB RAM, 960GB SSD; optional transcoding server | Direct-mounted storage, NFS or object storage | Cost-sensitive production plan for single-site environments with moderate concurrency |
| 100-1000 users high availability | 2 application servers, 2 database servers, 1 search server, 1 transcoding server | S3/OBS or shared storage is recommended for failover | For small and medium enterprises requiring failover |
| 1000-5000 users standard | 1 application server, 16-core CPU, 64GB RAM; 1 database server, 8-core CPU, 32GB RAM; 1 transcoding server, 8-core CPU, 16GB RAM | 1 storage server, recommended 16-core CPU, 64GB RAM, 500GB SSD + 16*10TB SATA, or third-party S3/NFS | Fits enterprises with larger file volume but acceptable single-site maintenance windows |
| 1000-5000 users high availability | 1 primary application server, 1 secondary application server, 1 primary database, 1 secondary database, 1 search server, 1 transcoding server; Redis and monitoring are optional | 2 storage servers or high-availability object storage recommended | Common production recommendation balancing stability and cost |
| 1000-5000 users K8S high availability | 3-5 application-engine replicas; 2 database replicas; 3 ES replicas; 3 Redis replicas | S3/OBS object storage; PVC should use SSD/NVMe StorageClass | Fits customers with existing K8S operations |
| 1000-5000 users + Zhichao AI/OCR | Add an AI/OCR node to the HA plan: 8-core CPU, 32GB RAM, 1TB SSD, T4/4080/A10-class 16GB GPU | Plan extra capacity for AI knowledge bases and vectorized data | Can connect to external compute platforms/public APIs or run privately |
| 1000-5000 users + fully private AI compute | Add an AI compute server to the HA plan: 32-core CPU, 128GB RAM, 1TB SSD, 4*5880 Ada 48GB GPU-class hardware | Reserve capacity for models, vector database, OCR intermediate files and knowledge-base indexes | For closed intranet AI scenarios where data must stay inside the domain |
| 10K-50K users high availability | Primary and secondary application servers each 32-core CPU, 128GB RAM; primary and secondary database servers each 16-core CPU, 64GB RAM; search 16-core CPU, 32GB RAM; transcoding 16-core CPU, 32GB RAM; Redis and monitoring are optional | Independent physical object-storage servers or distributed object storage, such as dual CPU, 128GB RAM, 960GB SSD + multiple high-capacity SATA disks | Requires dedicated design based on concurrency, organization scale and network topology |
| Cloud deployment | ECS application server, 32-core CPU, 64GB RAM, 960GB SSD; Cloud Database / RDS, 8-core CPU, 32GB RAM, 500GB SSD; optional Windows transcoding server, 8-core CPU, 16GB RAM | OBS/S3 purchased by required capacity and expanded on demand | Fits Alibaba Cloud, Huawei Cloud, Tencent Cloud and other public-cloud or hardware-light projects |
SSO And Organization Sync
BabelBird can integrate with multiple identity and organization systems. The integration method affects login flow, organization synchronization, user fields, permission mapping and network allowlists, but usually does not require a mandatory additional server.
| Integration | Common use | Architecture focus |
|---|---|---|
| AD / LDAP | Domain-account login, organization and user synchronization, internal unified identity | Confirm LDAP address, Base DN, sync fields, unique account identifier and network allowlist |
| WeCom | Access inside WeCom, organization sync and message notifications | Configure enterprise ID, app secret, callback URL and trusted domain |
| DingTalk | DingTalk access, address-book sync, task and message entry | Configure app credentials, callback URL, address-book permission and IP allowlist |
| Feishu | Feishu organization sync, SSO and workbench entry | Configure app permissions, callback URL, user-field mapping and open-platform permission |
| OAuth2 / OIDC | Integration with IAM, unified identity or zero-trust platforms | Confirm authorize endpoint, token endpoint, userinfo endpoint, scope, callback URL and signing algorithm |
| Seeyon OA | Link with OA portal, organization, accounts or unified entry | Clarify OA-side identity protocol, organization-sync API, jump entry and network-access policy |
Architecture Diagram Notes
The diagram displays user access, access and identity, application services, data services, file processing, object storage, and operations/security layers. It adapts when different deployment models are selected:
- Standard deployment emphasizes a single site, lower cost and baseline split of application, database, transcoding and storage; POC and standard deployment only display one database server in the data-service layer.
- High availability displays active/standby applications, active/standby databases, load balancing, shared or object storage and backup links; Redis and monitoring are shown as optional items.
- K8S high availability displays Ingress, application replicas, database primary/replica, ES cluster, Redis cluster and StorageClass.
- Dual-active data centers display Center A / Center B, global access entry, per-site application/data services, cross-site data synchronization and disaster recovery.
- Selecting SSO adds the external identity system and organization-sync node to the diagram.