How to Set Up HashiCorp Vault on a VPS: TLS, Policies, and Backups

HashiCorp Vault is an enterprise-grade secrets management tool designed to securely store, access, and manage sensitive data such as API keys, passwords, certificates, and encryption keys. This guide intends to teach you a full setup for Secrets Management with HashiCorp Vault on VPS.

Unlike traditional methods, Vault provides centralized secrets management with strong encryption, access control, and audit capabilities.

Key features of HashiCorp Vault include:

• Centralized Secret Storage: Encrypts secrets at rest and stores them in a backend of your choice.
• Dynamic secrets: Generates short-lived credentials on demand and can rotate and revoke them automatically.
• Encryption as a service: Apps encrypt and decrypt without handling encryption keys directly.
• Access control policies: Use path-based rules to grant fine‑grained permissions.
• Audit logging: Records Vault activity for security reviews and compliance.
• High availability: Runs in clusters with failover for production reliability.

You can proceed to the following steps to set up HashiCorp Vault on a VPS, including installation, configuration, and secrets management.

If you need a reliable VPS server, you can visit PerLod Hosting, which offers the best plans to deploy HashiCorp Vault secret management.

Prerequisites for Setting Up Secrets Management with HashiCorp Vault on VPS

To set up secrets management with HashiCorp Vault on VPS, you need some requirements. Be sure to meet these prerequisites:

• A VPS running Ubuntu 22.04 or later.
• Root or sudo access to the server.
• At least 2GB RAM and 20GB disk space.
• SSH access to your VPS.
• A domain name or IP address for accessing Vault.

If you need a reliable Linux VPS with full sudo access and public networking, PerLod provides the best services for your needs.

Connect to your VPS via SSH and update the system packages with the commands below:

sudo apt update && sudo apt upgrade -y

Install required dependencies for adding the HashiCorp repository:

sudo apt install gpg wget curl -y

Once you are done with these, proceed to the following steps to set up Secrets Management with HashiCorp Vault on VPS.

Step 1. Install HashiCorp Vault

To install Vault safely on your VPS, you can use HashiCorp’s official APT repository so the package can be installed and updated through your system’s package manager.

Add the HashiCorp GPG key to verify package authenticity with the command below:

wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null

Add the HashiCorp repository to your system with the following command:

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

Update the package index and install Vault with the following commands:

sudo apt update
sudo apt install vault -y

You can verify the installation by checking its version:

vault --version

Step 2. Create HashiCorp Vault User and Directories

At this point, you need to create a dedicated Vault user and the standard directories Vault needs for data, TLS files, and configuration. This allows Vault to run as a non-root user, separates its files into predictable locations, and applies restrictive permissions.

Create a dedicated system user for Vault with the command below:

sudo useradd --system --home /etc/vault.d --shell /bin/false vault

Create required directories for Vault data and configuration by using the following commands:

sudo mkdir -p /opt/vault/data
sudo mkdir -p /opt/vault/tls
sudo mkdir -p /etc/vault.d

Then, set up the correct ownership and permissions with the following commands:

sudo chown -R vault:vault /opt/vault
sudo chown -R vault:vault /etc/vault.d
sudo chmod 750 /opt/vault/data
sudo chmod 750 /etc/vault.d

Step 3. Generate TLS Certificates for Vault Secrets Management

TLS is required to protect Vault traffic in transit, especially on a VPS exposed to the internet. In this step, we want to generate a private key and a self‑signed certificate for testing.

For production, replace the self‑signed cert with one issued by a trusted CA to avoid errors.

Generate a private key with the following command:

sudo openssl genrsa -out /opt/vault/tls/vault-key.pem 2048

Create a certificate signing request configuration file with the command below:

sudo tee /opt/vault/tls/vault-csr.conf > /dev/null << EOF
[req]
default_bits = 2048
prompt = no
encrypt_key = no
default_md = sha256
distinguished_name = dn
req_extensions = v3_req

[dn]
CN = vault.yourdomain.com
C = US
ST = State
L = City
O = Organization
OU = IT Department

