Store env files, YAML, JSON, and plain-text configs alongside your containers. Rotate them without rebuilding images, roll back without re-uploading, and mount them into the workloads that need them at the paths your code already expects.
Env files for the classic KEY=valuelayout, YAML for hierarchical config that tools and humans both read well, JSON for machine-generated documents and API payloads, and plain text for everything else — nginx config, properties files, prompt templates, whatever your workload reads.
Configuration changes don't require an image rebuild. Update the content, redeploy the container, done. Your image stays generic and reusable across environments; environment-specific values live next to the project that uses them.
Every update creates a new version. Previous versions are retained so you can pin to a specific one or roll back instantly. A bad config push is a one-command rollback, not a search through git history.
Configs live at the organisation level. Attach them to the projects that need access, then mount them into specific containers at the path your application already reads from. Same lifecycle model as TLS bundles and the rest of the Vault.
Config types
All four types share the same lifecycle — versioning, rotation, rollback, project attachment, container mounting. They differ only in what content they accept.
Env Files
One KEY=value pair per line. Mount the file into a container at the path your runtime reads from (/app/.env, /etc/env, wherever), or use it as the source of truth for environment variable injection. Comments and blank lines are preserved across rotations.
YAML Configs
YAML documents are syntax-checked on upload, so you catch the broken indent before it reaches your container. Ideal for application config files, feature flags, structured preferences, and anywhere you want hierarchy plus comments.
JSON Configs
Strict JSON, validated on upload — no trailing commas, no comments, just well-formed documents. The right shape for machine-generated config, API request templates, schema definitions, and tools that expect JSON natively.
Plain Configs
Arbitrary text, stored byte-for-byte. nginx and Caddy config, Java properties files, INI files, prompt templates, fixtures, license keys — if it's text and your container reads it from disk, this is where it goes.
Platform features
The same capabilities the Vault gives your secrets — versioning, attachment, mounting, audit — applied to your config files.
Versioning
Every update 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 content.
Rollback
Activate any retained version with a single command. Containers mounting the config pick up the rolled-back content on their next deploy — no re-upload, no commit-and-revert in git, no incident bridge.
Attachment
Configs live at the organisation level; projects opt in by attachment. A container can only mount a config if the config 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 config at that path at boot time. Your application reads from a regular filesystem path — no SDK to integrate, no network calls to make.
Validation
YAML and JSON configs are parsed on upload. A malformed document is rejected before it touches your container, so the only way to break a deploy is to push semantically invalid content — never syntactically invalid content.
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 config, 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.
Keep one container image across environments and inject environment-specific values via an env file mounted at the path your runtime expects. Move a service from staging to production by attaching a different env file to the project — no rebuild required.
Manage feature flag configuration as a YAML or JSON document. Roll a flag forward by editing the config; roll it back by activating the previous version. Audit log shows who toggled what and when.
Mount an nginx, Caddy, or Envoy config as a plain config at the path the binary expects. Roll config changes independently of image builds, and rotate without re-deploying the entire image registry.
Ship the prompts your AI workload uses as a plain or YAML config. Iterate on prompts without redeploying your image, and roll back the moment a new prompt produces worse results in production.
Create configs in the console with file pickers and an inline editor. Validation runs on upload so you catch parse errors before they reach a container.
Manage the full lifecycle through Reis (`reis env_file:create`, `reis json_config:rotate`) or Terraform (`bahriya_env_file`, `bahriya_yaml_config`). The same operations, scriptable.
A single inventory view per config type with current version, attached projects, last-rotated timestamp, and a side-by-side diff between versions.
A per-item base rate while the config 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 baking environment values into container images and committing secrets to config repos. Upload, attach, mount, rotate — all in one place.
