page_title: Register a Service Mesh Proxy in a Service Registration
page_title: Deploy proxies as sidecar services
description: >-
You can register a service instance and its sidecar proxy at the same time. Learn about default settings, customizable parameters, limitations, and lifecycle behaviors of the sidecar proxy.
---
# Deploy sidecar proxies
# Deploy sidecar services
This topic describes how to create, register, and start sidecar proxy services in Consul. Refer to [Service mesh proxies overview](/consul/docs/connect/proxies) for additional information about how proxies enable Consul functionalities. For information about deploying service mesh proxies, refer to [Deploy service mesh proxies](/consul/docs/connect/proxies/deploy-service-mesh-proxies).
@ -172,17 +172,40 @@ $ consul connect envoy -sidecar-for=web
For details about operating an Envoy proxy in Consul, refer to [](/consul/docs/connect/proxies/envoy)
## Configuration reference
Add the `connect.sidecar_service` block to your service definition file and specify the parameters to configure sidecar proxy behavior. The `sidecar_service` block is a service definition that can contain most regular service definition fields. Refer to [Limitations](#limitations) for information about unsupported service definition fields for sidecar proxies.
The `sidecar_service` block is a service definition that can contain most regular service definition fields. Refer to [Limitations](#limitations) for information about unsupported service definition fields for sidecar proxies.
Consul treats sidecar proxy service definitions as a root-level service definition. All fields are optional in nested definitions, which default to opinionated settings that are intended to reduce burden of setting up a sidecar proxy.
Consul treats sidecar proxy service definitions as a root-level service definition. All fields are optional in nested
definitions, which default to opinionated settings that are intended to reduce burden of setting up a sidecar proxy.
## Sidecar service defaults
The following fields are set by default on a sidecar service registration. With
[the exceptions noted](#limitations) any field may be overridden explicitly in
the `connect.sidecar_service` definition to customize the proxy registration.
The "parent" service refers to the service definition that embeds the sidecar
proxy.
- `id` - ID defaults to being `<parent-service-id>-sidecar-proxy`. This can't
be overridden as it is used to [manage the lifecycle](#lifecycle) of the
registration.
- `name` - Defaults to being `<parent-service-name>-sidecar-proxy`.
- `tags` - Defaults to the tags of the parent service.
- `meta` - Defaults to the service metadata of the parent service.
- `port` - Defaults to being auto-assigned from a configurable
range specified by [`sidecar_min_port`](/consul/docs/agent/config/config-files#sidecar_min_port)
and [`sidecar_max_port`](/consul/docs/agent/config/config-files#sidecar_max_port).
- `kind` - Defaults to `connect-proxy`. This can't be overridden currently.
- `check`, `checks` - By default we add a TCP check on the local address and
port for the proxy, and a [service alias
check](/consul/docs/services/usage/checks#alias-checks) for the parent service. If either
`check` or `checks` fields are set, only the provided checks are registered.
- `proxy.destination_service_name` - Defaults to the parent service name.
- `proxy.destination_service_id` - Defaults to the parent service ID.
- `proxy.local_service_address` - Defaults to `127.0.0.1`.
- `proxy.local_service_port` - Defaults to the parent service port.
## Example with overwitten configurations
### Example with overwritten configurations
In the following example, but the `sidecar_service` macro sets baselines configurations for the proxy, but the [proxy
trujillo-adam
1 year ago