Deploying HashiCorp Vault with Ansible

If you want to manage secrets centrally and securely, you’ll eventually land on HashiCorp Vault. If you’re new to Vault, part 1 introduces what it is and how it’s meant to work. This part covers the infrastructure: instead of installing and configuring Vault manually, I deploy the entire instance with Ansible so the setup is reproducible, version-controlled, and easy to spin up again when needed.

Why Vault, Why Ansible?

HashiCorp Vault puts secrets (passwords, API keys, certificates) in one place, with access control, audit logging, and rotation. For me the important part was: no passwords lying around locally, no shared secrets in repos, and a clear separation of who can read what.

Ansible is already my go-to for server setup and configuration. Deploying Vault with Ansible means a dedicated role or playbook that handles installation, configuration, and systemd setup. Any change to the setup lives in the same repo as the rest of the infrastructure.

A cloud or VM provider with a simple API and SSH access fits well with a fully automated deployment: you define the target host (or use dynamic inventory), and Ansible does the rest.

Environment and Requirements

Before writing the playbook, you need a clear picture of the environment:

• Provider / inventory: SSH keys, optional firewall or network config, and a way for Ansible to reach the host (static or dynamic inventory).
• Ansible: Access to target hosts via SSH.
• Target server: e.g. a small VM with a current Linux (Debian/Ubuntu or the like).

Vault typically runs as a binary with its own config file; a systemd service keeps the process running and brings it back after reboots.

Ansible Setup

In my infrastructure Ansible repo, the Vault deployment is structured like this:

• Role or playbook: A dedicated vault role (or a playbook with tasks) handles:

  • Installing the Vault binary (e.g. from HashiCorp or a package)
  • Creating directories (data, config, logs)
  • Writing the Vault config (listen address, storage backend, TLS options)
  • A systemd unit for the Vault service
  • Optional: firewall rules, users/groups

• Variables: Address, port, paths, and optionally TLS certs are driven by Ansible variables so you can reuse the same playbook across environments.

I deliberately keep the config so that no unseal keys or root token end up in Ansible – initialization and unseal happen after first start, manually or via a separate, secured process.

flowchart LR
  A[Your machine<br/>Ansible playbook] --> B[SSH<br/>to target host]
  B --> C[Target server<br/>Install binary, config, systemd]
  C --> D[Vault running<br/>sealed until init]

The diagram above shows the deployment flow: your machine runs Ansible, which connects via SSH to the target server and installs and configures the Vault binary and systemd service.

First Steps After Deploy

Once the service is up:

1. Initialize Vault – vault operator init (one-time), store unseal keys and root token securely.
2. Unseal – After every Vault restart (e.g. after updates) you need to unseal; that can be manual or a secured automation step.
3. First policies and auth methods – e.g. enable the KV engine, create initial paths, set up OIDC or AppRole for later integration (Ansible, CI/CD, vaultsh).

That sets the stage for the next step: pulling the Ansible Vault password from HashiCorp Vault instead of keeping it locally – that’s part 3 of this series.

Lessons Learned / Next Steps

• Reproducibility: Once the playbook has been run, you can recreate the instance or deploy to a second environment whenever you need to.
• Don’t overwrite on re-runs: With tools like Vault, re-running the playbook (e.g. after a change or by habit) must not overwrite existing state: data dirs, config that was adjusted after init, or – worst case – trigger a fresh init and wipe what’s there. Design tasks to be idempotent and skip or protect anything that’s already initialised or holds live data.
• Separation: Keeping deployment (Ansible) and “operations” (init, unseal, policies) separate reduces the risk of sensitive values ending up in repos or logs.
• Up next: In part 3 I show how a wrapper script fetches the Ansible Vault password from HashiCorp Vault – so you can gradually move from Ansible Vault to Vault as the central source.

The full Ansible setup for this deployment lives in my infrastructure Ansible repo (private).