1. Pilae
2. Apps
3. OpenBao

Running OpenBao in production: what it takes

1. Decide how it unseals

   Auto-unseal against your HSM over PKCS#11 or a KMS you control, so a restarted node rejoins by itself. With Shamir shares instead, every restart waits for your key holders, and upgrade windows are planned around them.

2. Initialise with your key holders

   Three or five nodes on a pinned version we have run. At initialisation the key shares are encrypted to the PGP keys of people you name, so nobody at Pilae sees them in the clear, and the initial root token is revoked once setup is done.

3. Wire sign-on, policies and TTLs

   People sign in through OIDC against Keycloak or your IdP; applications use AppRole, Kubernetes or certificates. Policies live in your repository, and lease TTLs come down from the 32-day default to what each mount needs.

4. Snapshot daily, restore against the seal

   A Raft snapshot goes offsite daily, encrypted, to a location in your chosen country. Once a month we restore it into a scratch cluster with no outbound network, unseal it against the same key and read a known test secret. A snapshot restores nothing without the seal, so the drill tests both.

5. Upgrade standbys first, in your window

   The Pilae Agent tests the upgrade on a copy with no outbound network, so its leases cannot revoke real credentials, then waits for your approval. Standbys go first and the active node last. OpenBao promises no downgrade, so the rollback is the previous binary plus the snapshot taken just before.

What OpenBao is, and who runs it

OpenBao system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

Cluster

3 or 5 nodesIntegrated Raft storage works only while a majority of nodes is up. Three nodes survive the loss of one, five survive two, and five is what upstream recommends. Where you already run a replicated PostgreSQL cluster, OpenBao can store its data there instead.

CPU, memory and disk

2 vCPU · 4 GB · SSD per nodeUpstream publishes no minimum, so this is where we start. Request rate and the number of live leases decide the size, not the number of secrets. Upstream does ask for SSDs and no burstable CPU or disk, because every write waits on a majority of nodes.

Seal

PKCS#11 HSM, KMS or ShamirDecides who can start OpenBao. Auto-unseal against an HSM or KMS you control, or unseal key shares held by people in your organisation. Pilae holds neither.

Sign-in

OIDC · AppRole · TLS certificatesThe built-in JWT/OIDC auth method federates people with Keycloak or Microsoft Entra ID. Applications authenticate with AppRole, Kubernetes service accounts or TLS certificates. LDAP sign-in now ships as a separate plugin.

Access

Private network · TLS · 8200Applications reach OpenBao over your private network with TLS to every node. It goes behind the gate on port 443 only if something outside must reach it, and the web UI stays on the private network.

Migrating from HashiCorp Vault to OpenBao

OpenBao keeps the Vault API, down to the X-Vault-Token header, so applications and their client libraries mostly need a new address rather than new code. The data is another matter. Upstream documents an in-place swap only for a Vault Community cluster on 1.14.1, the release it tested, with Raft storage and Shamir unseal. A current Vault, or any Vault Enterprise cluster, moves by copy into a new OpenBao cluster: the configuration is rebuilt as code and the static secrets are copied by script. Tokens and leases do not come across, so clients log in again and dynamic credentials are issued fresh. Replication and Sentinel policies have no equivalent. Most of the work is in the inventory: which mounts are live, and which clients call them.

1. Inventory mounts and callers

   The secrets engines, auth methods and policies in use, read from Vault itself, and the clients that call them, read from its audit log. Mounts that depend on a plugin OpenBao does not ship are flagged here, before anything moves.

2. Rebuild the configuration as code

   Policies, auth roles and mount settings are written as code in your repository and applied to a new OpenBao cluster beside Vault. Vault Enterprise namespaces become OpenBao namespaces.

3. Copy the static secrets

   KV secrets are read from Vault, written to OpenBao and compared path by path. An internal CA gets a new intermediate signed by your root rather than a copied key.

4. Move clients, then retire Vault

   Applications switch address one team at a time and log in again for OpenBao tokens. Anything that parses the old token prefix is found in testing. Vault stays up, unchanged, until the last client has moved and its leases have run out.

An OpenBao node that unseals against your HSM

# /etc/openbao/bao.hcl on bao-1, one node of three
ui           = true
cluster_name = "acme-bao"
api_addr     = "https://bao-1.acme.internal:8200"
cluster_addr = "https://bao-1.acme.internal:8201"

default_lease_ttl = "24h"
max_lease_ttl     = "168h"

listener "tcp" {
  address       = "10.40.0.11:8200"
  tls_cert_file = "/etc/openbao/tls/bao-1.crt"
  tls_key_file  = "/etc/openbao/tls/bao-1.key"
}

storage "raft" {
  path    = "/var/lib/openbao/raft"
  node_id = "bao-1"
  retry_join {
    leader_api_addr     = "https://bao-2.acme.internal:8200"
    leader_ca_cert_file = "/etc/openbao/tls/acme-ca.pem"
  }
  retry_join {
    leader_api_addr     = "https://bao-3.acme.internal:8200"
    leader_ca_cert_file = "/etc/openbao/tls/acme-ca.pem"
  }
}

# The key stays in acme's HSM. The PIN comes from BAO_HSM_PIN
# in the service environment, never from this file.
plugin_directory = "/opt/openbao/plugins"
plugin "kms" "pkcs11" {
  command = "openbao-plugin-kms-pkcs11"
}
seal "pkcs11" {
  lib         = "/opt/hsm/lib/libpkcs11.so"
  token_label = "acme-bao"
  key_label   = "bao-root-key-2026"
  mechanism   = "AES_GCM"
}

audit "file" "to-file" {
  description = "Requests and responses, secrets HMAC-hashed, shipped off the node"
  options {
    file_path = "/var/log/openbao/audit.log"
  }
}

What Pilae is responsible for

Where it runs

zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware

Who holds the credentials

You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.

If you leave

The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running OpenBao

Pricing is on request: a fixed price for onboarding, then a monthly price for OpenBao, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size

The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.

High availability

One machine with tested restores, or a replicated setup that keeps serving when a node fails.

Storage and backups

How much data it holds, how long backups are kept, and point-in-time recovery for its database.

Plan and support

Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.

Region

Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.

Sign-on and integrations

Single sign-on, directory sync, mail relays and the other systems the app has to reach.

OpenBao: common questions

Also in engineering and security