15. When to use Consul, and when not to

Consul is four products and you can adopt any subset. So the honest question is not “Consul or not” but “which parts, if any”.

Where it clearly wins

1. Mixed environments. Virtual machines and containers and a bare-metal database and a managed cloud service, all needing to find each other. Nothing else does this as well. Kubernetes’ Service discovery stops at the cluster boundary; Consul does not care what a workload runs on.

2. Multi-datacentre and multi-cluster. Independent Raft per datacentre, WAN federation or cluster peering, mesh gateways, and prepared queries that fail over to the nearest datacentre by measured latency. This is the strongest single differentiator.

3. Service discovery through DNS. Legacy applications, any language, no code change. Nothing else in this space gives you that for free.

4. Deep, protocol-aware health checking. Seven check types, TTL checks for background workers, checks bound to sessions so a failing leader loses leadership automatically. etcd has none of this.

5. Progressive adoption. Discovery today, health checks tomorrow, KV next year, mesh perhaps never. Each piece is useful alone, which is rare.

Where something else wins

Pure Kubernetes, one cluster. Kubernetes already has Services, DNS, endpoints and readiness probes. Adding Consul for discovery inside one cluster is a second system doing a job the first already does. → Use Kubernetes’ own.

You need a strongly consistent configuration store and nothing else. → etcd. Smaller, simpler, better watch semantics, Apache 2.0.

You want a service mesh and only a service mesh. → Linkerd is dramatically simpler; Istio has more features and a larger ecosystem. Consul’s mesh is good and it arrives with three other products attached.

Your cloud already has a registry. AWS Cloud Map, ECS service discovery, Azure Service Fabric. If you are on one cloud and staying, the managed thing is one fewer system. → Use it.

You have three services. A configuration file with three addresses is fine, and it will keep being fine for a while. → Wait.

The comparison table

	Consul	etcd	Kubernetes	Istio	Cloud Map
Service discovery	yes	primitive	yes (in-cluster)	via K8s	yes
Health checking	excellent	none	probes	via K8s	basic
DNS interface	yes	no	in-cluster	in-cluster	yes
KV store	yes	yes	ConfigMaps	no	no
Service mesh	yes	no	no	yes	no
Multi-datacentre	yes	painful	painful	yes	per-region
Non-Kubernetes workloads	yes	yes	no	limited	yes
Operational burden	high	medium	—	high	none
Licence	BUSL	Apache 2.0	Apache 2.0	Apache 2.0	proprietary

The licence

Consul 1.17 and later are under the Business Source License 1.1. It is not an OSI-approved open source licence. You may use it internally without restriction; you may not use it to provide a competing commercial service. Each version converts to MPL 2.0 four years after release.

For most organisations this changes nothing. For three groups it changes a great deal:

Anyone building a product on it. “Competing service” is defined by HashiCorp and interpreted by lawyers, and the uncertainty alone is disqualifying for some businesses.

Anyone with a policy requiring OSI licences. Some do, and the policy does not bend.

Anyone who values a foundation-governed project. Consul is a vendor product now owned by IBM. etcd is CNCF-governed and Apache 2.0, and that is a genuine and permanent difference.

The alternatives if the licence is disqualifying: etcd for the KV and coordination role, Nomad’s situation is the same so it does not help, Linkerd or Istio for the mesh, and Kubernetes’ own machinery for discovery. There is no drop-in Consul fork with the momentum that OpenTofu or OpenBao have.

Decide this before you invest, not after. A licence question discovered two years into a deployment is much more expensive than one asked at the start.

Against etcd, specifically

The comparison people most often need.

   etcd                             Consul

   a strongly consistent KV store   discovery + health + KV + mesh
   clients connect to the cluster   apps talk to a local agent
   watches: ordered, gap-free,      blocking queries: simpler,
     with a global revision           no ordering guarantee
   no health checks                 seven kinds of health check
   no DNS                           DNS is a first-class interface
   one cluster                      multi-datacentre by design
   Apache 2.0, CNCF                 BUSL, vendor-owned

Choose etcd when you need a small, correct, strongly consistent store with the best watch semantics available, and you will build discovery on top yourself. It is what Kubernetes uses, for exactly those reasons.

Choose Consul when you want discovery and health checking as products rather than primitives, and when your workloads are not all in one Kubernetes cluster.

Chapter 15 of the etcd guide makes the same comparison from the other side and reaches the same split.

Against Kubernetes’ built-in discovery

Inside a cluster, Kubernetes wins and it is not close: Services, DNS, endpoints and readiness probes are already there, already understood, already monitored.

