Skip to main content


Learn more about network options for Virtual Servers.

Networking for Virtual Servers can be as simplistic or as fine-grained as your use case dictates. If you'd like to attach a Public IP or LoadBalancer IP to your Virtual Server, this is the section to do it.

Additional Resources

To learn more about networking on CoreWeave cloud, see Networking.

Deployment method: CoreWeave Cloud UI

From the CoreWeave Cloud UI Virtual Server deployment menu, click the Network expandable.

Attaching IPs

More advanced networking options for Virtual Servers are configured by interacting directly with the YAML editor, but Public IP and LoadBalancer IP configuration options are also exposed via graphical toggles in this expandable. These toggles are switched on and off according to whether or not you want the Virtual Server to have either kind of IP address provisioned to it.

Attaching a Public IP to the Virtual Server will allow it to be accessible through the Internet via an assigned IPv4 address by a created Kubernetes service. When network.directAttachLoadBalancerIP is turned on (true) a new Service will be created, and its LoadBalancer IP will be directly attached to the Virtual Server.

The graphical toggles affect the network.directAttachLoadBalancerIP and .network.public options in the CRD manifest respectively, toggling their values between true and false.\

When both options are set to true, public networking is provided via an automatically-provisioned public IP address. When both are false, public networking is disabled, and no public IP will be provisioned.

Example in plain text:

public: true
directAttachLoadBalancerIP: true

When both network.directAttachLoadBalancerIP and network.public are set to false, the Virtual Server Operator (VSO) creates a "Headless Service," in order to resolve internal DNS using cluster DNS.

When network.directAttachLoadBalancerIP is set to true, custom UDP and TCP ports may not be set.

Additional networking options

All other networking options for Virtual Servers provisioned through the CoreWeave Cloud UI must be configured through the YAML manifest.

Custom MAC addresses

By default, a persistent MAC address, derived from the Virtual Server's name, is assigned to the Virtual Server. To override this, you may include MAC address configurations in the .network.macAddress field.

Custom MAC addresses for Virtual Servers are configured with dashes separating each octet:

macAddress: A2-1F-EE-09-06-5D

DNS policy

DNS policies for Virtual Servers refer to the Kubernetes Pod DNS policies. By default, Virtual Servers have a DNS policy of ClusterFirst.

TCP and UDP ports

The TCP and UDP ports to expose on the Virtual Server are configured using the tcp.ports and udp.ports lists in the YAML manifest respectively.


When network.directAttachLoadBalancerIP is set to true, custom UDP and TCP ports may not be set.

Desired ports may be configured in their respective lists, as seen in this example:

Example in plain text:

public: true
directAttachLoadBalancerIP: false
- 22
- 443
- 3389
- 3389
- 4172

Floating IPs

Floating IPs allow stable IP addresses to be assigned from the load balancer IP of each Service. These allow for custom DNS configurations, and predictable addressing.

Floating IPs can be specified in the YAML manifest using a YAML list:

floatingIPs: [,]

Learn more about Floating Services.

Attaching a Layer 2 VPC

A Virtual Server may be attached to one or multiple VPCs, as well as to the regular CoreWeave Cloud Native Kubernetes (CCNN) network.

Each VPC will be represented as a separate Network Interface Card (NIC) inside the Virtual Server, in addition to the CoreWeave network (CCNN). The NICs inside a Virtual Server will be in the same order as the VPCs are specified - the order is deterministic to ensure that a NIC inside the Virtual Server always connects to the same VPC, even through reboots and migrations.


Learn more about CoreWeave Layer 2 VPCs.

By default, CoreWeave Cloud Native Networking is enabled. To disable CoreWeave networking, set disableK8sNetworking to true.


CoreWeave Cloud Native Networking is designed with low latency and high isolation in mind. Even when a VPC is in use, it is recommended to leave the regular networking attached for Internet access while leveraging the VPC interface for things like on-premise connectivity.

Additionally, disabling CoreWeave Cloud Native Networking means loss of all regular Kubernetes networking functionality, such as Services, Load Balancers and internet access. The Pod will only be able to communicate on the specified VPCs. For internet access, a virtual firewall can be deployed bridging a VPC and a regular CCNN interface. For most Kubernetes use cases, it is not recommended to disable the standard network.

Also note that if disableK8sNetworking is set to true and a VPC is designated, no k8s (paravirtual) NIC will be attached - only the VPC will be attached.

CoreWeave support is available to help with any network design questions.

Layer 2 VPCs may be attached to Virtual Servers using the following methods:

Deployment method: CoreWeave Cloud UI

VPCs that are deployed in the client namespace are associated with Virtual Servers by configuring their addresses within the YAML spec of the Virtual Server to be associated.

VPC names are configured inside the .network.vpcs stanza in the YAML manifest:

vpcs: []
- name: vpc0
- name: vpc1
# If disableK8sNetworking is set to `true` and a VPC is defined, no k8s (paravirtual) NIC will be attatched
disableK8sNetworking: false