Cloud-init Network Config Generator

Output target:

Choose where this YAML will be placed before boot.

Interface ID:

Examples: ens160, eth0, enp1s0, or id0 for a matched device.

Static address CIDR:

One address per line; prefixes are required.

Default gateway:

Leave blank only when another route source provides the default path.

DNS servers:

Resolvers are emitted under nameservers.addresses.

Search domains:

Optional; keep blank when no resolver search path is needed.

Static routes:

One route per line using destination,gateway,metric,table.

Samples stay local and overwrite the current form.

Renderer:

Optional network-config renderer field.

Match MAC address:

Optional; use lowercase colon-separated MAC notation.

Set interface name:

Optional target interface name after matching.

MTU:

Use only when the VM network requires a non-default MTU.

bytes

Default route metric:

Blank omits metric from generated default routes.

Mark interface optional

Adds optional: true so boot does not wait for this interface.

Use legacy gateway4/gateway6 keys

Default output uses routes with to: default; enable only for older images that require gateway keys.

{{ result.yaml }}

Field	Value	Output path	Note	Copy
{{ row.field }}	{{ row.value }}	`{{ row.path }}`	{{ row.note }}

Severity	Check	Detail	Recommendation	Copy
{{ row.severity }}	{{ row.check }}	{{ row.detail }}	{{ row.recommendation }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Cloud-init network configuration tells a new virtual machine how its network interface should come up during early boot. For static hosts, that usually means writing the interface name, one or more CIDR addresses, default routes, DNS resolvers, and any device matching rule before the image starts for the first time.

The stakes are practical. A wrong prefix can leave the guest unreachable, a gateway from the wrong IP family can make the default path fail, and a missing resolver can make the host look half-configured even when the address is correct. Static network data also tends to be prepared outside the guest, so small YAML mistakes often show up only after the VM has already booted.

Cloud-init network configuration flow from seed input through version 2 YAML into booted VM interface settings.

Version 2 network configuration is especially useful for repeatable VM images because the same YAML can be reviewed, versioned, and attached to a seed source. It is not a live connectivity test. The final check still happens on a disposable VM or staging clone where cloud-init, the guest image, and the selected renderer all behave like the production boot path.

Cloud-init and Netplan share much of the version 2 vocabulary, but portability depends on the target image. Configuration that works on a Netplan-based image may not work on an image that only supports cloud-init's narrower renderer path. Keep static network YAML conservative when the same seed file must boot across several distributions or image builds.

Technical Details:

Version 2 network configuration is a YAML map whose root either starts with version: 2 for a NoCloud network-config file or nests the same block under network: for a cloud-config drop-in. Ethernet definitions live under ethernets, and each definition can include static addresses, name service data, routes, device matching, and boot behavior.

Static addresses use CIDR notation, so the prefix length is part of the address value. That is why 10.44.50.21/24 carries more useful information than 10.44.50.21. The prefix tells the guest which addresses are on-link and helps decide whether an IPv4 gateway sits in one of the entered subnets.

Transformation Core:

Cloud-init network-config YAML transformation rules
Input area	YAML output	Rule used for this generator
`Output target`	`version: 2` or `network:` wrapper	NoCloud emits the network block at the top level; `cloud.cfg.d` indents the same block below `network:`.
`Interface ID`	`ethernets.<id>`	A plain interface name can be used directly. With a MAC match, the ID may be an opaque name and `set-name` can assign the final device name.
`Static address CIDR`	`addresses`	Each IPv4 or IPv6 address must include a valid prefix. Static families also emit `dhcp4: false` or `dhcp6: false`.
`Default gateway`	`routes` or `gateway4`/`gateway6`	Default output uses `routes` with `to: default`. The legacy switch emits gateway keys for older images.
`DNS servers` and `Search domains`	`nameservers.addresses` and `nameservers.search`	Resolvers must be literal IPv4 or IPv6 addresses. Search suffixes are checked as domain labels, not as URLs or paths.
`Static routes`	`routes`	Rows use `destination,gateway,metric,table`. Destination can be `default` or CIDR, gateway must match the route family, and metric must be a non-negative integer.

The validation rules are intentionally narrower than every possible Netplan feature. They match the visible generator controls and focus on static ethernet boot data: one interface definition, optional renderer choice, optional MAC match, optional rename, optional MTU, routes, name service, and a review table that separates errors, warnings, informational notes, and pass status.

Validation Boundaries:

Validation boundaries for generated cloud-init network configuration
Field or check	Boundary	Why it matters
`Interface ID` and `Set interface name`	Letters, numbers, dot, dash, underscore, and colon are accepted.	Risky characters can make the YAML hard to audit or the interface name unsafe for the target image.
`Static address CIDR`	IPv4 prefixes are `0` to `32`; IPv6 prefixes are `0` to `128`.	Missing or out-of-range prefixes block a reliable static address plan.
`Default gateway`	Only one gateway per address family is accepted.	Duplicate IPv4 or IPv6 defaults can make route priority ambiguous before the guest has booted far enough to troubleshoot.
`Match MAC address`	Lowercase colon-separated notation such as `00:11:22:33:44:55`.	Cloud-init expects lowercase MAC matches, and quoting the generated scalar avoids YAML type confusion.
`MTU`	Integer from `576` to `9216` bytes, or blank.	Blank keeps the image default; a custom value should match the VM network and upstream switch path.
`Default route metric`	Integer from `0` to `4294967295`, or blank.	The value applies only to generated `routes` output and is ignored when legacy gateway keys are enabled.

The output is deterministic for the same inputs. The YAML, Network Ledger, Validation Review, and JSON payload all come from the same parsed network data, so a warning in the review should be resolved before the YAML is copied into an image seed or cloud-config drop-in.

Everyday Use & Decision Guide:

Start with NoCloud network-config when you are preparing the separate network-config file for a seed drive or NoCloud source. Choose cloud.cfg.d snippet when the same network block must live inside a cloud-config drop-in under network:.

For a first static VM pass, fill in Interface ID, one Static address CIDR, one Default gateway, and the DNS resolvers that the guest should use immediately after boot. Add Search domains only when short hostnames must resolve inside a private DNS zone.

Use Static sample to return to a single-stack IPv4 example when the form has drifted during testing.
Use Dual-stack sample when you need IPv4 and IPv6 addresses, gateways, DNS, a MAC match, and a stable renamed interface in one example.
Leave Renderer blank for portable input unless the target image expects networkd or NetworkManager.
Add Match MAC address before using Set interface name. A rename without a tight match can point at the wrong adapter after hardware order changes.
Use Use legacy gateway4/gateway6 keys only when an older image rejects default routes written as routes with to: default.

The most common false confidence is a clean-looking YAML block with a bad route assumption. Check Validation Review for duplicate default gateways, a gateway family without a matching static address, a route destination that does not match its next hop family, or an IPv4 gateway outside the entered subnet.

Before attaching the YAML to a real build, read Network Ledger. It tells you which values landed at ethernets.<id>.addresses, routes[].to=default, nameservers.addresses, match.macaddress, and related output paths.

Step-by-Step Guide:

Work from the boot target first, then review the generated paths before using the YAML in an image build.

Choose Output target. The Cloud-init YAML tab should start with version: 2 for NoCloud or network: for the cloud-config wrapper.
Enter Interface ID. If you will match by MAC, use an opaque ID such as id0; otherwise use the expected device name such as ens160.
Add one address per line in Static address CIDR. If Validation Review reports that a prefix is missing, change the value to address/prefix form such as 10.44.50.21/24.
Enter one Default gateway per IP family, then add optional Static routes as destination,gateway,metric,table. Keep route destinations and gateways in the same IP family.
Add DNS servers and optional Search domains. Resolver entries must be IP addresses, while search domains should be plain domain suffixes.
Open Advanced only for renderer selection, MAC matching, interface rename, MTU, default route metric, optional boot behavior, or legacy gateway output.
Read Validation Review. Clear every Error, then decide whether each Warning reflects a real target-image choice or a mistake.
Use Network Ledger to audit output paths, then test the final Cloud-init YAML on a disposable VM before depending on it for a production boot.

Interpreting Results:

cloud-init network-config ready means no errors were found in the entered values and the YAML can be reviewed as a candidate. It does not mean the target image, datasource, renderer, or virtual network will accept it unchanged.

How to interpret cloud-init network-config generator outputs
Output cue	Meaning	Follow-up
`fix required`	At least one validation error is active.	Open `Validation Review` and correct the field named by the error before using the YAML.
`validated`	No error or warning rows are active.	Still test the selected `Output target` on a disposable VM, because image support is outside the form's validation.
`routes with to: default`	Default gateways will be emitted as route entries.	Use this for current images unless an older target requires `gateway4` or `gateway6`.
`gateway4/gateway6`	Legacy gateway output is enabled.	Remember that `Default route metric` is ignored in this mode.
`NetworkManager renderer` warning	The renderer depends on image and Netplan support.	Use `networkd` or omit the renderer when portability matters more than a specific backend.

The JSON view is useful for documenting the same parsed network data, but the YAML is the value cloud-init consumes. If the ledger and YAML disagree with the intended boot plan, fix the inputs rather than editing the copied YAML by hand.

Worked Examples:

Single-stack static VM

A VM on 10.44.50.0/24 can use Interface ID ens160, Static address CIDR 10.44.50.21/24, gateway 10.44.50.1, and two internal DNS servers. The summary should show ens160 static, and Network Ledger should list Static addresses as 10.44.50.21/24 with the default route model set to routes with to: default.

Dual-stack matched interface

A dual-stack guest can use an opaque Interface ID such as id0, addresses 10.44.50.21/24 and 2001:db8:44:50::21/64, IPv4 and IPv6 gateways, a lowercase Match MAC address, and Set interface name ens160. The badges should include ipv4 + ipv6, and the generated YAML should include both dhcp4: false and dhcp6: false.

Gateway review before boot

If the address is 10.44.50.21/24 but the gateway is 10.44.60.1, Validation Review adds a Gateway reachability warning because the gateway is outside the entered IPv4 subnet. That warning can be valid for unusual routing, but for ordinary VM networks it usually means the gateway or prefix should be corrected before the seed is used.

Legacy image with gateway keys

When an older image expects gateway4 or gateway6, turn on Use legacy gateway4/gateway6 keys. The Default route model row changes to legacy gateway output, and any Default route metric triggers a warning because metric is only emitted on generated route entries.

FAQ:

Should I choose NoCloud or cloud.cfg.d output?

Choose NoCloud network-config when creating the separate network-config file for a NoCloud seed. Choose cloud.cfg.d snippet when the network block will be placed under network: in a cloud-config drop-in.

Why does the address need a slash prefix?

Static addresses are emitted in CIDR form. Without a prefix such as /24 for IPv4 or /64 for IPv6, the guest cannot know the intended subnet size.

Why did set-name produce a warning?

set-name is safest with a unique match.macaddress. If you enter a final interface name without a MAC match, the review warns that the rename may not target one predictable device.

Can I use more than one default gateway?

Use at most one default gateway for IPv4 and one for IPv6. Duplicate gateways in the same family are reported as errors so the generated network data does not hide a route-priority problem.

Does the entered network data get sent to a server?

The form builds YAML, ledger rows, validation rows, and JSON in the browser. This tool has no separate generation endpoint for the network values entered in the form.

Glossary:

cloud-init: A boot-time configuration system commonly used by cloud images and VM templates.
NoCloud: A cloud-init datasource that can read local or remote seed data, including a separate network-config file.
network-config: The YAML network configuration data cloud-init can apply during early boot.
CIDR: Address notation that combines an IP address and prefix length, such as 10.44.50.21/24.
renderer: The backend expected to apply the network settings on the guest image, such as networkd or NetworkManager.
default route: The route used when no more specific route matches the destination.

References:

Networking config Version 2, cloud-init documentation, Canonical.
NoCloud, cloud-init documentation, Canonical.
YAML configuration, Netplan documentation.