Vault Community for a 10-person team: what you actually run

For a small team, HashiCorp Vault Community is a stateful cluster you operate, not a program you install. HashiCorp recommends at least five servers for production integrated storage and discourages a single server. Each node starts sealed after every restart and, with the default seal, needs people holding key shares to open it. Snapshots are manual in Community, so you schedule them yourself. Audit logging is off until you enable it, and once on, Vault refuses requests it can't log. Namespaces, replication and automated snapshots are Enterprise features. None of that is a reason to avoid Vault. It is the work you sign up for, and it pays off when you need what only Vault does well: credentials generated on demand, PKI, encryption as a service. If what you need is a shared place for .env files and API keys, it's a lot of machinery for that job.

The guide to self-hosting a secrets vault compares six options side by side. This post goes deeper on one, with the list of things a ten-person team would actually run.

The cluster: three or five nodes

Vault's integrated storage replicates data across nodes with Raft. For N nodes, quorum needs ceil((N + 1) / 2) of them, and "if a cluster cannot achieve quorum, the cluster becomes unavailable and cannot commit new logs" (Vault: integrated storage). The arithmetic:

HashiCorp recommends "at least 5 servers for a standard production deployment" and "strongly discourage[s] single server deployments for production use due to the high risk of data loss." A small team can choose three nodes and accept tolerating one failure, but it's a choice to write down, because a second failure, or one failure during an upgrade, stops writes.

Each node is a machine you patch, monitor, give TLS certificates and keep in its own failure domain. Three nodes in one rack, or three containers on one host, tolerate one process crash and nothing else.

Sealed after every restart

"When you start a Vault server, it starts in a sealed state", able to read its storage but not decrypt it (Vault: seal/unseal). With the default Shamir seal, the unseal key is split into shares, a threshold of them is needed to open the node, and "you must unseal each node with the required threshold of shares." A node stays unsealed until, among other things, "you restart the server."

For a small team that turns into a people problem:

• Which of you hold shares, and can a threshold of them be reached at any hour?
• What happens during a holiday, or after someone leaves? Shares held by a former employee need re-keying.
• Every kernel update, host reboot or container reschedule seals a node until someone acts.

