Managing Bare Metal VLANs and IP Blocks as Code

Network changes on dedicated infrastructure have traditionally been the slowest part of any project. A new private segment between two clusters meant a ticket, a wait, and a manual confirmation that the switch config was right. OpenMetal Central has supported self-service VLANs and IP blocks since 2025. The February 2026 release added deletion with safeguards and brought VLAN and IP block management into the public API. That means the network between your servers can live in the same scripts as the servers themselves.

Here’s the kind of task this is built for: you run an application tier on one bare metal cluster and a database tier on another. Keeping them as separate clusters lets each one use its own hardware, its own deployment configuration, and its own scaling schedule. But the application servers need to reach the databases over a private network, and the database traffic should never touch the public internet. You want that network defined in code, reproducible in another region, and removable cleanly when the environment is retired.

We’ve already written about why our network is designed the way it is, in our explainer on VLANs, VXLANs, and private networking and our piece on dedicated VLANs for multi-tenant environments. This article is about the day-to-day mechanics: what objects exist, which calls create them, and what rules govern them.

How OpenMetal Bare Metal Networking Is Wired

A short foundation helps the API calls make sense.

Every OpenMetal bare metal node ships with its two physical NICs bonded using LACP (802.3ad) into a bond0 interface, which provides redundancy and extra bandwidth. Each server has dual 10 Gbps private links, for 20 Gbps total, and traffic between your servers on private networks is unmetered. Our infrastructure guide covers the physical layout in more detail.

Every switchport connected to your node is configured as a trunk port. That means you can add VLANs on top of bond0 without any physical change, but only VLANs assigned to your cluster will pass through. So the workflow is always the same: provision the VLAN in Central (or through the API), then configure a subinterface on the node.

Some VLANs, such as the Inventory and Provider networks, are routed VLANs backed by virtual interfaces on our core switches, using VRRP for high availability. That has a practical consequence: every routed VLAN consumes five reserved IPs from each prefix. Those cover the VRRP gateway, the two core switches, the network address, and the broadcast address. A /28 routed block gives you 11 usable addresses, not 14.

The Object Model Behind VLANs, IP Blocks, And Clouds

Networking in the OpenMetal API works with three objects.

VLANs

A VLAN is created in a specific datacenter location and has a type:

• internal: for private, cluster-to-cluster traffic only
• routed: publicly routed

A set of VLANs is system-reserved: control, compute, storage, tunnel, octavia, inventory, and provider. Those can’t be altered or deleted by regular users. Only VLANs you create (marked created_from = "user") can be modified.

IP Blocks

An IP block (also called a prefix) is a CIDR range, also tied to a location. Types include:

• private: RFC 1918 space for internal networks
• routed: public addresses

The type pairing is strict. Private IP blocks must be assigned to an internal VLAN, and routed IP blocks must be assigned to a routed VLAN. An IP block isn’t usable until it’s assigned to a VLAN.

In the Central UI, private blocks can be created anywhere from /21 (2,048 addresses) down to /32, using addresses from the standard private ranges. Public blocks are purchased as add-ons attached to an active cloud, in sizes from 16 to 256 addresses. Our guide to adding IP blocks to a cloud walks through that process. If you have your own IP space, we also support bringing your own IP blocks of /24 or larger for announcement from our edge routers.

Clouds

In our API, a cloud is a collection of servers. That covers both a bare metal cluster and a Private Cloud Core. VLANs are assigned to clouds, which is what makes a VLAN pass through to the trunk ports of that cloud’s servers.

Managed Addressing

Each IP block has a managed addressing mode that controls whether we assign addresses to hosts for you:

• off: nothing is auto-assigned (the default for blocks created in Central)
• all: a host gets an IP from each block on the VLAN
• pool: if a VLAN has multiple blocks, they’re treated as one pool and each host gets a single address

For most custom private networks, “off” is the right starting point. You decide which host gets which address, either by configuring it on the node or by recording allocations through the API.

Building A Private Network Between Two Clusters

Here’s the scenario from the top: an application cluster and a database cluster in the same location, joined by a private network. Our guide to creating a private network between multiple clusters covers the Central UI version. Below is the same flow through the API.

Step 1: Create a Private IP Block

POST /v1/prefixes with a location, a type of private, and either a specific CIDR or a prefix length for automatic allocation:

{
  "label": "app-db-private",
  "description": "Private network between the app and database clusters",
  "fields": {
    "pod_location": "<pod_location>",
    "prefix_type": "private",
    "cidr": "192.168.50.0/24"
  }
}

Step 2: Create an Internal VLAN

