Deployment

BitVault ships as a set of OCI images built once, signed, and promoted through environments by digest. The same bytes run from a developer’s laptop (Docker Compose) through staging to production Kubernetes — only configuration, scale, and secrets differ.

What’s in This Section

Page What It Covers
Environments Environment ladder (local → dev → preview → staging → prod), promotion flow, ephemeral previews
Containerization Image catalog, design rules, tagging, supply-chain properties
Kubernetes Namespace layout, PodSecurity, NetworkPolicies, resource management, probes, graceful shutdown
Helm Chart Dependency tiers, values structure, installation, GitOps usage
GitOps with ArgoCD Pull-based deployment, application structure, sync waves, drift detection, rollback
Rollout Strategy Canary analysis, database expand/contract migrations, zero-downtime mechanics
CI/CD Pipelines Pipeline stages, supply-chain security, OIDC cloud auth, monorepo ergonomics

Dependency Tiers

BitVault’s runtime dependencies are grouped into three tiers. The Helm chart and Docker Compose files ship a values.{lite,standard,full}.yaml overlay for each.

Tier Dependencies Intended Use
lite PostgreSQL + MinIO Self-hosted, local development, CI smoke tests
standard lite + Redis + NATS JetStream Production minimum; enables caching, sessions, rate-limiting, and the full event backbone
full standard + OpenSearch SaaS deployments; enables full-text search across the derived index

:::note The standard tier is the recommended baseline for any production deployment. The full tier adds derived search capabilities; PostgreSQL FTS serves as the fallback when OpenSearch is unavailable. :::

Key Design Constraints