Store TLS bundles, certificates, GPG and SSH keypairs, and encryption keys in one place. Rotate them on demand, roll back instantly, attach them to projects, and mount them into the containers that need them — without leaving the platform.
TLS bundles for HTTPS termination and mTLS, X.509 certificates for client auth and signing, GPG keypairs for package signing and encrypted backups, SSH keypairs for deploy keys and git access, and raw encryption keys for disk and application-level encryption. Each type carries the right metadata for its job — subject, fingerprint, expiry, key algorithm — surfaced automatically.
Sensitive material is encrypted before it ever lands on disk. The console and API surface metadata only — fingerprints, expiry dates, subject lines, public halves of keypairs — so you can see what you have without exposing the secret. Decryption happens on demand, only when a container mounts the item.
Rotation creates a new version and marks it current — your containers pick up the new material on their next deploy. Previous versions are kept for instant rollback, so a bad rotation is a one-command fix, not an incident.
Items live at the organisation level. Attach them to the projects that need access, and only those projects can mount them. Attachment is per-region — your TLS bundle only follows your containers to the regions you actually run in.
Vault item types
Every type supports versioning, rotation, rollback, project attachment, and container mounting. Pick the type that fits your secret material.
TLS
Full bundles — CA certificate, server certificate, and private key in PEM form. Mount them into containers for HTTPS termination, mTLS authentication, and internal service-to-service TLS. Bahriya parses the certificate and surfaces subject, fingerprint, and expiry so you can audit at a glance.
X.509
Single PEM certificates for client authentication, code signing, and anywhere you need a certificate without a paired private key. Same metadata extraction and versioning as TLS bundles, mounted as a single file inside the container.
GPG
Armored public and private keys with an optional passphrase, ready for package signing, encrypted backups, and verified releases. Key ID and fingerprint are extracted on create so you can find the right key without unwrapping it.
SSH
Public and private SSH key pairs for deploy keys, git remotes, and any service that authenticates over SSH. The public half is always visible in the console; the private half is encrypted at rest and only ever materialised inside the containers you mount it into.
Symmetric
Raw cryptographic key material for application-level encryption, envelope encryption, and anywhere you need a symmetric key as an opaque blob. Stored encrypted, mounted as a file or injected as an environment variable.
Configs
Env files, YAML, JSON, and plain-text configs follow the same lifecycle as vault items — versioned, attachable, mountable — but without encryption since the content is not secret. Use them for application configuration that changes alongside your secrets.
Platform features
Rotation, rollback, attachment, and audit — the operations every secret needs over its lifetime, surfaced as first-class capabilities.
Versioning
Every rotation creates a new version and marks it current. Previous versions are retained (the most recent five by default) so you can pin to a specific version or roll back to a known-good one without re-uploading material.
Rollback
Activate any retained version with a single command. Containers that mount the item pick up the rolled-back material on their next deploy, no re-upload, no re-issue, no incident playbook.
Attachment
Items live at the organisation level; projects opt in by attachment. A container can only mount an item if the item is attached to that project, giving you a clean two-step boundary between storage and use.
Mounting
Pick a mount path on the container; Bahriya materialises the decrypted files at that path at boot time. Your application reads from a regular filesystem path — no SDK to integrate, no network calls to make.
Metadata
Certificate subjects, expiry dates, key fingerprints, and algorithms are extracted on create and shown alongside the item. Find the right key, spot expiring certificates, and audit your inventory without ever decrypting the underlying material.
Audit
Create, rotate, activate, attach, detach, and delete actions are all written to the organisation activity log with the actor and timestamp. A complete audit trail across every vault item, no extra service to enable.
Common workflows
The same capability fits a lot of different jobs. Here are some of the patterns we see most often.
For workloads that need to handle TLS directly — mTLS, custom protocols, or certificate-pinned clients — mount a TLS bundle at a chosen path and let your server read the certificate and key from the filesystem. Rotate the bundle, redeploy, done.
Mount a GPG keypair into a build container to sign release artefacts, container images, or downstream package manifests. Rotate the key on a schedule; old signatures stay verifiable because old versions are retained.
Mount an SSH keypair so a worker or cron job can pull a private repository at runtime — without baking the key into the container image, without committing it to a config repo, and without rebuilding when you rotate.
Use an encryption key to protect data your application writes to durable storage. Rotate periodically; previous versions stay available so older records remain decryptable while new writes use the current key.
Create vault items in the console with file pickers, validation, and automatic metadata extraction. No CLI required to get started.
Manage the full lifecycle through Reis (`reis tls_bundle:create`, `reis tls_bundle:rotate`) or Terraform (`bahriya_tls_bundle`). The same operations, scriptable.
A single inventory view per item type with current version, attached projects, expiry, and last-rotated timestamp.
A per-item base rate while the item exists, plus a per-region rate while attached to a project. No surprise charges for rotations or rollbacks.
Coming Soon
Planned for later in 2026/2027, timeline subject to change.
Redis-compatible in-memory data store with persistent snapshots and restore. Session caching, queues, pub/sub, and real-time data — without Redis licensing concerns.
Managed relational database with automated backups, point-in-time recovery, and regional deployment. A production-ready RDBMS for structured data and transactional workloads.
Managed PostgreSQL with automated backups, point-in-time recovery, and regional deployment. Advanced SQL features, JSONB support, and extensions for modern application workloads.
A globally distributed, multi-region document database with built-in replication. Conflict-free sync across regions for offline-first applications and geo-distributed NoSQL workloads.
S3-compatible object storage for files, media, backups, and static assets. Accessible from your containers or directly via standard S3 APIs and client libraries.
Global content delivery network for static assets, media, and API acceleration. Edge caching across multiple PoPs with automatic origin pull from your containers or object storage.
Your own dedicated API gateway in front of your services. JWT/OAuth2/OIDC and key auth, fine-grained rate limiting and quotas, request/response transformations, circuit breakers, canary releases and traffic splitting, gRPC and WebSocket proxying, and rich per-route analytics — all configured declaratively via Reis or the Console.
Managed RabbitMQ for asynchronous messaging between containers. Multi-region clusters, project-private networking, and per-node billing — same operational model as Memcached.
Stop wiring secrets through container images and CI variables. Upload, attach, mount, rotate — all in one place.