Consul earns its place in Kubernetes in exactly two cases:

You have workloads outside the cluster too. VMs, a database on bare metal, a second cluster. syncCatalog bridges the two directions and that bridge is genuinely hard to build otherwise.

You want its mesh rather than Istio’s. A defensible choice — Consul’s intentions model is simpler than Istio’s AuthorizationPolicy, and if Consul is already running for reason one, the mesh is incremental.

If neither is true, do not add Consul to a Kubernetes cluster. You are running two discovery systems and reconciling them forever.

Against Istio and Linkerd

   Linkerd    simplest by far. Rust proxy, small footprint,
              Kubernetes only. If you want a mesh and nothing else,
              start here.

   Istio      most features, largest ecosystem, steepest learning
              curve. Kubernetes-centric, with VM support that works
              and is not the main path.

   Consul     mesh plus discovery plus KV. The best option for
              non-Kubernetes workloads. More to run than Linkerd,
              less feature-dense than Istio.

The deciding question is whether your workloads are all in Kubernetes. If yes, Linkerd or Istio. If no, Consul is the one that was designed for the mixed case, and the difference is substantial.

Against Nomad

Not a competition — they are complementary, from the same vendor, and Nomad registers its allocations into Consul automatically. If you run Nomad, you run Consul, and the integration is the best argument for both.

Nomad plus Consul plus Vault is a coherent, well-integrated stack that is genuinely simpler to operate than Kubernetes for many workloads. It is also a smaller ecosystem, a smaller hiring pool, and three BUSL products. That trade is real in both directions.

What to adopt, in order

   1. SERVICE DISCOVERY + HEALTH CHECKS
      The core value. DNS or HTTP. Weeks, not months.

   2. consul-template
      Dynamic backends for HAProxy, nginx, Prometheus, application
      config. The highest-value integration in the product.

   3. THE KV STORE
      Configuration and feature flags with blocking-query watches.
      Not secrets — that is Vault.

   4. ACLs
      Before you are too large to migrate. default_policy = "allow"
      first, then deny.

   5. THE SERVICE MESH
      Only if you have a specific need: mTLS for compliance,
      per-service authorisation, traffic shaping.
      This is a large, permanent commitment.

Steps 1 and 2 are most of the value. Many successful Consul deployments never go past step 3, and that is not a failure of adoption — it is a correct assessment of what the remaining steps cost.

Would I choose it today?

For a mixed VM-and-container environment: yes. Nothing else covers that case as well, and the DNS interface means legacy applications participate with no changes.

For multi-datacentre: yes, subject to the licence. Independent Raft per datacentre with mesh gateways and latency-aware failover is a genuinely good design and the alternatives are worse.

For a single Kubernetes cluster: no. Use what is already there.

For a configuration store alone: no. etcd is smaller, simpler and Apache 2.0.

For a mesh alone: probably not. Linkerd if you want simple, Istio if you want features — unless your workloads are not all in Kubernetes, in which case Consul again.

And the licence caveat applies to all of it. If BUSL is disqualifying for you, that is a complete answer and the rest of the analysis does not matter. Establish it first.

What Consul does not solve

It does not load balance. It tells you the healthy addresses; your client, or HAProxy, or the sidecar distributes across them.

It does not store your data. The KV store is for coordination. A megabyte in it is a mistake; a gigabyte is an incident.

It does not hold secrets. No encryption at rest by default, no audit log in the open-source version, no rotation, no dynamic credentials. Vault exists for that and integrates directly.

It does not make your services reliable. It tells you which are healthy. What you do about the unhealthy ones is the actual work — and clients must still retry, because no discovery system removes the window between an instance dying and everyone learning about it.

What to take from this chapter

• Mixed environments and multi-datacentre are where Consul clearly wins. Nothing else covers those as well.
• Inside one Kubernetes cluster, use Kubernetes. Two discovery systems is worse than one.
• For a configuration store alone, etcd is smaller, simpler and Apache 2.0.
• For a mesh alone, Linkerd is simpler and Istio has more — unless your workloads are not all in Kubernetes.
• The BUSL licence is decisive for some organisations. Establish it before investing, not after.
• Adopt discovery and health checks first, then consul-template. That is most of the value, and stopping there is a legitimate outcome.
• The mesh is a large permanent commitment. Adopt it for a specific need, not because it is there.
• It does not load balance, store data, or hold secrets, and clients must still retry.

Next: the cheat sheet — every command, configuration block, API path and DNS form from this guide on one page.