Concept and mechanism
Starting a process does not demonstrate an operational cluster. In a new datacenter, bootstrap_expect states how many servers must be present before automatic bootstrap. Use consistent server configuration and a join mechanism that discovers them. Retry_join supports repeated discovery but does not correct a wrong address, incompatible firewall, or agents configured for different environments. Confirm node identity, advertised address, data directory, datacenter, and channel security. A server data directory contains persistent state; do not treat it as disposable cache during an incident. Distinguish initial bootstrap from recovery of an existing cluster.
Guided application
In a fictional lab, two servers wait for the planned third. Complete and validate the design rather than creating isolated leaders merely to remove a warning. For production handover, one development agent does not automatically satisfy persistence, security, or resilience. On Kubernetes, review the chart, compatible versions, volumes, identity, and component connectivity before accepting deployment merely because pods are Running. This course explains those decisions but does not replace an executable lab. Record approved configuration, change ownership, rollback conditions, and evidence that RUN can recognize leader loss and join failure without rebuilding the cluster by trial and error.
bootstrap_expect=3 with only two joined servers has not completed planned bootstrap.
Common pitfalls
Running as ready; bootstrap as universal repair; deleting data_dir to clear alerts.
Related topics: Discovery, architecture, and quorum · Registration, health checks, and DNS · Mesh, identity, and intentions
Confirm formation, persistence, and communication before recording acceptance.
Reference: Bootstrap a Consul datacenter · Historical Consul Associate (003), retired 2026-07-15; technical references inspected 2026-09-30