cloudflare · nikitacano · May 7, 2026
@@ -2,6 +2,9 @@
 title: Configure your Magic WAN Connector to connect via static IP assignment
 description: Local console access for bootstrapping Magic WAN Connector
 date: 2025-02-14
+products:
+  - cloudflare-one-appliance
+  - cloudflare-one
 ---
 
 You can now locally configure your [Magic WAN Connector](/cloudflare-wan/configuration/appliance/) to work in a static IP configuration.

@@ -3,6 +3,7 @@ title: Cloudflare One Appliance supports multiple DNS server IPs
 description: DHCP server settings now accept multiple DNS server IP addresses
 date: 2025-04-30
 products:
+  - cloudflare-one-appliance
   - cloudflare-one
 ---
 

@@ -3,6 +3,7 @@ title: Virtual Cloudflare One Appliance with KVM support (open beta)
 description: Deploy the virtual appliance on KVM-based hypervisors with Proxmox VE support
 date: 2025-07-21
 products:
+  - cloudflare-one-appliance
   - cloudflare-one
 ---
 

@@ -3,6 +3,7 @@ title: Designate WAN link for breakout traffic
 description: Pin breakout traffic to specific WAN ports for deterministic egress control
 date: 2025-11-06
 products:
+  - cloudflare-one-appliance
   - cloudflare-one
 ---
 

@@ -3,6 +3,7 @@ title: Breakout traffic visibility via NetFlow
 description: NetFlow export from Magic WAN Connector for breakout traffic monitoring
 date: 2025-12-31
 products:
+  - cloudflare-one-appliance
   - cloudflare-one
 ---
 

@@ -3,6 +3,7 @@ title: Post-quantum encryption support for Cloudflare One Appliance
 description: Hybrid ML-KEM protects appliance traffic against harvest-now, decrypt-later attacks
 date: 2026-02-11
 products:
+  - cloudflare-one-appliance
   - cloudflare-one
 ---
 

@@ -3,6 +3,7 @@ title: Link aggregation (LACP) support for Cloudflare One Appliance
 description: Bundle physical LAN ports into a single logical interface for redundancy and bandwidth.
 date: 2026-04-07
 products:
+  - cloudflare-one-appliance
   - cloudflare-one
 ---
 

