The listener waits. A single connection request hits the wire, and Hashicorp Boundary decides if it lives or dies. In that decision path, the grpcs prefix is the gate.
Hashicorp Boundary supports multiple connection types, but when you configure a Boundary worker to use grpcs:// you’re explicitly telling it to use gRPC over TLS. The grpcs prefix is more than a naming convention—it signals secure, encrypted communication between the Boundary worker and the controller. Without it, traffic falls back to plain gRPC (grpc://), which carries no TLS guarantees.
This matters for any deployment where workers run outside a tightly controlled network segment. Using grpcs ensures that all session brokering, credential delivery, and target connection instructions are wrapped in transport-layer encryption. In Boundary’s architecture, gRPC is the control channel. Securing it with TLS through the grpcs prefix protects against interception or tampering.
When setting up workers, you define their address in the configuration file or environment variables. Specify grpcs://<controller-host>:<port> to bind them to secure channels. Your controller must be configured with valid TLS certificates. Self-signed certificates can work for testing, but in production, a certificate from a trusted CA reduces friction and avoids complex trust bootstrapping.