Bring your own cloud

With bring your own cloud (BYOC), your KiviDB databases run in a cloud account you own instead of in KiviDB's. You create and manage them from the same…

Bring your own cloud

With bring your own cloud (BYOC), your KiviDB databases run in a cloud account you own instead of in KiviDB's. You create and manage them from the same KiviDB console, and KiviDB keeps operating them: failover, recovery, backups, upgrades. The machines, disks and backups live in your account.

BYOC is available on AWS, Google Cloud and Azure.

What stays in your account

Everything that holds or serves your data:

  • the machines your databases run on, and their disks
  • the public addresses and the network rules of each database: Elastic IPs and a security group on AWS; static external addresses and kividb-… firewall rules on Google Cloud; public IP addresses, network interfaces and a network security group on Azure
  • the groups that run read replicas (Pro): Auto Scaling groups on AWS, managed instance groups on Google Cloud, virtual machine scale sets on Azure
  • disk snapshots
  • KDB exports, in a bucket you choose (S3, Cloud Storage, or a container in an Azure storage account)

Every resource KiviDB creates carries managed-by=kividb (a tag on AWS and Azure, a label on Google Cloud), so you can always find it in your account.

KiviDB keeps running the console and the API, the DNS names your applications connect to, the TLS certificates, the database passwords, and the metrics and logs shown in the console.

How access works

You connect an account once, in the console. You create a role in that account from a CloudFormation template KiviDB provides, and KiviDB uses that role to create and manage databases for you. The role is narrow:

  • it works only in the regions you choose
  • it can change or delete only resources KiviDB created (tagged managed-by=kividb)
  • in your backup bucket, it can read and write only under the kividb/ prefix
  • it cannot create users, roles or policies

You can revoke it at any time by deleting the CloudFormation stack. See Permissions and security for exactly what the role can and cannot do.

On Google Cloud, the equivalent is a service account named kividb-mgmt in your project, created by a setup script or Terraform module KiviDB provides. KiviDB acts as it by impersonation, so no key is ever created. Its permissions are limited to resources named kividb- wherever Google Cloud allows it, and to the kividb/ prefix of your backup bucket. See Permissions and security.

On Azure, KiviDB works as its own app, KiviDB, added to your Microsoft Entra tenant. A setup command or Terraform module KiviDB provides gives the app its roles: management in one resource group you choose, and nowhere else, reads on the subscription, join on the subnets you name, and the kividb/ prefix of your backup container. KiviDB signs in with its own secret, so no credential of yours is created. See Permissions and security.

Requirements

  • An AWS account where you can create a CloudFormation stack with an IAM role.
  • A VPC in each region you want to use, with one subnet per availability zone you want databases in (up to six). Each subnet must route 0.0.0.0/0 to an internet gateway: databases have a public endpoint, limited to their allowlist, and need outbound internet access to reach KiviDB.
  • An S3 bucket in the same account, for backups. Any existing bucket works; KiviDB uses only the kividb/ prefix in it.
  • You must be the owner of the KiviDB organization to connect an account.

On Google Cloud, you need a project where you can create service accounts and custom roles, a VPC network with a subnet in each region and a route to the internet, and a Cloud Storage bucket in the project with uniform bucket-level access. See Connect your Google Cloud project.

On Azure, you need to be an Owner of the subscription (or Contributor plus User Access Administrator), a subnet in each region with a way to the internet, and a storage account with a container for backups. See Connect your Azure subscription.

What works differently

Most things work exactly as they do in KiviDB's cloud: creating, resizing, upgrading and deleting databases, high availability and failover, persistence, schedules, metrics and logs, the Explorer, users and passwords. The differences:

  • Private endpoints. Each database also has a private name that resolves inside your VPC, VPC network or virtual network. See Connect from inside your VPC.
  • No private connectivity add-on. The database is already inside your network, so there is no endpoint service to set up.
  • A public endpoint is required for now. It is limited to the database's allowlist. Private-only databases are not available yet.
  • Backups stay in your account. See Backups and restores.
  • Free tier databases always run in KiviDB's cloud.

Next steps

  1. Connect your AWS account, your Google Cloud project or your Azure subscription
  2. Create a database in your account
  3. Connect from inside your VPC