1. Describe the state you want

Your desired-state YAML describes supported listeners, virtual hosts, routes, upstreams and policies. You can author it directly or use the Console's guided controls. A draft is only proposed intent; it is not yet serving traffic.

The browser is not a separate configuration authority. The internal configuration service validates the document and prepares the immutable artifact that the data plane will use. Free operator paths are YAML, CLI and the optional no-cost proprietary Console. Supported programmatic management, API documentation and external integration contracts are Enterprise scope.

2. Validate and preview

Validation checks the supported configuration contract. Preview lets an operator compare the proposed artifact with its baseline: which routes, upstreams or other resources change? A successful validation does not prove that an upstream is healthy or that the change meets your business objective.

3. Activate and inspect the result

Activation is an explicit operation. Read the authoritative rollout and node status rather than trusting a local browser success message. Each node must report what happened to the intended artifact.

Some changes cannot activate without a restart. In the recorded listener-change test, the data plane rejected the change with a restart-required reason while existing traffic continued using the earlier configuration. Not all edits are hot-reloadable.

4. Keep desired and observed state separate

Desired state is what an operator requested. Observed state is what the gateway confirms it is serving. A disconnected node may have stale observations; the interface must not interpret silence as a successful change.

A control-plane outage does not require a data plane to stop using its already active snapshot. However, serving independence is not the same as being able to publish new configurations while the controller is unavailable.

5. Recover without rewriting history

Exact rollback restores a retained artifact under a new rollout sequence. A rejected candidate and its diagnostics remain part of history. To correct it, create a new draft; do not change the evidence of the rejected attempt.

A rollback can restore routing intent. It cannot reverse a payment, message, or other side effect already performed by an upstream. Applications remain responsible for business-level idempotency and recovery.

This is a conceptual guide, not a complete deployment procedure. Authentication, confirmation requirements, supported changes and restart boundaries must follow the exact release documentation.

See the recorded Console workflow or return to the learning library.