consul connect: Service Mesh Proxies in CI
consul connect runs the mesh sidecar proxies and exposes the mesh CA that secures service-to-service traffic with mTLS.
Consul Connect is the service mesh. In a test you can spin up a built-in proxy so two services talk over mTLS without standing up Envoy.
What it does
consul connect groups the mesh subcommands. consul connect proxy runs the lightweight built-in proxy, consul connect envoy bootstraps an Envoy sidecar, and consul connect ca get-config / set-config manages the mesh certificate authority. Intentions (allow/deny rules between services) are managed separately via consul intention.
Common usage
# built-in proxy as a sidecar for a registered service
consul connect proxy -sidecar-for web
# bootstrap an Envoy sidecar
consul connect envoy -sidecar-for web
# inspect the mesh CA configuration
consul connect ca get-configOptions
| Flag / subcommand | What it does |
|---|---|
| proxy | Run the built-in Go proxy (testing and low-traffic use) |
| envoy | Generate Envoy bootstrap config and exec Envoy |
| ca get-config / set-config | Read or update the mesh CA configuration |
| -sidecar-for <service> | Run as the sidecar for a registered service |
| -service <name> | Service name the proxy represents |
In CI
For a mesh integration test, the built-in proxy (consul connect proxy) avoids needing an Envoy binary on the runner. Remember traffic is denied by default once intentions are in default-deny mode; add an intention allowing the upstream or calls fail.
Common errors in CI
"Error: -sidecar-for requires the service to be registered" means you must register the service first. "==> Error: Failed to exec envoy: exec: \"envoy\": executable file not found in $PATH" from consul connect envoy means Envoy is not installed on the runner. A connection refused between services with intentions enabled usually means a missing allow intention, not a proxy bug.