The pain is long-standing. An open feature request from July 2022 describes it: after maintenance, "a node becomes sealed after the maintenance and requires either manual unseal (inconvenient to do all the time)", or reliance on an external provider, or a second Vault cluster with the same problem (GitHub: hashicorp/vault #16419).

Auto-unseal moves the problem rather than removing it. Vault asks a cloud KMS, or another Vault through the transit seal, to decrypt its root key at startup. The seal configuration lists AWS KMS, Azure Key Vault, Google Cloud KMS, OCI KMS, AliCloud KMS and transit without an Enterprise badge, while the PKCS#11 HSM seal is marked Enterprise (Vault: seal configuration). With auto-unseal you get recovery keys instead of unseal keys, and a hard dependency: "If the seal mechanism or its keys are permanently deleted, then the Vault cluster cannot be recovered, even from backups."

The glossary entry on vault unsealing has the short version.

Backups you schedule yourself

"All Vault editions support data backup and restoration with manual snapshots", and "Vault Enterprise adds support for configurable automated snapshots to local and cloud storage" (Vault: snapshots). In Community, that means your own job:

vault operator raft snapshot save "vault-$(date +%F).snap"

The job needs a Vault token with permission to take snapshots, which is itself a credential to store and rotate. Then there's where the snapshot goes, how long you keep it, and how you'd restore it. A snapshot is only useful if you can still open what's in it: with Shamir, that means the unseal shares; with auto-unseal, the same KMS key. Keep snapshots and what opens them apart, and test a restore into a scratch cluster before you need one. Backing up a secrets vault without backing up the secrets looks at backups across designs.

Audit devices that can stop the cluster

"When you initialize a new Vault cluster, auditing is disabled" (Vault: audit devices). Once you enable a device, Vault takes the log seriously: if no enabled device accepts an entry, "Vault refuses to service the corresponding API request", and when all devices are unavailable, "Vault in effect becomes unavailable as well." HashiCorp's advice is to "enable at least two audit devices."

That's the right design for evidence and a new outage mode: a full disk under the audit log is now a Vault outage. Budget for log shipping, rotation and disk alerts. Values are written as HMAC-SHA256 hashes by default, so the logs prove access without revealing secrets.

Upgrades

Vault's upgrade documentation asks you to review "the important changes for each major version between your current version and the upgrade target", and lists as a prerequisite: "Identify and notify enough people with unseal shards to meet the unseal threshold after restart" (Vault: upgrading). Every upgrade is a sequence of restarts, so every upgrade is also an unseal exercise on each node.

What Community doesn't include

The Enterprise section of Vault's documentation lists, among others, replication, namespaces, HSM support, seal wrapping, control groups and automated snapshots, and says these capabilities require an Enterprise license (Vault Enterprise). For a small team, the ones that matter most:

• Replication and disaster recovery. No second cluster kept in step for you. Your disaster recovery is your snapshots and your rebuild procedure.
• Namespaces. One tenant space. Separating teams or clients is done with paths and policies.
• Automated snapshots. Covered above.

Vault's license matters too: versions 1.15 and later use the Business Source License 1.1, with each version converting to MPL 2.0 after four years (Vault license). OpenBao has the same architecture, so the same operational list applies; the self-hosting guide covers it.

The managed option: HCP Vault Dedicated

If the operational list is the problem, HashiCorp runs Vault for you. HCP Vault Dedicated has three tiers (HCP Vault Dedicated: tiers and features):

• Development: "a single-node Vault instance with a 25 client count limit" that "is not subject to the HashiCorp Cloud SLA", without high availability or snapshot restoration. Not for production.
• Essentials: highly available clusters "with a 99.9% SLA", audit log streaming and backup and restore.
• Standard: Essentials plus performance replication, Sentinel policies and control groups.

Pricing is an hourly base cost by tier, size and region, and Essentials and Standard add "an additional flat-rate hourly cost per Vault client", so the bill grows with every machine and pipeline that authenticates. Check the current rates for your region before comparing.

When Vault earns its keep

Vault is worth this list when you need what it does that simpler stores don't:

• Dynamic secrets: database users created per service and revoked when their lease ends. Why a blind-server vault can't issue dynamic secrets explains why that requires a server that can decrypt.
• PKI: short-lived internal TLS certificates issued on request.
• Encryption as a service: applications encrypting data with keys they never see.
• Many services and a platform team to own the cluster, its policies and its on-call.

For ten people sharing .env files, cloud credentials and a handful of API keys, those features may go unused while the cluster still needs its five nodes, its share holders and its snapshot job.

A smaller thing to run

Self-hosted on the Enterprise plan, Crunu is one server process with one database, SQLite, Postgres or Cloudflare D1, on your own Docker host, Cloudflare Workers, Vercel or Google Cloud Run, and it moves between them with one archive. There's no unseal step, because the server never holds a key that decrypts values: encryption happens in the browser and the agent, which is client-side encryption, and the server stores ciphertext and metadata such as names. A restart is just a restart. Backups are an archive without plaintext values plus the server's .env, kept separately. There's no high-availability guide yet, and no dynamic secrets, PKI or encryption as a service, by design. Crunu vs HashiCorp Vault lists where Vault is stronger, and Infisical vs HashiCorp Vault compares Vault with another self-hosted option.

Checklist before you commit to Vault Community

• Three or five nodes in separate failure domains, with TLS and monitoring
• Share holders named, reachable, and re-keyed when someone leaves; or an auto-unseal KMS key you'll never delete
• A snapshot job, an off-cluster store, and a tested restore
• Two audit devices and alerts on their disks
• An upgrade procedure that includes unsealing every node
• A use for dynamic secrets, PKI or transit that justifies the rest

Sources

• Integrated storage, HashiCorp Vault docs, checked October 30, 2026.
• Seal/Unseal, HashiCorp Vault docs, checked October 30, 2026.
• Seal configuration, HashiCorp Vault docs, checked October 30, 2026.
• Allow Vault to auto-unseal restarted instances when in HA mode, hashicorp/vault issue #16419, checked October 30, 2026.
• Snapshots, HashiCorp Vault docs, checked October 30, 2026.
• Audit devices, HashiCorp Vault docs, checked October 30, 2026.
• Upgrading Vault, HashiCorp Vault docs, checked October 30, 2026.
• Vault LICENSE, hashicorp/vault on GitHub, checked October 30, 2026.
• Vault Enterprise, HashiCorp Vault docs, checked October 30, 2026.
• HCP Vault Dedicated tiers and features, HashiCorp Cloud Platform docs, checked October 30, 2026.