Self-Host HashiCorp Vault on a VPS

This guide walks you through installing and configuring HashiCorp Vault on your own VPS, giving you a centralized secrets management system for API keys, database credentials, and other sensitive data. You’ll end up with a working Vault server using the filesystem storage backend, TLS enabled, and a basic understanding of how to store and retrieve secrets. Before starting, you need a VPS with Ubuntu 22.04 or 24.04, root access, and a domain name pointing to the server’s IP address.

What You’ll Need

• A VPS with at least 1 GB RAM and 10 GB disk space (Ubuntu 22.04/24.04 recommended)
• Root or sudo access to the server
• A domain name (or subdomain) pointing to your VPS’s public IP address (for TLS)
• Basic familiarity with the command line and systemd

Step-by-Step

1. Update the system and install prerequisites. SSH into your VPS and run sudo apt update && sudo apt upgrade -y. Then install required tools: sudo apt install -y curl unzip gnupg lsb-release.
2. Install Vault. Download the official Vault binary from HashiCorp’s releases page. For the latest version (check https://releases.hashicorp.com/vault/), use wget https://releases.hashicorp.com/vault/1.17.6/vault_1.17.6_linux_amd64.zip (replace version if newer). Unzip it, move the binary to /usr/local/bin/, and verify with vault --version.
3. Create a dedicated system user. Run sudo useradd --system --home /etc/vault --shell /bin/false vault to create a non-login user for Vault.
4. Create the configuration directory and file. Create /etc/vault with sudo mkdir -p /etc/vault. Then create /etc/vault/vault.hcl with the following content (adjust api_addr to your domain):
   storage "file" {
path = "/opt/vault/data"
}
listener "tcp" {
address = "0.0.0.0:8200"
tls_cert_file = "/etc/vault/tls/vault.crt"
tls_key_file = "/etc/vault/tls/vault.key"
}
api_addr = "https://vault.example.com:8200"
ui = true
disable_mlock = true
   Note: disable_mlock is set to true for simplicity; in production, consider removing it and granting the vault user the ability to mlock (see setcap cap_ipc_lock=+ep /usr/local/bin/vault).
5. Create the data directory. Run sudo mkdir -p /opt/vault/data and set ownership: sudo chown -R vault:vault /opt/vault /etc/vault.
6. Set up TLS certificates. For a production setup, use Let’s Encrypt with certbot: sudo apt install certbot and obtain a certificate for your domain: sudo certbot certonly --standalone -d vault.example.com. Then copy the cert and key to /etc/vault/tls/ and set permissions: sudo mkdir -p /etc/vault/tls && sudo cp /etc/letsencrypt/live/vault.example.com/fullchain.pem /etc/vault/tls/vault.crt && sudo cp /etc/letsencrypt/live/vault.example.com/privkey.pem /etc/vault/tls/vault.key && sudo chown -R vault:vault /etc/vault/tls.
7. Create a systemd service file. Create /etc/systemd/system/vault.service with:
   [Unit]
   Description=HashiCorp Vault
   After=network.target

   [Service]
   User=vault
   Group=vault
   ExecStart=/usr/local/bin/vault server -config=/etc/vault/vault.hcl
   ExecReload=/bin/kill -HUP $MAINPID
   KillSignal=SIGINT
   Restart=on-failure
   LimitNOFILE=65536

   [Install]
WantedBy=multi-user.target

8. Start and enable Vault. Run sudo systemctl daemon-reload, then sudo systemctl start vault and sudo systemctl enable vault. Check status with sudo systemctl status vault.
9. Initialize Vault. Set the environment variable export VAULT_ADDR='https://vault.example.com:8200'. Then run vault operator init -key-shares=1 -key-threshold=1 (for testing; use 5 and 3 in production). Save the unseal key and root token securely. Vault is now initialized but sealed.
10. Unseal Vault. Run vault operator unseal and enter the unseal key when prompted. Repeat if you used multiple key shares. After unsealing, log in with vault login and the root token.
11. Enable a secrets engine and store a test secret. Run vault secrets enable -path=secret kv-v2 (for KV v2). Then store a secret: vault kv put secret/myapp password=supersecret. Retrieve it with vault kv get secret/myapp.
12. Access the UI (optional). Navigate to https://vault.example.com:8200/ui in your browser, log in with the root token, and manage secrets visually.

Common Mistakes

• Forgetting to unseal after reboot. Vault seals on restart; you must unseal manually or use an auto-unseal mechanism like cloud KMS or a separate unseal service.
• Using the root token in production. Root tokens are powerful; create a policy with least privilege and use that for daily operations.
• Exposing Vault to the public internet without TLS. Always use TLS. Vault sends secrets in plaintext if not.
• Setting disable_mlock without understanding the risk. In production, mlock prevents memory swapping; disabling it can expose secrets in swap. Use setcap instead.
• Using a weak unseal key threshold. A single key share is convenient but insecure. Use at least 3 shares and a threshold of 2.

Tips

• Back up your unseal keys and root token. Store them in a password manager or offline. Losing them means losing access to all secrets.
• Use a dedicated VPS for Vault. Don’t run other services on the same server to reduce attack surface.
• Enable audit logging. Run vault audit enable file file_path=/var/log/vault_audit.log to track access.
• Use dynamic secrets where possible. For databases, enable the database secrets engine to generate short-lived credentials instead of static ones.
• Set up a backup routine. Backup the /opt/vault/data directory and the unseal keys. Test restores.

Troubleshooting

• Vault service fails to start. Check logs with sudo journalctl -u vault -f. Common issues: permissions on config/data directories, invalid config syntax, or missing TLS files.
• Cannot connect to Vault. Check if the port 8200 is open: sudo ufw status or ss -tulpn | grep 8200. Ensure your VPS firewall allows it. Also verify VAULT_ADDR is set correctly.
• TLS errors in browser. Ensure your certificate is valid and not expired. Use curl -v https://vault.example.com:8200/v1/sys/health to test.
• Vault is sealed after restart. Run vault operator unseal again. Consider setting up auto-unseal if this is frequent.
• Permission denied when reading secrets. Check your token’s policy: vault token capabilities. Create a policy that grants read on the path you need.

Frequently Asked Questions

Q: Can I use Vault without TLS if it’s behind a VPN?
A: Technically yes, but it’s risky. If the VPN is compromised, secrets are exposed. Always use TLS even in private networks.

Q: What is the difference between KV v1 and KV v2?
A: KV v2 supports versioning and metadata, allowing you to roll back to previous secret values. KV v1 is simpler but overwrites on write.

Q: How do I rotate the root token?
A: Run vault token create -policy=root -ttl=1h to create a temporary root token, then revoke the original. Or use vault operator generate-root with unseal keys.

Q: Can I use Vault for SSH key management?
A: Yes, Vault has an SSH secrets engine that can generate one-time SSH passwords or sign SSH keys.

Q: How do I upgrade Vault?
A: Download the new binary, replace the old one, and restart the service. Always back up data and unseal keys before upgrading.

Q: What happens if I lose all unseal keys?
A: You lose access to all secrets. There is no recovery. This is why backing up keys is critical.

Related

• MCP in Production: Security Failures Behind the Backdoor Label
• Nothing Phone 2 Waterproof? IP54 Rating Explained
• Satellite Internet Equipment & Installation Guide