--- title: Common deployment methods description: Public cloud platform, self-purchased server, single server, virtualization, object storage, distributed and disaster recovery deployment methods. slug: deployment-modes lang: en category: Deployment Guide category_order: 7 order: 8 keywords: - Deployment - Common deployment methods - Private Deployment --- # Common Deployment Options BabelBird can run in an enterprise data center, on a virtualization platform, or on cloud infrastructure such as Alibaba Cloud and Huawei Cloud. Deployment choices determine operations and availability design, not guaranteed capacity or disaster recovery from a fixed server count. ## Options | Option | Suitable environment | Components and considerations | | --- | --- | --- | | Cloud infrastructure | Cloud compute and storage projects | Application, database, search and optional processing, with OSS/OBS/S3 storage; validate managed-database compatibility. Object storage does not replace the database | | Purchased servers | Local data center and storage | Separate business and storage resources as required by load and redundancy | | All-in-one | Small evaluation or limited resources | Combined services and mounted storage; a single point of failure requires independent backups | | Virtualization / hyperconverged infrastructure | Existing IT resources | Allocate application, database, search and conversion resources; mount storage or connect object storage | | High availability | Continuity and maintenance requirements | Redundant application, database, storage and entry points; validate failover and failback | | Cross-network data ferry | Controlled exchange between network zones | Separate deployments, transfer channel, direction, approval and logging; see [data ferry](deployment-data-ferry.md) | Cloud deployment still requires application operations, security configuration, backups and recovery tests, plus compute, storage and network fees. Multi-zone and off-site recovery must be designed explicitly. ## Resource Planning Application, database, search, processing and storage are distinct roles that may be combined or separated. Hardware models, OS versions and user counts in historical white papers are references, not current procurement commitments. Use the [configuration advisor](configuration-advisor.md) and [server requirements](deployment-requirements.md) to select a maintained OS and validate capacity and workload. ## Object Storage Connect validated NFS/S3 storage or build object storage on general-purpose servers. Single-server and distributed configurations have different fault boundaries. ![Single-server object-storage topology](../../assets/images/object-storage-single-server.jpg) *Single-server example; independent backups remain necessary.* ![Distributed object-storage topology](../../assets/images/object-storage-cluster.jpg) *Multi-node example. Confirm erasure-code parameters, failure domains, minimum nodes and expansion batches for the chosen storage implementation. Data/parity block counts do not universally translate to server counts.* ## Availability and Disaster Recovery HA reduces the impact of certain failures; backups support recovery from deletion, corruption or site failure. Neither replaces the other. Plan consistent recovery of database records, file content and required configuration. ![Off-site disaster recovery](../../assets/images/backup-disaster-recovery.jpg) *Controlled replication or backup between primary and recovery sites.* Define RPO, RTO, replication mode, retention and failback procedures. Restoring backups takes time; object-storage replication alone does not make the application and database fail over together. See [high availability](deployment-high-availability.md) and [backup and recovery](deployment-high-availability.md).