POST /v1/vlans with the same location and a type of internal. You can assign the VLAN to a cloud at creation, attach an existing IP block at creation, or do both later in separate calls.

Step 3: Attach the IP Block to the VLAN

POST /v1/vlans/{vlanId}/prefixes/{prefixId} links them. The requirements are simple: both resources must be in the same location and owned by the same organization, and the IP block can’t already be assigned to another VLAN. You can also skip this step by passing the VLAN’s ID in the central_vlan_id field when you create the block.

Step 4: Assign the VLAN to Both Clusters

POST /v1/clouds/{cloudId}/vlans/{vlanId} once for the application cluster and once for the database cluster. A few rules apply:

• The cloud and VLAN must be in the same location.
• Both must belong to the same organization.
• The cloud’s provisioning status must be complete.
• A cloud can have at most 10 assigned VLANs.

That 10-VLAN limit is worth designing around if you plan to segment heavily at the infrastructure layer. If one of your clusters is a Private Cloud Core, OpenStack VPCs built on VXLAN give you additional isolated networks inside it without consuming infrastructure VLANs, as our network architecture explainer covers. The same VLAN steps work for connecting a bare metal cluster to a Private Cloud Core.

Step 5: Configure the Nodes

Once the VLAN is assigned, it’s passing through the trunk ports, but each node still needs a subinterface. With plain Linux tooling, it’s three commands:

ip link add link bond0 name bond0.1993 type vlan id 1993
ip addr add 192.168.50.5/24 dev bond0.1993
ip link set bond0.1993 up

Our infrastructure guide also shows NetworkManager (nmcli) and Netplan equivalents for RHEL-family and Ubuntu systems. Use whichever your configuration management already manages, so the subinterface survives a reboot. The VLAN ID to use comes back from the VLAN resource in the API.

A simple addressing plan keeps things readable. For example, give application nodes addresses from 192.168.50.10 upward and database nodes addresses from 192.168.50.100 upward. Then point your application’s database connection strings at the private addresses and bind the database listeners to the private interface only.

You can confirm the assignment on each cluster’s Networking page in Central, which lists every VLAN assigned to the cluster along with its IP blocks.

Step 6: Record IP Allocations

POST /v1/deployment/network/prefixes/{prefixId}/ip records an IP address in the block, with an optional label and assigned host. If you don’t specify an address, one is assigned automatically from the block. GET /v1/deployment/network/prefix/{prefixId} returns the block with every allocated address, which gives you a single source of truth for who holds what.

To unassign an address from a host, update it with an empty assigned_host. One rule to know: a host’s main IP can’t be reassigned or unassigned.

Tearing It Down In The Right Order

The February 2026 release added the ability to delete VLANs and IP blocks, with built-in safeguards against accidental removal. The API enforces a dependency order, which means your teardown scripts have to follow it too.

What Blocks Deletion

An IP block can’t be deleted if:

• It wasn’t created by a user (system-created blocks require support)
• It’s still assigned to a VLAN
• Any of its IP addresses are assigned to nodes

A VLAN can’t be deleted if:

• It wasn’t created by a user
• It’s assigned to a cloud or node
• It still has IP blocks assigned to it

System VLANs (control, compute, storage, tunnel, octavia, inventory, provider) can’t be deleted at all.

The Teardown Sequence

Working backward from the build:

1. Release IP allocations. Delete or unassign the IP addresses you recorded in the block.
2. Unassign the VLAN from clouds. Use DELETE /v1/clouds/{cloudId}/vlans/{vlanId}. This removes the association without deleting the VLAN. You can’t remove all of a VLAN’s assignments through this endpoint, since a VLAN needs at least one cloud assignment. Because a VLAN can’t be deleted while it’s assigned to a cloud, contact OpenMetal support to remove the final assignment when you’re retiring the VLAN entirely.
3. Unassign the IP block from the VLAN. DELETE /v1/vlans/{vlanId}/prefixes/{prefixId} leaves both resources active, and no billing changes occur from the unassignment itself.
4. Delete the IP block. DELETE /v1/prefixes/{prefixId}.
5. Delete the VLAN. DELETE /v1/vlans/{vlanId}.

If you’re scripting this, run it against the API sandbox first. The safeguards return clear validation errors, and it’s much better to discover a missed dependency there than in production.

Controlling Access To A Private Cloud’s Endpoints

If one of your clusters is a Private Cloud Core, one more network-adjacent endpoint deserves a mention. The API includes a firewall configuration for Private Cloud Cores on deploy suite v4.0.0 or later. GET /v1/deployment/cloud/{cloudId}/firewall returns the current configuration, including the customer allowlist and the cloud’s VLAN topology. PUT on the same path replaces the allowlist.

