---
title: "Subnets and attachments"
description: "Carve up a VPC and connect workloads to it."
---

A VPC on its own routes nothing. **Subnets** carve its range into usable pieces, and **attachments** give a workload an interface on one of them.

## Subnets

A new VPC already has a subnet called `default` — a `/24` taken from its range, after the block the platform keeps for the router, the resolver and the VPN terminators. On a `10.224.0.0/16` VPC that is `10.224.1.0/24`. Most setups never need another one.

Add more when you want to separate workloads by egress behaviour, which is the only thing that actually differs between two subnets:

| | Public subnet | Private subnet |
|---|---|---|
| Reaching other workloads in the VPC | Yes | Yes |
| Default route for outbound traffic | The platform's | The VPC's |
| Outbound traffic leaves through | Miget | Your own gateway |

<Note>
"Public" does not mean the workload is reachable from the internet. It means its default route stays with the platform. A workload on a private subnet sends everything through the VPC, so its egress leaves through whatever gateway you have attached — useful when a third party allows traffic only from a fixed address you control.
</Note>

A subnet's range must sit inside the VPC's own and must not overlap a sibling. Both refusals name the conflict.

### Address families

A subnet runs **dual-stack** by default — IPv4 and IPv6. You can also ask for `ipv4` only, or `ipv6` only. The IPv6 range is derived from the VPC's own unless you set one.

## Attaching a workload

Applications, services and add-ons can all attach. Pick the workload and the subnet, and the platform gives it an interface there.

<Warning>
**Attaching restarts the workload.** A network interface cannot be added to a running container, so the workload rolls as part of the operation. For a database, that is a database restart — plan it like one.

Detaching restarts it again.
</Warning>

An application can skip that restart entirely by joining the VPC **when it is created**, rather than being attached afterwards.

### Names, not addresses

Once attached, a workload answers to a name inside the VPC, shown on the attachment. Use that name.

<Warning>
The name resolves to the workload's current pod address, and **that address changes when the workload rolls**. After a deployment the record is stale until the next attach, detach or route change refreshes it.

Treat it as a name to connect to, never as an address to hard-code, allow-list or store.
</Warning>

A **cron job** gets no name at all: its pods are transient, so there is nothing stable to publish.

## Removing things

- A subnet cannot be deleted while a workload is still attached to it.
- A VPC cannot be deleted while it still has subnets.

Both refuse rather than cascade, so nothing disappears underneath a running workload.