--- title: "Introduction to YugabyteDB Anywhere" url: "https://docs.yugabyte.com/stable/yugabyte-platform/yba-overview/" --- # Introduction to YugabyteDB Anywhere YugabyteDB Anywhere architecture and introduction. YugabyteDB Anywhere from 50,000 ft YugabyteDB Anywhere (YBA) is a self-managed database-as-a-service that allows you to deploy and operate YugabyteDB database clusters (also known as universes) at scale. In YBA, a database cluster is called a [universe](/stable/architecture/key-concepts/#universe "universe"), and the terms are used interchangeably. More precisely, a universe in YBA always consists of one (and only one) [primary cluster](/stable/architecture/key-concepts/#primary-cluster "primary cluster"), and can optionally also include a single [read replica](/stable/architecture/key-concepts/#read-replica-cluster "read replica") cluster attached to the primary cluster. ## Features You can use YBA to deploy YugabyteDB database clusters that will tolerate single node failures, multiple node failures, single availability zone failures, multiple availability zone failures, single region failures, cloud provider failures, and more. YugabyteDB Anywhere also supports [xCluster](/stable/architecture/docdb-replication/async-replication/ "xCluster") deployments (including for disaster recovery), where two YugabyteDB universes are deployed, and data is replicated asynchronously between them. YBA supports these deployments in the following environments: - On-premises - YBA can deploy YugabyteDB on VMs or bare metal hosts running various flavors of Linux, with the flexibility required to accommodate organizational security and compliance needs. - Public clouds - YBA can deploy cloud-native YugabyteDB clusters in AWS, Azure, GCP, and OCI. YBA understands the native instance types, volume types, availability zones, regions, and OS image availability on each cloud, and maps them seamlessly to YugabyteDB's fault tolerance and performance configurations. - Kubernetes - YBA can deploy YugabyteDB in Kubernetes clusters and both map the zones available in a single Kubernetes cluster, and map multiple regions across different Kubernetes clusters to YugabyteDB's fault tolerance capabilities. ### Additional features YBA supports the following additional features: - Encryption in transit, with support for CA and self-signed certificates. - Encryption at rest, with integration with major Key Management Services (KMS), including AWS, GCP, Azure, OCI Vault, and Hashicorp Vault. - Scheduled backups to cloud native storage such as AWS S3, Google GCS, Azure Storage, and OCI Object Storage, as well as to vanilla NFS storage. - Alerting and monitoring, using [Prometheus](https://prometheus.io "Prometheus"). - Integration with LDAP and OIDC for authentication. - High availability configuration for fast recovery of YBA in case of an outage. ### Day 2 management YBA supports common Day 2 management operations, including the following: - Online scale in and out with no disruptions to existing database clients. - Vertical online scale up and down. - Online database software upgrades and configuration changes. - Online OS patching. - Incremental and full backups, and point-in-time recovery. - Rotation of CA and server certificates for encryption in transit. - Rotation of KMS keys used for database encryption at rest. - Monitoring and alerting of database health. - Monitoring performance and metrics, including finding slow queries and getting insights on performance tuning using [Performance Advisor](/stable/yugabyte-platform/alerts-monitoring/performance-advisor/ "Performance Advisor"). YBA operations can be performed through a GUI, or via automation tools that use its exposed REST APIs or Terraform provider. ## YugabyteDB Anywhere architecture YBA runs on standalone VMs or Kubernetes pods. YBA can in turn be used to deploy YugabyteDB database clusters on either VMs or Kubernetes pods. ![YugabyteDB Architecture](/images/yb-platform/prepare/yba-architecture.png "YugabyteDB Architecture") A VM that is part of a YugabyteDB cluster runs multiple processes, including the [YB-Master](/stable/architecture/yb-master/ "YB-Master") and [YB-TServer](/stable/architecture/yb-tserver/ "YB-TServer") services of the cluster, and other secondary agents, including the [node agent](/stable/faq/yugabyte-platform/#node-agent "node agent"), YB Controller backup agent, and [Prometheus Node Exporter](https://prometheus.io/docs/guides/node-exporter/ "Prometheus Node Exporter") for host metrics export. The YB-Master and YB-TServer services can be deployed in the same VM or, for better isolation, in separate dedicated VMs. On Kubernetes clusters, the YB-Master and YB-TServer services always run in isolated pods. For more information on the architecture of YugabyteDB, see [YugabyteDB Architecture](/stable/architecture/ "YugabyteDB Architecture"). YBA requires network connectivity to the YugabyteDB database clusters to perform day 2 operations and monitoring. And, of course, in any cluster, database cluster nodes require connectivity to each other. Network connectivity to the public Internet is optional: YBA supports both Internet-connected and air-gapped deployments. YBA stores cloud provider metadata and other cluster metadata in its own embedded database. YBA also uses a local Prometheus instance to scrape and store metrics from YugabyteDB clusters. To ensure fault tolerance of YBA itself, YBA can be configured in [High Availability](/stable/yugabyte-platform/administer-yugabyte-platform/high-availability/ "High Availability") mode. In this setup, the primary YBA instance is synchronized with one or more standby instances to provide quick failover in case of an outage. ## Provider configurations A provider configuration (also referred to as provider) describes your cloud. For example, the regions and zones that you will allow YugabyteDB to be deployed to. Additionally, in the case of public IaaS clouds, the service account YBA should use to create servers/VMs in your cloud. YBA uses the cloud configuration information in a provider to deploy and manage universes. YBA supports three major types of provider configurations: 1. On-premises. 2. Public Cloud (AWS, GCP, Azure, or OCI). 3. Kubernetes (for example, VMware Tanzu, Red Hat OpenShift, or Managed Kubernetes Service). On-premises Cloud Kubernetes Advantages Maximum flexibility Maximum automation It's Kubernetes Platforms Private cloud, bare metal, AWS, Azure, GCP, OCI AWS, Azure, GCP, OCI Kubernetes Permissions for YBA Minimal sudo access during provisioning Cloud and OS permissions As required for Kubernetes Node provisioning Manually created, with automatic provisioning using a script Automatically created and provisioned Via Helm ### On-premises Unlike the Kubernetes and cloud providers, where YBA has privileges and creates the VMs (or pods) automatically, with an on-premises provider *you* create the server VMs manually. Use this option for any of the following situations: - You are deploying YugabyteDB clusters truly on-premises (for example, on VMware or Nutanix). - You are deploying YugabyteDB clusters to public cloud, but (due to security policies or other restrictions) you can't provide YBA with cloud permissions or SSH access to cloud VMs. In this case, you must create your VMs and/or deploy your Linux OS manually in the cloud. - You are deploying a single [stretched cluster across multiple clouds](/stable/yugabyte-platform/create-deployments/create-universe-multi-cloud/ "stretched cluster across multiple clouds") (for example, one cluster with some nodes on AWS, others on GCP, and/or others on Azure). - Any other cases where you must retain control over creating the VMs and/or Linux OS, and can't give this control to YBA. With the on-premises provider, after creating VMs manually (that is, outside of YBA), you will add them to your on-premises provider's free pool of servers. Subsequently, when creating the universe, database nodes are taken from the on-premises provider's free pool of servers and added to the universe. ### Public cloud If you are deploying a universe to a public cloud (AWS, Azure, GCP, or OCI) and want maximum automation when managing clusters (creating them, scaling them, patching the OS, and so on), use a public cloud provider configuration. This approach does require that you provide YBA with cloud and OS privileges. For example: - YBA must be given privileges to create a VM. - YBA must initially have root-level SSH login access to that VM for initial installation of a management agent. After installation of the agent, SSH access can be removed. This approach allows for maximum automation. Also, you do have the option to specify a custom OS image that otherwise meets all other enterprise security rules. ### Kubernetes If you are deploying a universe to Kubernetes, use a Kubernetes provider. ## New experience [EA](/stable/releases/versioning/#feature-maturity) Starting in v2026.1.2.0, YugabyteDB Anywhere features a new and improved experience, with many usability enhancements. Throughout the documentation, steps that differ between the two UIs are marked as follows: - [New UI](/stable/yugabyte-platform/yba-overview/#new-experience) Steps for the new experience - [Classic UI](/stable/yugabyte-platform/yba-overview/#new-experience) Steps for the classic UI ### Enable the new experience While in Early Access, the new experience is not available by default. To enable the new experience, do the following: - To enable the experience for Super Admin, set the **Enable new Universe experience** Global Runtime Configuration option (config key `yb.ui.feature_flags.enable_new_universe_experience`) to true. - To enable the experience for all users, set the **Enable new Universe experience for all users** Global Runtime Configuration option (config key `yb.ui.enable_new_universe_experience_for_all_users`) to true. Refer to [Manage runtime configuration settings](/stable/yugabyte-platform/administer-yugabyte-platform/manage-runtime-config/ "Manage runtime configuration settings"). Note that only a Super Admin user can modify Global configuration settings. ### New and improved The new experience provides significant enhancements and new features, including: - New Universe Configuration Wizard Set up and manage universes using a wizard in **Guided** or **Expert** mode to help you build the right topology. In **Guided** mode, choose how resilient you want your universe to be and build from there; **Expert** mode gives you full control over replication factor and per-zone node counts. - [Plan your universe](/stable/yugabyte-platform/create-deployments/create-universes-overview/ "Plan your universe") - [Create a universe](/stable/yugabyte-platform/create-deployments/create-universes-wizard "Create a universe") - Preferred availability zone ranking You can now rank preferred regions and availability zones to pin tablet leaders and optimize read and write latency. [Learn about preferred regions and zones](/stable/yugabyte-platform/create-deployments/create-universes-overview/#preferred-region "Learn about preferred regions and zones") - Add Read Replica wizard Add a read replica to your universe using a new wizard, then edit placement, hardware, and flags independently. [Add a read replica](/stable/yugabyte-platform/create-deployments/read-replicas/ "Add a read replica") - Review before you apply Placement and hardware changes now provide a summary of current and new values before you confirm. For vertical scaling, choose whether to resize existing nodes (smart resize) or migrate to a new set of nodes. [Scale and edit universes](/stable/yugabyte-platform/scale-deployments/edit-universe/ "Scale and edit universes") - Centralized universe settings Access all your universe configuration settings from a single **Settings** tab. See [Where did features move](#where-did-features-move "Where did features move"). ### Where did features move? Universes have a new **Settings** tab for all universe configuration settings, organized as follows: - General: Cluster information - Placement: Resilience or replication factor, regions, availability zones, and ranked preferred regions - Hardware: Instance types and disk - Security: Network access, encryption in transit, and encryption at rest - Database: API endpoints and authentication (YSQL/YCQL), additional features, and configuration flags - Advanced: Proxy settings, ports, node access, and Kubernetes overrides - Logs: Database query and audit log settings - Telemetry Export: Log and metrics export See where features have moved: | [Classic UI](/stable/yugabyte-platform/yba-overview/#new-experience) | [New UI](/stable/yugabyte-platform/yba-overview/#new-experience) | |----------------------------------------------------------------------|------------------------------------------------------------------| | Edit Universe (Region, AZ, and node placement) | Settings > Placement | | Edit Universe (Instance Configuration) | Settings > Hardware | | Edit Universe (Place Masters on dedicated nodes) | Settings > Placement > Advanced Placement Options | | Edit Universe (User Tags) | Settings > Advanced > User Tags | | Add Read Replica / Edit Read Replica | Settings > Placement | | Create Universe > Configure Read Replica | Add after creating the universe (Settings > Placement) | | Edit Flags | Settings > Database > Advanced Config Flags | | Edit Postgres Compatibility | Settings > Database > Features | | Connection Pooling | Settings > Database > Features | | Edit YSQL / YCQL Configuration | Settings > Database > Interface | | Edit Security > Encryption in-Transit | Settings > Security > Encryption in Transit | | Edit Security > Encryption at Rest | Settings > Security > Encryption at Rest | | Edit Kubernetes Overrides | Settings > Advanced > Helm Overrides | | Logs / Enable Database Audit Logging | Settings > Logs | | Logs & Metrics Export | Settings > Telemetry Export | | Metrics > Export Metrics | Settings > Telemetry Export |