A few behaviors to plan around:

• It’s a full replace. The entire list is overwritten, not merged, so always send the complete desired list.
• It accepts IPv4 addresses and CIDRs only, up to 100 entries.
• Applying is asynchronous. A 200 response means the change was queued, not that it’s live. Poll the GET endpoint for the final status.
• A 409 response means another job is already running for the cloud. Wait and retry.

For teams that manage allowlists from a central source of truth, this lets the cloud’s access list be generated and applied from the same pipeline.

Why This Matters For Real Deployments

Three situations where networking-as-code pays off.

Separating Application And Data Tiers

Splitting tiers across clusters is a clean way to keep hardware matched to the job, with compute-heavy servers for the application and storage-heavy servers for the databases, while still giving them a private path to each other. When you add database nodes later, you assign nothing new: they join a cluster that already has the VLAN, and you configure the subinterface as part of the node build. Compare configurations on our hardware details page.

Multi-Region Builds

VLANs and IP blocks are location-scoped, so a multi-region design is the same set of calls repeated per location. If you’re building out in Amsterdam for EU data residency or in Singapore for APAC, a parameterized script gives each region the same network layout, with addressing you choose and record in one place.

MSPs Segmenting Customer Environments

For managed service providers, a VLAN per customer environment with its own private block is a clean boundary. Every OpenMetal customer already gets dedicated VLANs at the infrastructure layer, so traffic doesn’t share a broadcast domain with other OpenMetal customers. Within your own account, creating and removing per-customer segments through the API makes onboarding and offboarding repeatable. Our MSP program is set up for that model.

Who This Is For

A good fit if you:

• Run more than one bare metal cluster, or bare metal alongside a private cloud, and need private connectivity between them
• Want network changes version-controlled alongside server provisioning
• Build the same environment in more than one OpenMetal region
• Onboard and offboard customer or team environments regularly
• Need a reliable record of IP allocations for these ranges without a separate IPAM tool

Probably not the right fit if you:

• Have a single, static network that rarely changes (the Central UI will be faster)
• Need more than 10 infrastructure VLANs on a single cloud and can’t use OpenStack VPCs for the extra segmentation
• Expect the API to configure the operating system side; node subinterfaces are still yours to manage

The Short Version

Your servers and the private network between them should come from the same code. The Central API gives you VLANs, IP blocks, and cluster assignments as first-class resources, with safeguards that stop a teardown script from deleting something still in use.

If you want to build a scripted network across your clusters, apply for a proof of concept and test it on real hardware. You can also compare options on the bare metal pricing page or talk with our team about your network design.

Frequently Asked Questions

Can I create VLANs on OpenMetal bare metal through an API?

Yes. The OpenMetal Central public API supports creating, listing, updating, assigning, and deleting VLANs and IP blocks. You can assign VLANs to bare metal clusters and Private Cloud Cores, attach IP blocks to VLANs, and record individual IP allocations.

What’s the difference between an internal VLAN and a routed VLAN?

An internal VLAN carries private traffic between your clusters only. A routed VLAN is publicly routed and backed by virtual interfaces on OpenMetal’s core switches using VRRP. Private IP blocks must be assigned to internal VLANs, and routed IP blocks must be assigned to routed VLANs.

Why does a routed /28 block give me fewer than 14 usable IPs?

Routed VLANs reserve five addresses from each block: the VRRP gateway, two core switches, the network address, and the broadcast address. A routed /28 leaves 11 usable addresses for your devices.

How many VLANs can I assign to one cloud?

Each cloud can have a maximum of 10 assigned VLANs. Inside a Private Cloud Core, OpenStack VPCs running on VXLAN provide additional isolated networks without using infrastructure VLANs.

Why can’t I delete a VLAN or IP block?

Central’s safeguards block deletion when resources are still in use. An IP block can’t be deleted while it’s assigned to a VLAN or has addresses assigned to nodes. A VLAN can’t be deleted while it’s assigned to a cloud or has IP blocks attached. System VLANs and system-created blocks can’t be deleted by users.

Does assigning a VLAN configure my server’s network interface?

No. Assigning a VLAN makes it pass through the trunk ports to your cluster’s servers. You still create the subinterface on each node, for example with ip link, NetworkManager, or Netplan.

Can I connect two bare metal clusters on the same private network?

Yes. Create a private IP block and an internal VLAN in the same location, attach the block to the VLAN, and assign the VLAN to both clusters. The same steps work for connecting a bare metal cluster to a Private Cloud Core.