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.

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:

Install required dependencies for adding the HashiCorp repository:

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

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:

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

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

You can verify the installation by checking its version:

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:

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

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

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:

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

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:

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

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

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.

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:

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:

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

Reload systemd to recognize the new service:

Enable and start the Vault service with the commands below:

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

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

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:

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:

Check Vault status with the following command:

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

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:

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

Example output:

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:

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

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:​

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

After the third key, check the 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.

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:

When prompted, enter your root token.

Alternatively, you can use this command:

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.

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:

Check enabled secrets engines with the command below:

Store Secrets:

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

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

Read Secrets:

To read the entire secret, you can use:

Or you can get a specific field only:

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

Version Management:

To update a secret, you can run:

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

View version history metadata with the command below:

Rollback to the previous version with:

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:

Undelete a soft-deleted secret with the command below:

Permanently destroy specific versions with this:

Warning: Destroyed versions cannot be recovered.

Delete all versions and metadata with the command below:

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

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:

Then, write the policy to Vault:

Admin Policy:

You can create a comprehensive admin policy file with:

Write the admin policy to the Vault:

Application Policy:

Create a policy for application access with the command below:

Write the policy:

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

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

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:

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

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

Create a user with policies attached:

Log in with username and password:

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

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

Enable AppRole authentication with this command:

Create an AppRole with policies:

Get the RoleID like a username:

Generate a SecretID like a password:

Then, log in with AppRole:

To view all enabled authentication methods, you can use:

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:

Then, view audit devices:

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:

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

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

Disable Audit Device:

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

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

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:

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:

These paths are automatically granted and cannot be modified.

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:

Verify the snapshot with:

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

Then, restore the snapshot:

Start and provide unseal keys with these commands:

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

Make the script file executable:

Schedule it with cron by using the commands below:

Add this line:

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 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:

Issue 2: permission denied errors.

You must check the policies attached to your token:

Issue 3: TLS certificate errors.

Verify the certificate paths and permissions:

Issue 4: Vault service won't start.

Check logs for errors and fix them:

Issue 5: Cannot connect to Vault.

Verify listener configuration and firewall rules:

For performance issues, you can check Vault performance metrics:

Monitor storage backend with:

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