Security
The controls in KiviDB Cloud, area by area. Each table says what is in place and what is not. Unless stated otherwise, statements apply to paid plans (Essentials, Pro, Scale) on AWS, Google Cloud and Azure.
How the service is built
KiviDB Cloud has two parts.
- The control plane is the website, console, API and the systems behind them. It runs in KiviDB's AWS account in Frankfurt (eu-central-1). It holds account records, billing records, database settings and the credentials needed to operate each database. It does not hold the contents of your database.
- Your database runs on its own virtual machines, in the cloud provider and region you choose. On the Pro plan it has replicas and fails over automatically. A small management agent on each machine carries out a fixed list of operations sent by the control plane.
With Bring Your Own Cloud, the machines, disks, network and backups are in your own AWS, Google Cloud or Azure account. See below.
Encryption in transit
| Connection | Status | Detail |
|---|
| Browser or tool to website, console and API | In place | TLS 1.2 or higher only. Plain HTTP redirects to HTTPS. HSTS is sent. |
| Your application to your database | Partial | TLS is available on its own port and is off unless you enable it. With "require TLS" enabled, your allowlist applies to the TLS port only. Certificates are issued by KiviDB's own certificate authority; you download its certificate from the console and trust it in your client. Client certificates (mutual TLS) signed by your own CA can be made optional or required; they are checked in addition to the password. |
| Between the nodes of one database (replication) | Optional | Encrypted with TLS when the database has TLS and encrypted replication is turned on; off by default. A sharded database with TLS always encrypts traffic between its nodes. Otherwise it travels unencrypted between private addresses inside the cloud provider's network, in one region. |
| Control plane to your database | Not in place | The console's data browser, health checks and some management operations connect to the database port from KiviDB's fixed addresses. These connections are authenticated and restricted by the firewall, but not encrypted. |
| Management agent to control plane | In place | HTTPS, outbound from the database server only. |
Encryption at rest
| What | Status | Detail |
|---|
| Database disks on AWS | Partial | Encrypted with AWS-managed keys for disks created from 11 October 2026. Disks created before that date are not encrypted. |
| Database disks on Azure and Google Cloud | In place | Encrypted by the provider with provider-managed keys. |
| Backups and exports | In place | Stored in the provider's object storage, encrypted at rest with provider-managed keys (AES-256 on AWS). Not publicly accessible. |
| KiviDB's account database | In place | Encrypted at rest. Not reachable from the internet. |
| Database passwords | In place | Encrypted by the application with AES-256-GCM before they are stored in the account database. The key is kept in AWS Secrets Manager, not in the database. A copy of each database's passwords is also held in AWS Secrets Manager, encrypted by AWS. KiviDB's services can read them, because they need them to operate your database. |
| Customer-managed keys | Not in place | You cannot supply or control the encryption keys. |
Network
| Control | Status | Detail |
|---|
| Firewall per database | In place | Each database has its own firewall rules. Only addresses on your allowlist can reach it. An empty allowlist means nobody can. |
| Allowlist default | In place | A database created in the console starts with only your own address allowed. One created through the API starts closed. KiviDB does not stop you adding a wide range; that is your decision. |
| Private connectivity | In place | AWS PrivateLink, Azure Private Link and Google Private Service Connect are available as a paid option, and public access can then be closed. |
| Public addresses | Partial | Database servers have public IP addresses. Exposure is limited by the firewall, not by the absence of an address. |
| Isolation between customers, AWS | In place | A separate subnet per customer and a separate firewall group per database. Traffic between a database's own nodes is allowed only within that group. |
| Isolation between customers, Azure and Google Cloud | In place | Customers' servers share a virtual network in each region, and each database has its own firewall rules within it. Traffic between a database's own nodes is allowed only between those nodes, and other traffic from inside the shared network is refused. |
| Web application firewall, DDoS service | Not in place | None beyond what the cloud providers apply by default. |
Accounts and sign-in
| Control | Status | Detail |
|---|
| Passwords | In place | Stored only as Argon2id hashes. Minimum 12 characters. |
| Google sign-in and single sign-on | In place | Google, and enterprise single sign-on by OpenID Connect or SAML. Sign-on is brokered by Auth0. |
| Two-factor authentication | Partial | Codes from an authenticator app, asked for after a password, Google or single sign-on sign-in. Off unless you turn it on; an organization's owner can require it of every member. Once on it cannot be turned off, only moved to a new authenticator. Ten single-use recovery codes, stored only as hashes. An account that no organization requires it of can instead be sent a code by email, and must then set up a new authenticator; where an organization requires it, the owner resets the member instead. No hardware security keys or passkeys. API keys are not asked for a second factor. |
| Attempt limits | In place | Sign-in is limited per account and per address; sign-up and password-reset requests per address. |
| Sessions | In place | Access tokens last 15 minutes. Refresh tokens last 14 days, are stored only as hashes, change on every use and are revoked when you sign out or reset your password. |
| Roles | In place | Owner, admin, member and viewer, for people and API keys alike. Billing and member management are restricted to owners, and minting API keys to owners and admins. A viewer reads metadata only: it cannot change anything, or read a password, a key, a document or a snapshot. |
| API keys | Partial | Stored only as keyed hashes, shown once, revocable at once, bound to one organization. A key cannot have less access than a member, and by default does not expire. |
| Audit log | In place | Every change to an organization and its databases, made in the console, with an API key or through an AI assistant, is recorded with who made it, when, from which address and on what, and so are sign-ins and failed password attempts. Owners and admins can read it and export it as CSV or JSON lines; events are kept for a year. The commands sent to a database and the data in it are not recorded. |
Access by KiviDB
| Question | Answer |
|---|
| Can KiviDB staff log in to a database server? | No. There is no shell or remote-login path. The management agent accepts a fixed list of twelve operations (for example: take a backup, apply a resize, update certificates) and rejects anything else. |
| Can KiviDB read the contents of a database? | Technically, yes. To run failover, backups and the console's data browser, the control plane holds each database's credentials and can connect to it. KiviDB does not access customer data except to provide the service or at the customer's request. |
| Is there a way to sign in as a customer? | No. The API has no impersonation or "log in as" function. |
| Who has access to production systems? | The founding team, through single sign-on to the cloud accounts. KiviDB is a small company and access is not yet divided into narrower roles. |
Bring Your Own Cloud
When a database runs in your own cloud account:
- The servers, disks, network and backups are yours and stay in your account. Your account's own audit log records what KiviDB does there.
- You grant access with a role or service account that you create from a template you can read. On AWS it is limited to the regions you list and to resources tagged as managed by KiviDB; on Google Cloud to resources named
kividb-; on Azure to one resource group.
- Removing that role or account ends KiviDB's access immediately.
- The control plane still holds the database's credentials and certificates, and still receives its metrics and logs.
Availability and backups
| Control | Status | Detail |
|---|
| Replicas and automatic failover | In place | On the Pro plan. Essentials is a single server. |
| Durability | In place | On paid plans every write is recorded in an append-only log on the database's disk, which survives a restart or replacement of the server. |
| Backups | Partial | Disk snapshots and exports, taken when you ask for one. Scheduled disk snapshots (hourly, daily or weekly, with a retention you set) are available per database and are off unless you switch them on. A snapshot restores the database as it was when the snapshot was taken; there is no recovery to an arbitrary point in time. |
| Uptime commitment | In place | See the Service Level Agreement. Availability is measured per database and kept for 400 days. |
| Status page | In place | status.kividb.io is run by Better Stack, an independent monitoring service, which keeps the history. It checks the website, the API and the MCP server directly, and polls a health check for each service once a minute; those checks run real operations against a KiviDB-owned database on AWS (write and read, full-text and vector queries, snapshots, schedules, metrics and logs). Databases on Azure and Google Cloud are not yet covered by a data-path check. Affected customers are also told by email. |
| Control plane | Partial | Its database runs in two availability zones with daily backups kept for 7 days. A control-plane outage does not stop running databases, but the console and API would be unavailable. |
Software integrity
| Control | Status | Detail |
|---|
| Management agent updates | In place | Signed, and verified by the agent before it updates itself. |
| KiviDB server downloads | Not in place | Served over HTTPS. Not signed, and no checksums are published. |
| Dependencies | Partial | Pinned by lock files. Container images are scanned when pushed. There is no automated dependency, secret or static-analysis scanning in the build. |
| Changes | Partial | Made by pull request with automated type and consistency checks. KiviDB does not have independent review of every change. |
| Environments | Partial | Test and production are separate deployments with separate databases and secrets, but share cloud accounts. |
Logging and monitoring
- Requests to the API are logged with address, time, path and result, and kept for 90 days.
- Each database's server log and metrics are collected to the control plane and kept for 30 days. They are what the console's Logs and Metrics pages show.
- KiviDB is alerted to failover and recovery events. Alerting on the control plane itself is basic.
- There is no dedicated security monitoring or intrusion detection service.
Payments
Card and bank details are entered on Razorpay's checkout and never reach KiviDB's servers. KiviDB keeps order and payment references, amounts and tax details.
Website
- No analytics, advertising or tracking cookies. The site stores only your sign-in session and preferences in your browser.
- Security headers are sent: HSTS, no content-type sniffing, no framing, limited referrer. A content security policy is not in place yet.
- Session tokens are kept in the browser's local storage.
Organisation
- KiviDB has not had an independent audit or a penetration test.
- If personal data is breached, KiviDB will notify affected customers and the authorities within the time the law requires. A written incident-response plan is not yet in place.
- Security problems can be reported under the disclosure policy.
Free tier
Free-tier databases are for trying the product. Several customers' databases run on one shared server, TLS is not available, and they expire after 7 days. Do not put data you need to protect in a free-tier database.