# Networks

Source: https://docs.quake.ai/docs/network/concepts/networks
Markdown: https://docs.quake.ai/docs/network/concepts/networks.md

---

# Networks

Networks are isolated Layer 2 segments that give your instances connectivity. Instances attach to at least one network; most production deployments use **private networks** with routers and floating IPs for controlled internet access.

## What a network provides

The Network service ([OpenStack Neutron](https://docs.openstack.org/neutron/latest/)) defines each network as a broadcast domain. Within it, you create one or more **subnets** that assign IP address ranges, gateways, and DHCP settings. Instances connect to networks through **ports**: each port carries an IP address and a MAC address and represents a virtual network interface on the instance.

Your project scopes networks to that project by default: only instances within the same project can communicate over a private network. This isolation is fundamental to multi-tenant security in the cloud.

## Built-in networks on Quake AI

Each project includes two external networks:

- **`PublicEphemeral`**: lets you attach an instance directly to the internet. Best for testing and quick experiments, since the instance is fully exposed on the provider network with no router or NAT in between.
- **`PublicStatic`**: provides controlled internet access through a router. You cannot attach an instance directly to `PublicStatic`; create a private network, attach a router to both `PublicStatic` and your private network, and use floating IPs for inbound access. Production workloads use this path when they need stable public addresses and private subnets.

## How networks connect to the rest of the platform

**Routers** link private networks to external networks and to each other, providing Layer 3 routing and NAT. **Floating IPs** give instances a stable public address that survives reboots and can be moved between instances. **Security groups** filter traffic at the port level, acting as a virtual firewall closest to the workload. For traffic distribution, run a reverse proxy on an instance or connect an external edge service.

Together, these components let you build network topologies from simple single-network setups to multi-tier architectures with web, application, and database segments.

<Figure caption="Network topology: private networks connect to the internet through a router and floating IPs">

```d2
direction: down

internet: Internet {shape: cloud}
extnet: PublicStatic
router: Router
fip: Floating IP

private: Private Network {
  inst1: Instance 1\n10.0.0.10
  inst2: Instance 2\n10.0.0.11
  inst3: Instance 3\n10.0.0.12
}

internet <-> extnet
extnet <-> router
router <-> private
fip -> private.inst1: DNAT {style.stroke-dash: 5}
```

</Figure>

## Designing your network layout

For a single application or experiment, one private network with a router and a floating IP is enough. As your project grows, separate tiers into distinct networks (web-facing instances on one network, application logic on another, databases on a third) and use routers and security groups to control traffic between them.

Consider your IP addressing scheme early. Subnet CIDR ranges cannot overlap within the same router, and changing them later means recreating the network. Plan for growth by using ranges larger than your immediate need.

## Further reading

**On this platform:**

- [Create a network](/docs/network/how-to/create-network): step-by-step network creation via Console, CLI, and API
- [Routers](/docs/network/concepts/routers): connect private networks to each other and to the internet
- [Floating IPs](/docs/network/concepts/floating-ips): stable public addresses for instances on private networks
- [Security groups](/docs/network/concepts/security-groups): port-level traffic filtering for network isolation
- [Ports](/docs/network/concepts/ports): the logical attachment between networks and instances

**External resources:**

- [OpenStack Neutron networking guide](https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html): upstream documentation for the software-defined networking layer
- [RFC 1918: Address Allocation for Private Internets](https://datatracker.ietf.org/doc/html/rfc1918): the standard defining private IP address ranges used in cloud network design