Operator panel

The operator panel lives under /operator and is the operator’s view. It is deliberately its own world: its own accounts, its own token, its own roles. A tenant login never gets in here, and an operator login opens no tenant application.

What keeps the separation intact

Until July 2026 the name of the cookie separated the two worlds — an operator cookie could not even arrive at a tenant route. Now that the login travels in the Authorization header, both use the same transport, and the separation rests on one field in the session: its scope (operator, or empty for tenants).

It is checked at every entrance, not only where it would be noticed. Both directions are pinned down by tests: an operator token on a tenant route yields 401, and so does a tenant token at the panel.

It is reachable only via the direct link — the normal interface has no reference to it.

Accounts and roles

Role	May
admin	everything, including management of operator accounts
consult	registry and reporting
support	assist tenant users (contact details, password reset)

The first account is created on the very first start from DNSE_OPERATOR_USER and DNSE_OPERATOR_PASSWORD and is an administrator. Further accounts are created by an administrator in the panel.

Every operator account can secure itself with TOTP two-factor under My account; disabling it requires the current password. Given the reach of these accounts, this is strongly recommended.

What the panel shows

Dashboard — metrics on organisations, users, zones and accounts, plus the distribution across plans.

Organisations — the registry: per tenant its plan, metrics and user list. From here you can change plans, correct contact details and reset passwords. With backups configured, restore points and Export now are added (Backup and restore).

System — the cluster configuration as a read-only view: which core settings are set via environment variables and how organisations and users are distributed across the regions.

The Regions tab shows the region catalogue: per region its code, label, the reserved domains (frontend, backend, DynDNS, agents) and the figures. Below that the loaded catalogue: where it came from (file, environment or built-in), its fingerprint and the lifetimes in force for sessions and DNS records.

What is shown is deliberately the state this node holds in memory, not the file on disk. You already have the file; what you cannot see is a node that never read it. Hence the catalogue per node below: when they run with differing fingerprints, a clear warning appears at the top — the rollout is then half-finished, and different nodes may hand out different backend domains. Nothing can be edited here: the rolled-out file is authoritative.

Settings and messages — the platform level: core settings and portal messages that appear as banners for all tenants. The operator maintains both once, centrally; these pages are hidden in the tenants’ admin panels. Outbound mail can be set per region (smtp.<region>.* — a node takes its own region’s block and falls back to the global smtp.* values without one). DynDNS hostnames and the public address no longer appear here: in the cloud they come from the region catalogue.

Data residency and moving

Selecting an organisation reveals the Data residency section: where its data actually sits — the declared home region per plan against the real distribution of events, counted across every event table.

The report answers three questions nobody could answer before:

• A customer asks where their data is. Previously we could only state the intent, not the state.
• Has intent drifted from reality? Operations never notices, because the application never filters reads on geo.
• Is a move really finished? Without a count, “finished” would be a claim.

It runs on demand only — the count spans every event table and does not belong in the overview list.

Two zeros are not the same thing. If the count cannot be obtained, it says so — not “0 events elsewhere”. Not counted is not the same as clean.

Skipped are org_plan and plan_acceptance. They do carry a tenant id, but they describe the organisation rather than being its data: they live in the primary region and do not move along. The report names them, so it stays visible what it is not talking about.

The move

Next to it sits the region selector with Move organisation (role admin only). The move relocates all of the organisation’s data — event log, archive, snapshots and read model together.

The order is deliberate: the home region is rewritten first, then the data moves. That way writes during the move already land at the target, instead of the move chasing a target that keeps moving.

The response is not a “done” but the count afterwards. Only outside the declared region: 0 proves a complete move. If the run aborts, “target declared, data partly still there” remains — the honest state, and a visible one. Repeating resumes; the call is idempotent.

Moving into the already declared region is allowed and no no-op: it clears the leftovers an aborted run, or an organisation from before regions existed, left behind.

The other nodes pick up the new assignment within half a minute (cached assignment, regionCacheTTL). Until then they still write to the old region — which is exactly why the move is repeatable.

No DNS data

The registry shows numbers, not zones. An operator sees that an organisation manages 42 zones — not which ones. Whoever is meant to help with content needs a regular share in the affected project.

Machine access

DNSE_OPERATOR_TOKEN allows access to the operator API without sign-in (header X-Operator-Token) and counts as an administrator. It is intended for the checkout frontend and automation — not as a convenient entrance for humans. Where it is not needed, it should be omitted.