---
title: Consul and Vault
scope: 3dmk
type: documentation
subject: consul-vault
group: Systems
status: current
version: "2.1.3"
source: https://3dmk.com/documentation#consul-vault
author: Nick Olson
contact:
  email: 3dmk@3dmk.com
  site: https://3dmk.com
license: CC BY 4.0
license_url: https://creativecommons.org/licenses/by/4.0/
attribution: Nick Olson, 3dmk.com
---

# Consul and Vault

Consul and Vault are two foundation services that every other service in the stack depends on. Consul tracks where each service runs. It also holds shared settings. Vault stores the secrets that services need. Both are off-the-shelf HashiCorp products. Together they keep addresses and credentials out of source code, images, and prompts.

## Role

Consul provides service discovery. Each service registers its name, location, tags, and health check when it starts. Clients resolve that name at call time through Domain Name System (DNS) or HTTP lookups. No service stores another service’s address. Name lookups work on every machine in the development environment.

Consul also keeps shared, non-secret configuration in a key-value store. Secrets never enter it.

Vault stores versioned key-value secrets. Each service authenticates to Vault with its own identity, and no two services share one. A policy limits each service to its own secrets. The service receives its credentials at runtime. It holds them in memory.

No project keeps secrets in source, environment files, plaintext configuration, or a local secret store. Configuration flows through Consul, and secrets flow through Vault.

## Parts

Both Docker hosts, core-docker-1 and core-docker-aws-1, run their own Consul and Vault. Each pair runs under the same names, so one compose file deploys a service to either host.

The Core bootstrap brings up the stack in three tiers.

| Tier | Services | Configuration source | Secret source |
|---|---|---|---|
| Foundation | Consul, Vault, and Nexus | Fixed settings at deploy time | Not applicable |
| Infrastructure | Redis and PostgreSQL | Consul | Vault |
| Application | Every other service | Consul | Vault |

Consul starts first. Vault, Nexus, Redis, and PostgreSQL follow in that order. For each service, the Core bootstrap runs three steps: deploy, health check, and Consul registration. The bootstrap seeds Consul with non-secret values. It initializes the Vault secrets engine. It seeds approved values. It also creates the service policies.

## Data

Consul keeps three kinds of data:

- A catalog of registered services

- Health check results for each registered service

- Key-value entries of non-secret settings, grouped by service

Each consumer has its own Vault entry for each system that it uses. Each entry keeps its earlier versions. These entries hold service credentials, such as database role passwords. The Vault standard forbids printing a service credential or writing it to a file.

## Connections

Every managed service uses both. The main exchanges follow:

- Managed services: Each one registers with Consul. It finds its dependencies by name.

- Vault: Vault registers in Consul, so services find Vault by name as well.

- PostgreSQL and Redis: Both read settings from Consul and credentials from Vault.

- Publishing: Each release reads its configuration and secrets from the target host’s Consul and Vault.

- NervHQ: Its health collector reads the Consul service catalog and Vault’s status.

- Agent tools: A tool uses a secret without showing it to the conversation.