network_mode: "service:[service name]"
```
When set, the [`networks`](#networks) attribute is not allowed and Compose rejects any
Compose file containing both attributes.
### `networks`
{{% include "compose/services-networks.md" %}}
```yml
services:
some-service:
networks:
- some-network
- other-network
```
For more information about the `networks` top-level element, see [Networks](networks.md).
### Implicit default network
If `networks` is empty or absent from the Compose file, Compose considers an implicit definition for the service to be
connected to the `default` network:
```yml
services:
some-service:
image: foo
```
This example is actually equivalent to:
```yml
services:
some-service:
image: foo
networks:
default: {}
```
If you want the service to not be connected a network, you must set [`network_mode: none`](#network_mode).
#### `aliases`
`aliases` declares alternative hostnames for the service on the network. Other containers on the same
network can use either the service name or an alias to connect to one of the service's containers.
Since `aliases` are network-scoped, the same service can have different aliases on different networks.
> [!NOTE]
> A network-wide alias can be shared by multiple containers, and even by multiple services.
> If it is, then exactly which container the name resolves to is not guaranteed.
```yml
services:
some-service:
networks:
some-network:
aliases:
- alias1
- alias3
other-network:
aliases:
- alias2
```
In the following example, service `frontend` is able to reach the `backend` service at
the hostname `backend` or `database` on the `back-tier` network. The service `monitoring`
is able to reach same `backend` service at `backend` or `mysql` on the `admin` network.
```yml
services:
frontend:
image: example/webapp
networks:
- front-tier
- back-tier
monitoring:
image: example/monitoring
networks:
- admin
backend:
image: example/backend
networks:
back-tier:
aliases:
- database
admin:
aliases:
- mysql
networks:
front-tier: {}
back-tier: {}
admin: {}
```
### `interface_name`
{{< summary-bar feature_name="Compose interface-name" >}}
`interface_name` lets you specify the name of the network interface used to connect a service to a given network. This ensures consistent and predictable interface naming across services and networks.
```yaml
services:
backend:
image: alpine
command: ip link show
networks:
back-tier:
interface_name: eth0
```
Running the example Compose application shows:
```console
backend-1 | 11: eth0@if64: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
```
#### `ipv4_address`, `ipv6_address`
Specify a static IP address for a service container when joining the network.
The corresponding network configuration in the [top-level networks section](networks.md) must have an
`ipam` attribute with subnet configurations covering each static address.
```yml
services:
frontend:
image: example/webapp
networks:
front-tier:
ipv4_address: 172.16.238.10
ipv6_address: 2001:3984:3989::10
networks:
front-tier:
ipam:
driver: default
config:
- subnet: "172.16.238.0/24"
- subnet: "2001:3984:3989::/64"
```
#### `link_local_ips`
`link_local_ips` specifies a list of link-local IPs. Link-local IPs are special IPs which belong to a well
known subnet and are purely managed by the operator, usually dependent on the architecture where they are
deployed.
Example:
```yaml
services:
app:
image: busybox
command: top
networks:
app_net:
link_local_ips:
- 57.123.22.11
- 57.123.22.13
networks:
app_net:
driver: bridge
```
#### `mac_address`
{{< summary-bar feature_name="Compose mac address" >}}
`mac_address` sets the Mac address used by the service container when connecting to this particular network.