Skip to content

web ui tour

Thomas Mangin edited this page Jul 25, 2026 · 2 revisions

Pre-Alpha. This page describes behavior that may change.

The web UI is the same engine as the CLI with a different surface on top. It reads and writes the same config tree, validates against the same YANG schemas, and uses the same user database for authentication. If you can do something at the CLI, you can do it in the browser. This page is the five-minute tour. The full reference lives at interfaces/web-ui.md.

Ze Web UI

Starting it

The web server is part of the Ze daemon. You start it with the --web flag or by enabling it in the config.

ze start --web 3443

By default Ze generates a self-signed ECDSA P-256 certificate on first start. That is fine for a local trial. Put a real certificate in front of it before you expose the port. There is a --insecure-web flag for development that skips authentication, but it forces the listener back to 127.0.0.1 so you cannot accidentally publish an unauthenticated UI.

Logging in

Open https://<host>:3443/. Unauthenticated requests get a login form. You log in with the same username and password you would use over SSH, because the web server uses the same user database. On success Ze sets a session cookie that is Secure, HttpOnly, and SameSite=Strict, and one user has one session at a time. Logging in from a second browser invalidates the first.

For automation that prefers raw HTTP over MCP or SSH, every URL accepts ?format=json or an Accept: application/json header, and API clients authenticate with HTTP Basic.

Navigating the config tree

The left panel is a Finder-style column browser, the kind macOS users will recognise. You click into a container, a new column slides in to the right, and you keep going until you hit a leaf or a list. Three columns are visible at a time, and they scroll horizontally as you go deeper.

Named containers (peers, groups, anything with a YANG key) appear above the unnamed ones, with a separator between them. Lists with unique constraints render as a table in the detail panel, with the key and unique fields as columns. You rename, edit, and delete entries inline. There is a + new button under every list that opens a small server-rendered form, with the YANG types validated before the entry is created.

A breadcrumb at the top mirrors the YANG path, and every segment is a link.

Edit, diff, commit

Each authenticated user gets an independent draft session. Your edits are tracked per user and never affect anyone else until you commit.

The flow is a four-step loop. You navigate to the leaf or list you want to change. You edit it in place: text and number fields auto-save one second after you stop typing, and they also save on blur and Enter. The commit bar at the bottom of the page tracks the count of pending changes. You click "Review and Commit", read the diff, and either commit or discard.

Conflicts with another user are detected at commit time, not at edit time, and the conflict report names the paths and shows both values. You resolve them and try again.

If a colleague commits while you have the page open, a Server-Sent Events stream pushes a notification banner with their username and a Refresh button.

The CLI bar

Every page has a CLI bar at the bottom that takes the same grammar as the SSH shell. The bar carries the current URL path as context, so a set or delete runs against whatever you are looking at. Tab completion calls back to the server for context-aware candidates: at /show/bgp/peer/upstream/, typing set and Tab offers the children of that peer entry.

There is also a terminal mode for when you want a scrollback shell in the browser instead of integrated commands.

Where to go next

Adapted from main/docs/features/web-interface.md and main/docs/guide/web-interface.md.

Home

About

First Steps

Configuration

Operation

Interfaces

Plugins

Plugin Development

Chaos Testing

Blueprints

Development

Reference

Clone this wiki locally