Local Vaults

Local vaults keep file bodies in Vaulthalla-managed local state on the host. They are the simplest vault type when the deployment does not need S3-compatible object storage.

When To Use A Local Vault

Use a local vault when:

• The host has enough disk for the stored data.
• You want simple operation without object-storage credentials.
• Low-latency local access matters.
• Backup tooling can capture local Vaulthalla state and PostgreSQL consistently.

Use an S3/R2 vault when object-storage durability, remote bucket workflows, or cloud-side inventory/event tooling is part of the design.

Create

1vh vault create docs \2  --local \3  --desc "Team documents" \4  --quota 50G \5  --on-sync-conflict keep_both

Common options:

Update

1vh vault update docs --quota 100G2vh vault update docs --on-sync-conflict ask

Access Files

Use the web filesystem browser, or use the mounted filesystem surface:

1/mnt/vaulthalla

Access is still controlled by Vaulthalla roles and the daemon. If a user can see the mount but cannot perform an operation, check the vault role assignment first.

Sync Behavior

Local vault sync does not need S3 remote-index logic, request budgets, or S3 Inventory. Local conflict behavior is controlled by:

1vh vault sync set docs --on-sync-conflict keep_both2vh vault sync info docs

Local conflict policies:

Backup Considerations

Local vaults require backup of local Vaulthalla state in addition to PostgreSQL and exported recovery material. A PostgreSQL dump alone is not enough because it does not contain local file bodies.

See Backup And Recovery.