HashiCorp Vault on an Offshore VPS

Vault solves three main problems. First, static secret storage - API keys, database passwords, signing keys - encrypted at rest and accessible only through authenticated, audited reads. Second, dynamic secret generation - Vault can issue short-lived credentials to AWS, GCP, Postgres, MySQL, MongoDB, RabbitMQ, and dozens of other backends on demand, with automatic revocation when the lease expires. Third, encryption as a service via the transit engine - your applications send plaintext, Vault returns ciphertext, without applications ever holding the master key. Vault is exactly the kind of system you do not want to trust to a SaaS. Every secret in your organization potentially passes through it - database passwords, signing keys, OAuth secrets, TLS certificate private keys. The blast radius of a managed Vault provider being compromised, subpoenaed, or going offline is enormous. Self-hosting Vault on an offshore VPS means the master keys, the unseal shards, and the secret material all live on infrastructure you own. The BSL license change in 2023 added a second reason to self-host - if you depended on HCP Vault (the managed offering), the path forward is uncertain for commercial use. OpenBao is the Apache 2.0 community fork that runs on the same protocol. Both work fine on a single offshore VPS for small to mid-size deployments.

Vault itself is a single Go binary with very modest resource needs. A small Vault server handles a few hundred secrets and a steady token issuance rate on 1 to 2 GB RAM and 1 vCPU. The real sizing question is the storage backend. Vault supports several - integrated raft storage (recommended since 1.4), Consul (legacy), Postgres, MySQL, S3, and others. For a single-VPS deployment, integrated raft storage is the right choice. It is built into the Vault binary, requires no external dependencies, and supports HA when you add more nodes later. Disk usage is small - a few hundred MB at most for typical secret volumes. Plan on a 40 to 80 GB SSD VPS just so you have room for audit logs to grow. For HA, run three Vault nodes across three separate offshore VPSes with raft storage. They form a Raft consensus cluster - one leader, two followers. Any node can serve reads after authentication; writes go through the leader. If the leader fails, the cluster elects a new one. This pattern survives a single-VPS failure with no manual intervention. For most small teams, a single-node Vault with reliable backups is enough; the cost of three-node HA is real complexity.

Install Vault from the HashiCorp apt repository: `wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg && echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" > /etc/apt/sources.list.d/hashicorp.list && apt update && apt install -y vault`. Configure Vault at `/etc/vault.d/vault.hcl`: set `ui = true`, define a `storage "raft"` block with `path = "/opt/vault/data"` and `node_id = "node1"`, a `listener "tcp"` block with `address = "0.0.0.0:8200"` and `tls_cert_file` and `tls_key_file` paths to your TLS cert. Set `api_addr = "https://vault.yourdomain.tld:8200"` and `cluster_addr = "https://YOUR_VPS_IP:8201"`. Create the data dir: `mkdir -p /opt/vault/data && chown vault:vault /opt/vault/data`. Start Vault: `systemctl enable --now vault`. Initialize: `VAULT_ADDR=https://vault.yourdomain.tld:8200 vault operator init`. Save the five unseal keys and the initial root token immediately - they cannot be recovered. Unseal Vault with three of the five keys: `vault operator unseal` (run three times, paste a different key each time). Log in with the root token: `vault login`. Immediately create a less-privileged admin policy and a personal token, and store the root token offline. Enable an audit backend: `vault audit enable file file_path=/var/log/vault_audit.log` so every secret access is recorded.