@@ -0,0 +1,14 @@
+---
+title: Custom DHCP options on Cloudflare One Appliance
+description: Configure DHCP options on the appliance's DHCP server, including options for PXE / iPXE boot.
+date: 2026-05-07
+products:
+  - cloudflare-one-appliance
+  - cloudflare-one
+---
+
+When the Cloudflare One Appliance is acting as the DHCP server for a LAN, you can now configure custom DHCP options on the leases it issues. This unlocks workflows such as PXE / iPXE boot, VoIP phone provisioning, and vendor-specific client configuration.
+
+Each option is defined by `option_number`, `value`, and one of four value types: `text`, `integer`, `hex`, or `ip`. Configurations are validated on the appliance before being applied — invalid configurations are rejected and the underlying error is returned to the API caller, so a bad option will not disrupt the live DHCP service.
+
+For details, refer to [DHCP server options](/cloudflare-wan/configuration/appliance/network-options/dhcp/dhcp-options/).
@@ -0,0 +1,17 @@
+---
+title: Source-based breakout and prioritization on Cloudflare One Appliance
+description: Define breakout and priority rules by source LAN, VLAN, or CIDR — in addition to destination application.
+date: 2026-05-07
+products:
+  - cloudflare-one-appliance
+  - cloudflare-one
+---
+
+Breakout and traffic prioritization rules on the Cloudflare One Appliance can now match by **source** in addition to destination application. You can pin breakout or priority behavior to:
+
+- A source LAN interface — VLANs attached to that LAN are included automatically.
+- A source IP address, range, or CIDR block.
+
+This is the natural way to break out a guest VLAN to the local Internet, or to prioritize traffic from a specific subnet, without enumerating destination applications.
+
+For details, refer to [Breakout traffic](/cloudflare-wan/configuration/appliance/network-options/application-based-policies/breakout-traffic/#breakout-by-source).
@@ -0,0 +1,18 @@
+---
+title: Self-serve provisioning of Cloudflare One Virtual Appliance via API
+description: Create, rotate, and delete Cloudflare One Virtual Appliance instances and license keys directly through the API and Terraform.
+date: 2026-05-07
+products:
+  - cloudflare-one-appliance
+  - cloudflare-one
+---
+
+You can now create, rotate, and delete Cloudflare One Virtual Appliance instances and their license keys directly via the API and Terraform.
+
+- Create a virtual appliance and receive a license key: `POST /accounts/{account_id}/magic/connectors` with `device.provision_license: true`.
+- Rotate the license key for an existing virtual appliance: `PATCH /accounts/{account_id}/magic/connectors/{connector_id}` with `provision_license: true`. The previous key is immediately and irrevocably revoked.
+- Delete a virtual appliance to release the associated licensed device.
+
+The license key is returned in the response only once, at create or rotate time. Copy and store it securely.
+
+For details, refer to [Configure a Cloudflare One Virtual Appliance](/cloudflare-wan/configuration/appliance/configure-virtual-appliance/).
@@ -0,0 +1,13 @@
+id: SmaYeH
+name: Cloudflare One Appliance
+
+entry:
+  title: Cloudflare One Appliance
+  url: /cloudflare-wan/configuration/appliance/
+  group: Cloudflare One
+  additional_groups: [Network security]
+
+meta:
+  title: Cloudflare One Appliance docs
+  description: Connect branch sites to Cloudflare One with a managed hardware or virtual appliance
+  author: "@cloudflare"
@@ -8,7 +8,17 @@ sidebar:
   order: 4
 ---
 
-import { Render } from "~/components";
+import { Render, Aside } from "~/components";
+
+<Aside type="note" title="Self-serve provisioning via API">
+
+You can create, rotate, and delete Cloudflare One Virtual Appliance instances directly via the API or Terraform. Each request returns a license key that you use to activate the deployed VM.
+
+- Create a virtual appliance: `POST /accounts/{account_id}/magic/connectors` with `device.provision_license: true`. The response includes `result.license_key` — copy and store it securely, as it is shown only once.
+- Rotate the license key: `PATCH /accounts/{account_id}/magic/connectors/{connector_id}` with `provision_license: true`. The previous key is immediately and irrevocably revoked.
+- Delete a virtual appliance: deletes the associated licensed device in the same operation.
+
+</Aside>
 
 <Render file="mconn/configure-connectors"
 	product="networking-services"

@@ -17,4 +17,21 @@ import { Render } from "~/components";
 	trafficSteeringURL: "/cloudflare-wan/reference/traffic-steering/",
 	whatHappensApp: "will now go directly to the Internet and bypass Cloudflare's filtering",
 	dashName: "Cloudflare WAN",
-	}} />
+	}} />
+
+## Breakout by source
+
+In addition to matching by destination application, you can define breakout rules that match by **source** — by source LAN interface, source VLAN, or source IP address / CIDR block. This is useful for breaking out an entire guest VLAN or a specific subnet to the local Internet without enumerating destination applications.
+
+Source-based breakout is configured via the API and Terraform.
+
+### Match criteria
+
+| Criterion             | Behavior                                                                                          |
+| --------------------- | ------------------------------------------------------------------------------------------------- |
+| Source LAN interface  | All traffic originating on the selected LAN is broken out. Any VLAN attached to that LAN is included automatically. |
+| Source CIDR / IP range| All traffic with a source IP in the specified range is broken out. Accepts a single IP, a range, or a CIDR block.   |
+
+The same criteria can be used to mark traffic as **prioritized** instead of broken out. Refer to [Prioritized traffic](/cloudflare-wan/configuration/appliance/network-options/application-based-policies/prioritized-traffic/) for details.
+
+Source-based and destination-based (managed app or custom app) rules can co-exist on the same appliance and are evaluated independently. If a flow matches both a source-based breakout rule and a destination-based breakout rule, the appliance breaks it out.
@@ -0,0 +1,64 @@
+---
+pcx_content_type: how-to
+description: Configure custom DHCP options on the Cloudflare One Appliance DHCP server, including options for PXE / iPXE boot.
+products:
+  - cloudflare-wan
+title: DHCP server options
+---
+
+When the Cloudflare One Appliance is configured as the DHCP server for a LAN, you can attach **custom DHCP options** to the leases it issues. This is commonly used for:
+
+- **PXE / iPXE boot** of workstations or kiosks (options 66, 67, 60, 43, 175, 209–211).
+- **VoIP phone provisioning** (option 66 — TFTP server).
+- **Vendor-specific client configuration** (option 43 with vendor sub-options).
+
+DHCP options can only be configured when the appliance is acting as the DHCP server. They have no effect when the appliance is in [DHCP relay](/cloudflare-wan/configuration/appliance/network-options/dhcp/dhcp-relay/) mode.
+
+DHCP options are configured via the API and Terraform.
+
+## Option format
+
+Each option is defined by three fields:
+
+| Field           | Description                                         | Example                |
+| --------------- | --------------------------------------------------- | ---------------------- |
+| `option_number` | The DHCP option code (1–254).                       | `67`                   |
+| `type`          | The value encoding: `text`, `integer`, `hex`, `ip`. | `text`                 |
+| `value`         | The option value, encoded per `type`.               | `boot/x64/pxelinux.0`  |
+
+### Value type encoding
+
+| Type      | Format                                                      | Example value                 |
+| --------- | ----------------------------------------------------------- | ----------------------------- |
+| `ip`      | A dotted-quad IPv4 address.                                 | `10.20.30.40`                 |
+| `integer` | A decimal integer.                                          | `0`                           |
+| `text`    | A UTF-8 string.                                             | `boot/x64/pxelinux.0`         |
+| `hex`     | A colon-separated sequence of bytes, used for sub-options.  | `01:04:aa:bb:cc`              |
+
+## Common PXE / iPXE options
+
+The most frequently used options for PXE / iPXE boot are:
+
+| Option | Type    | Purpose                                                                              |
+| ------ | ------- | ------------------------------------------------------------------------------------ |
+| 60     | `text`  | Vendor class identifier (typically `PXEClient`).                                     |
+| 66     | `ip` or `text` | TFTP server name or IP address (boot server).                                |
+| 67     | `text`  | Bootfile name to load (for example `ipxe.pxe` or `undionly.kpxe`).                   |
+| 43     | `hex`   | Vendor-specific information; sub-option layout is vendor-defined.                    |
+| 175    | `hex`   | iPXE-specific encapsulated options (HTTP/HTTPS boot, iSCSI, DNS, and more).          |
+| 209    | `text`  | iPXE configuration file URI.                                                         |
+| 210    | `text`  | iPXE configuration file path prefix.                                                 |
+| 211    | `text`  | iPXE configuration file path.                                                        |
+
+For a complete list of standard DHCP option codes, refer to the [IANA BOOTP/DHCP parameters registry](https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml).
+
+## Validation and apply behavior
+
+Before applying a new DHCP options configuration, the appliance:
+
+1. Stages the change to a temporary configuration file.
+2. Validates the syntax with the underlying DHCP server.
+3. **On success**, atomically swaps the staged configuration into place and reloads the DHCP server with no service interruption.
+4. **On failure**, discards the change and returns the underlying validation error to the API caller. The live DHCP service is never restarted with an unverified configuration.
+
+This means a malformed option will be rejected at apply-time rather than disrupting DHCP service for clients on the LAN.