[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = vault.yourdomain.com
DNS.2 = localhost
IP.1 = YOUR_VPS_IP
IP.2 = 127.0.0.1
EOF

Note: Replace vault.yourdomain.com with your actual domain and YOUR_VPS_IP with your VPS IP address.

Now use the following command to generate the CSR:

sudo openssl req -new -key /opt/vault/tls/vault-key.pem -out /opt/vault/tls/vault.csr -config /opt/vault/tls/vault-csr.conf

Create a self-signed certificate, which is valid for 365 days:

sudo openssl x509 -req -in /opt/vault/tls/vault.csr -signkey /opt/vault/tls/vault-key.pem -out /opt/vault/tls/vault-cert.pem -days 365 -extensions v3_req -extfile /opt/vault/tls/vault-csr.conf

Once you are done, set the correct permissions on the certificate files with the following commands:

sudo chown vault:vault /opt/vault/tls/*
sudo chmod 600 /opt/vault/tls/vault-key.pem
sudo chmod 644 /opt/vault/tls/vault-cert.pem

Step 4. Create Vault Configuration File

At this point, you must create the vault.hcl file, which is the main server config that tells Vault where to store data, how to accept client connections, and which addresses it should announce to clients and other Vault nodes.

sudo tee /etc/vault.d/vault.hcl > /dev/null << EOF
# Storage Backend - Raft Integrated Storage
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "node1"
}

# TCP Listener with TLS
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/vault-cert.pem"
  tls_key_file  = "/opt/vault/tls/vault-key.pem"
}

# API and Cluster Addresses
api_addr      = "https://YOUR_VPS_IP:8200"
cluster_addr  = "https://YOUR_VPS_IP:8201"

# Enable UI
ui = true

# Disable memory locking (required for non-root users)
disable_mlock = true

# Log level
log_level = "Info"
EOF

Configuration Explanation:

• path: Local directory where Raft stores data and snapshots.
• node_id: Unique identifier for this Vault node in a cluster.
• address = “0.0.0.0:8200”: Binds to all network interfaces on port 8200.
• tls_cert_file: Path to TLS certificate.
• tls_key_file: Path to private key for TLS.
• api_addr: External URL for Vault API, which is used by clients.
• cluster_addr: Internal address for cluster communication on port 8201.
• ui = true: Enables the web interface at https://YOUR_VPS_IP:8200/ui.
• disable_mlock = true: Disables memory locking, required when running as a non-root user; prevents swapping secrets to disk.
• log_level: Options are Trace, Debug, Info, Warn, Error. Info is recommended for production.

Also, set the correct permissions on the configuration file with the following commands:

sudo chown vault:vault /etc/vault.d/vault.hcl
sudo chmod 640 /etc/vault.d/vault.hcl

Step 5. Configure Vault as a System Service

To run Vault reliably in the background and start it automatically after reboots, you can set it up as a systemd service.

To create the systemd service file, run the command below:

sudo tee /lib/systemd/system/vault.service > /dev/null << 'EOF'
[Unit]
Description="HashiCorp Vault - A tool for managing secrets"
Documentation=https://developer.hashicorp.com/vault/docs
ConditionFileNotEmpty=/etc/vault.d/vault.hcl
Requires=network-online.target
After=network-online.target

[Service]
Type=notify
User=vault
Group=vault
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
SecureBits=keep-caps
AmbientCapabilities=CAP_IPC_LOCK
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
NoNewPrivileges=yes
ExecStart=/usr/bin/vault server -config=/etc/vault.d/vault.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
LimitNOFILE=65536
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target
EOF

Set proper permissions on the service file with the following command:

sudo chmod 644 /lib/systemd/system/vault.service

Reload systemd to recognize the new service:

sudo systemctl daemon-reload

Enable and start the Vault service with the commands below:

sudo systemctl enable vault
sudo systemctl start vault

Check the service status that is active and running with the following command:

sudo systemctl status vault

To check logs and errors, you can use the command below:

sudo journalctl -u vault -n 50 --no-pager

Step 6. Set Vault CLI Environment Variables

To make the Vault CLI talk to your server without repeating flags on every command, you can set a few environment variables in your shell.

Set up environment variables for interacting with Vault with the commands below:

export VAULT_ADDR='https://YOUR_VPS_IP:8200'
export VAULT_SKIP_VERIFY=1

The VAULT_SKIP_VERIFY=1 skips TLS certificate verification. It is only for self-signed certs in development; do not use it in production with proper certificates.

To make these settings permanent, add them to your shell profile with the commands below:

echo 'export VAULT_ADDR="https://YOUR_VPS_IP:8200"' | sudo tee -a /etc/profile.d/vault.sh
echo 'export VAULT_SKIP_VERIFY=1' | sudo tee -a /etc/profile.d/vault.sh
sudo chmod 644 /etc/profile.d/vault.sh
source /etc/profile.d/vault.sh

Check Vault status with the following command:

vault status

You should see the following output that Vault is sealed and uninitialized:

Sealed: true
Initialized: false

Step 7. Initialize and Unseal Vault

Vault initialization will create the unseal key shares and the first (root) admin token, which must be captured immediately and stored securely, because Vault will not show them again and losing them can lock you out permanently.

Initialize Vault to generate unseal keys and root token with the command below:

vault operator init

This command generates 5 unseal keys by default and 1 root token.

Example output:

Unseal Key 1: 4jYbl2CBIv6SpkKj6Hos9iD32k5RfGkLzlosrrq/JgOm
Unseal Key 2: B05G1DRtfYckFV5BbdBvXq0wkK5HFqB9g2jcDmNfTQiS
Unseal Key 3: Arig0N9rN9ezkTRo7qTB7gsIZDaonOcc53EHo83F5chA
Unseal Key 4: 6DJ26by8OC0YcbMXBZO9wJfRb0cI5LkQpDMfnVSPFTZe
Unseal Key 5: GqQ8VYuOzp8l9DdNMiLFSQmm5aDDxQqGIsBjGsjRSSfl

Initial Root Token: hvs.6j6aLuAq33GcdLQaHXRgztpM

Vault initialized with 5 key shares and a key threshold of 3.

Essential security notes:

• Save these keys and token securely in multiple locations.
• Never commit them to version control.
• At least 3 keys are required to unseal the Vault.
• The root token has unlimited privileges; use it only for initial setup.
• Loss of unsealed keys means permanent data loss.

For enhanced security, you can customize the key shares and threshold with the command below:

vault operator init -key-shares=5 -key-threshold=3

For production environments, consider using PGP encryption for unseal keys:

vault operator init \
  -key-shares=5 \
  -key-threshold=3 \
  -pgp-keys="keybase:user1,keybase:user2,keybase:user3,keybase:user4,keybase:user5"

After initialization, Vault starts in a sealed state. You must unseal it using at least 3 of the 5 unseal keys with the command below:​

vault operator unseal

When prompted, enter the first unseal key. Repeat this command two more times with different keys:

vault operator unseal
# Enter second key

vault operator unseal
# Enter third key

After the third key, check the status:

vault status

Important note: Vault will seal automatically when:

• The service is restarted.
• The server reboots.
• An explicit seal command is issued.
• A storage error occurs.

You must unseal the Vault every time it seals.

For production environments, you can implement auto-unseal using cloud KMS or HSM.

Step 8. Vault Authentication with Root Token

At this point, you can log in to Vault using the initial root token created during initialization, so you can perform the first setup tasks like enabling auth methods, creating policies, and configuring secrets engines.

Log in to Vault using the root token with the command below:

vault login

When prompted, enter your root token.

Alternatively, you can use this command:

vault login hvs.6j6aLuAq33GcdLQaHXRgztpM

Once authenticated, the token is stored in ~/.vault-token.

Root Token Warnings:

• Root tokens have unrestricted access to all Vault operations and should only be used for initial configuration.
• Revoke root token after creating administrative policies.
• Use the principle of least privilege for all other operations.

Step 9. Enable and Configure Vault Secrets Engines

Secrets engines are how Vault actually stores and serves sensitive data or generates it. In this step, we want to enable the KV v2 secrets engine and then practice the core workflows.

Enable KV Version 2 Secrets Engine:

The KV (Key-Value) v2 engine provides versioned secret storage. To enable it, use the command below:

vault secrets enable -path=secret kv-v2

Check enabled secrets engines with the command below:

vault secrets list

Store Secrets:

Now you can store a secret with multiple key-value pairs with the command below:

vault kv put secret/myapp/database \
username="dbuser" \
password="SecureP@ssw0rd123" \
host="db.example.com" \
port="5432"

To store secrets from a file, you can run the command below:

vault kv put secret/myapp/api @api-credentials.json

Read Secrets:

To read the entire secret, you can use:

vault kv get secret/myapp/database

Or you can get a specific field only:

vault kv get -field=password secret/myapp/database

To get the secret in a JSON format, you can use this command:

vault kv get -format=json secret/myapp/database

Version Management:

To update a secret, you can run:

vault kv put secret/myapp/database \
username="dbuser" \
password="NewSecureP@ssw0rd456" \
host="db.example.com" \
port="5432"

This creates version 2. To read a specific version, you can run:

vault kv get -version=1 secret/myapp/database

View version history metadata with the command below:

vault kv metadata get secret/myapp/database

Rollback to the previous version with:

vault kv rollback -version=1 secret/myapp/database

This creates a new version (version 3) with the same data as version 1.

Delete and Destroy Secrets:

For a soft delete, you can use this command:

vault kv delete secret/myapp/database

Undelete a soft-deleted secret with the command below:

vault kv undelete -versions=2 secret/myapp/database

Permanently destroy specific versions with this:

vault kv destroy -versions=2 secret/myapp/database

Warning: Destroyed versions cannot be recovered.

Delete all versions and metadata with the command below:

vault kv metadata delete secret/myapp/database

Also, you can list all secrets at a path with this:

vault kv list secret/myapp

Step 10. Configure Vault Access Policies

Access policies are Vault’s core authorization mechanism, which define exactly who can do what, on which paths, using clear capabilities.

Policy Capabilities include:

• create: Create new data at a path.
• read: Read data from a path.
• update: Update existing data at a path.
• delete: Delete data at a path.
• list: List keys at a path.
• sudo: Gain root-protected access to paths.
• deny: Explicitly deny access.

Read-Only Policy:

To create a policy file for read-only access, you can use this command:

tee read-only-policy.hcl > /dev/null << 'EOF'
# Read-only access to all secrets under secret/myapp/
path "secret/data/myapp/*" {
  capabilities = ["read", "list"]
}

# Allow reading metadata
path "secret/metadata/myapp/*" {
  capabilities = ["read", "list"]
}

# Allow token self-management
path "auth/token/lookup-self" {
  capabilities = ["read"]
}

path "auth/token/renew-self" {
  capabilities = ["update"]
}
EOF

Then, write the policy to Vault:

vault policy write read-only read-only-policy.hcl

Admin Policy:

You can create a comprehensive admin policy file with:

tee admin-policy.hcl > /dev/null << 'EOF'
# Read system health check
path "sys/health" {
  capabilities = ["read", "sudo"]
}

# Manage ACL policies
path "sys/policies/acl/*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

# Manage authentication methods
path "sys/auth/*" {
  capabilities = ["create", "read", "update", "delete", "sudo"]
}

path "auth/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Manage secrets engines
path "sys/mounts/*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

# List existing secrets engines
path "sys/mounts" {
  capabilities = ["read"]
}

# Manage the Key-Value secrets engine
path "secret/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Manage audit devices
path "sys/audit/*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

# Read audit device configuration
path "sys/audit" {
  capabilities = ["read", "sudo"]
}
EOF

Write the admin policy to the Vault:

vault policy write admin admin-policy.hcl

Application Policy:

Create a policy for application access with the command below:

tee app-policy.hcl > /dev/null << 'EOF'
# Application can create, read, update secrets under its path
path "secret/data/myapp/*" {
  capabilities = ["create", "read", "update"]
}

# Application can list secrets
path "secret/metadata/myapp/*" {
  capabilities = ["list", "read"]
}

# Application can manage its own token
path "auth/token/renew-self" {
  capabilities = ["update"]
}

path "auth/token/lookup-self" {
  capabilities = ["read"]
}
EOF

Write the policy:

vault policy write app-policy app-policy.hcl

You can list all policies and read a specific policy with the commands below:

vault policy list
vault policy read admin

Vault can show you what policy is needed for a specific operation. To do this, you can run:

vault kv get -output-policy secret/myapp/database

Step 11. Configure Vault Authentication Methods

Authentication is how users and applications prove who they are to Vault before any policy rules are applied. In this step, we want to configure a few common auth methods, create credentials, and confirm everything is enabled and working.

Method1. Token Authentication: Tokens are the default authentication method.

To create a token with specific policies, you can run:

vault token create -policy=read-only -ttl=1h

To create a token with multiple policies, you can use:

vault token create -policy=read-only -policy=app-policy -ttl=24h

Method 2. UserPass Authentication: You can also use the userpass authentication method by enabling it with the command below:

vault auth enable userpass

Create a user with policies attached:

vault write auth/userpass/users/mila \
  password="SecurePassword123!" \
  policies="read-only,app-policy"

Log in with username and password:

vault login -method=userpass username=mila

Change a user’s password by using the command below:

vault write auth/userpass/users/mila/password password="NewPassword456!"

Method 3. AppRole Authentication: AppRole is designed for automated workflows and applications.

Enable AppRole authentication with this command:

vault auth enable approle

Create an AppRole with policies:

vault write auth/approle/role/my-app \
token_policies="app-policy" \
token_ttl=1h \
token_max_ttl=4h \
secret_id_ttl=24h

Get the RoleID like a username:

vault read auth/approle/role/my-app/role-id

Generate a SecretID like a password:

vault write -force auth/approle/role/my-app/secret-id

Then, log in with AppRole:

vault write auth/approle/login \
role_id="675a50e7-cfe0-be76-e35f-49ec009731ea" \
secret_id="ed0a642f-2acf-c2da-232f-1b21300d5f29"

To view all enabled authentication methods, you can use:

vault auth list

Step 12. Enable Vault Audit Logging

Audit logging records Vault activity so you can trace who accessed which secrets, when, and from where. It is an essential control for security monitoring and compliance.

File Audit Device: You can enable file-based audit logging by using the commands below:

sudo mkdir -p /var/log/vault
sudo chown vault:vault /var/log/vault
vault audit enable file file_path=/var/log/vault/audit.log

Then, view audit devices:

vault audit list

Audit Log Format: Audit logs are written in JSON format, and each entry includes:

• Request details.
• Authentication information.
• Response data.
• Timestamp and duration.

Example audit log entry:

{
  "time": "2024-12-18T10:45:32.123456Z",
  "type": "response",
  "auth": {
    "client_token": "hmac-sha256:abc123...",
    "accessor": "hmac-sha256:xyz789...",
    "display_name": "token",
    "policies": ["app-policy", "default"],
    "token_policies": ["app-policy", "default"],
    "metadata": null
  },
  "request": {
    "id": "f3d2a1b4-...",
    "operation": "read",
    "client_token": "hmac-sha256:abc123...",
    "client_token_accessor": "hmac-sha256:xyz789...",
    "path": "secret/data/myapp/database"
  },
  "response": {
    "data": {
      "data": {
        "password": "hmac-sha256:def456...",
        "username": "hmac-sha256:ghi789..."
      }
    }
  }
}

Syslog Audit Device: For integration with centralized logging systems, you can use:

vault audit enable syslog tag="vault" facility="AUTH"

Socket Audit Device: You can send audit logs to an external service via TCP/UDP socket:

vault audit enable socket address="10.0.1.5:9090" socket_type="tcp"

Disable Audit Device:

vault audit disable file/

Warning: In production, always maintain at least one audit device for security compliance.

Audit Log Rotation: You can configure log rotation using logrotate:

sudo tee /etc/logrotate.d/vault > /dev/null << 'EOF'
/var/log/vault/audit.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 vault vault
    postrotate
        systemctl reload vault > /dev/null 2>&1 || true
    endscript
}
EOF

Step 13. Access Vault Web UI

Vault’s Web UI provides a convenient way to manage secrets and access controls without relying only on the CLI.

From your desired browser, you can access it at:

https://YOUR_VPS_IP:8200/ui
 or
https://vault.yourdomain.com:8200/ui

Once you access the Vault UI, accept the self-signed certificate warning and select an authentication method:

• Token: Enter root token or any valid token.
• Username: Enter username and password if userpass is enabled.

Then, sign in to the Vault dashboard.

Note: For full UI functionality, users need appropriate policies. The UI automatically requires access to:

path "sys/internal/ui/mounts" {
  capabilities = ["read"]
}

path "sys/internal/ui/mounts/*" {
  capabilities = ["read"]
}

These paths are automatically granted and cannot be modified.

Protect Vault Data: Backup and Recovery Options

In this step, you can learn how to protect Vault data and recover quickly from accidents or server failures using integrated Raft snapshots.

First, take a snapshot of Vault data:

vault operator raft snapshot save vault-snapshot-$(date +%Y%m%d-%H%M%S).snap

Verify the snapshot with:

vault operator raft snapshot inspect vault-snapshot-20241218-104530.snap

To restore from a snapshot, stop the Vault service with the command below:

sudo systemctl stop vault

Then, restore the snapshot:

vault operator raft snapshot restore -force vault-snapshot-20241218-104530.snap

Start and provide unseal keys with these commands:

sudo systemctl start vault
vault operator unseal

Also, you can create and use an automated backup script:

sudo tee /usr/local/bin/vault-backup.sh > /dev/null << 'EOF'
#!/bin/bash

# Configuration
BACKUP_DIR="/opt/vault/backups"
RETENTION_DAYS=30
VAULT_ADDR="https://127.0.0.1:8200"
VAULT_TOKEN_FILE="/root/.vault-token"

# Create backup directory if it doesn't exist
mkdir -p "$BACKUP_DIR"

# Set Vault address
export VAULT_ADDR="$VAULT_ADDR"
export VAULT_TOKEN=$(cat "$VAULT_TOKEN_FILE")

# Create snapshot with timestamp
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
SNAPSHOT_FILE="$BACKUP_DIR/vault-snapshot-$TIMESTAMP.snap"

# Take snapshot
vault operator raft snapshot save "$SNAPSHOT_FILE"

# Compress snapshot
gzip "$SNAPSHOT_FILE"

# Remove old backups
find "$BACKUP_DIR" -name "vault-snapshot-*.snap.gz" -type f -mtime +$RETENTION_DAYS -delete

echo "Backup completed: $SNAPSHOT_FILE.gz"
EOF

Make the script file executable:

sudo chmod +x /usr/local/bin/vault-backup.sh

Schedule it with cron by using the commands below:

sudo crontab -e

Add this line:

0 2 * * * /usr/local/bin/vault-backup.sh >> /var/log/vault/backup.log 2>&1

Here are some backup best practices you can consider:

• Regular Schedule: Automate backups daily or more frequently based on RPO.
• Off-site Storage: Store backups in a separate location.
• Encryption: Encrypt backups at rest and in transit.
• Testing: Regularly test restore procedures to ensure backups are valid.
• Retention Policy: Keep multiple generations of backups.
• Monitoring: Alert on backup failures.
• Documentation: Document restore procedures in runbooks.

Troubleshooting Common Vault Issues

Troubleshooting helps you quickly identify and fix the most common Vault problems. Here are the most common issues you may face and their solutions:

Issue 1: Vault is sealed after a restart.

The solution is to unseal Vault using 3 unseal keys or implement auto-unseal:

vault operator unseal

Issue 2: permission denied errors.

You must check the policies attached to your token:

vault token lookup
vault policy read POLICY_NAME

Issue 3: TLS certificate errors.

Verify the certificate paths and permissions:

sudo ls -la /opt/vault/tls/
sudo openssl x509 -in /opt/vault/tls/vault-cert.pem -text -noout

Issue 4: Vault service won’t start.

Check logs for errors and fix them:

sudo journalctl -u vault -n 100 --no-pager
sudo systemctl status vault

Issue 5: Cannot connect to Vault.

Verify listener configuration and firewall rules:

sudo netstat -tlnp | grep 8200
sudo ufw status

For performance issues, you can check Vault performance metrics:

vault read sys/metrics

Monitor storage backend with:

vault operator raft list-peers
vault operator raft autopilot state

FAQs

Conclusion

At this point, you have learned to set up Secrets Management with HashiCorp Vault on VPS, including secure installation, TLS-enabled access, persistent Raft storage, systemd service management, initialization, unsealing, authentication, policies, secrets engines, auditing, and a basic backup workflow.

We hope you enjoy this guide. Subscribe to our X and Facebook channels to get the latest updates and articles.

For further reading:

VPS backups and disaster recovery strategies

Multi-Tenant VPS Hosting Architecture