Introduction to YugabyteDB Anywhere

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, and the terms are used interchangeably. More precisely, a universe in YBA always consists of one (and only one) primary cluster, and can optionally also include a single 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 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.
• 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.

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.

A VM that is part of a YugabyteDB cluster runs multiple processes, including the YB-Master and YB-TServer services of the cluster, and other secondary agents, including the node agent, YB Controller backup agent, and 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.

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 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

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 (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 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 Steps for the new experience
• Classic UI 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. 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
  • 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

• 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

• 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

• Centralized universe settings

  Access all your universe configuration settings from a single Settings tab.

  See 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: