Admin Interface

Vexillum includes a built-in admin web interface for reflector operators.

The admin interface provides a central place to manage the Vexillum runtime, mode instances, users, roles, access policies, audit logs, and account security.

Purpose

The admin interface is intended for operational management.

It helps operators avoid turning every administrative task into a direct database edit, config-file surgery, or a half-remembered command from someone’s forum post in 2013.

Access

By default, the admin interface should be treated as a private service.

A typical configuration binds the admin listener to localhost:

[admin]
listen = "127.0.0.1:8080"

Operators can then access it through one of the following:

• Local browser on the host
• SSH tunnel
• VPN
• Reverse proxy with TLS and access controls
• Private management network

Avoid exposing the admin interface directly to the public internet unless you have intentionally designed the deployment around that risk.

The admin UI serves a nonce-based Content-Security-Policy - script-src has no unsafe-inline, and every inline <script> carries a per-request nonce instead. This matters if you front the admin interface with a proxy that rewrites HTML or injects its own scripts (an auth proxy’s login page, an ad/analytics injector, etc.): anything added outside Vexillum’s own rendering won’t have a valid nonce and will be blocked by the browser.

Dashboard

The dashboard provides a high-level view of the Vexillum runtime.

Depending on enabled features and current implementation, this may include:

• Runtime status
• Enabled modes
• Instance state
• Listener state
• Recent activity
• Administrative warnings
• Links to mode-specific management pages

The dashboard is usually the first place to check after starting or restarting Vexillum.

Your Account

Your Account section is used for your account security-related management.

This section includes:

• Username
• Session Expiry information
• Password change form
• Permissions overview

Bootstrap credentials should be rotated after initial setup. Leaving bootstrap credentials unchanged is how “temporary setup” becomes “permanent incident report.”

Bootstrap password rotation

After initial deployment, operators should rotate any bootstrap or setup password and create named administrator accounts.

Recommended flow:

1. Start Vexillum for the first time.
2. Log in using the bootstrap credentials. (u: admin, p: <bootstrap password>)
3. Rotate or disable the bootstrap password.
4. Store recovery information securely.

Access Control

User Accounts

The user accounts section manages accounts that can access the admin interface.

Operators should create named accounts for real users instead of sharing a single administrator login.

Named users make audit logs useful. Shared accounts make audit logs decorative, which is very on-brand for bad infrastructure decisions.

User management may include:

• Creating users
• Disabling users
• Updating user information
• Managing account security
• Assigning roles

Roles

Roles define groups of permissions.

Role-based access control helps operators separate responsibilities across users. This is useful for club systems, shared infrastructure, and larger networks where more than one person helps manage the reflector.

Example role types might include:

Role	Intended use
Administrator	Full operational control
Operator	Day-to-day reflector management
Viewer	Read-only access to admin status
Auditor	Access to logs and history

Actual roles and permissions should match the implementation and local operating policy.

Role Policy Editor

The Role Policy Editor defines what a role is allowed to do.

Policies should be kept as small as practical. Give users the access they need, not a ceremonial golden hammer for smashing the whole deployment.

A good policy model helps answer:

• Who can manage users?
• Who can change roles?
• Who can modify mode instances?
• Who can view audit logs?
• Who can change account security settings?
• Who can rotate bootstrap credentials?

Callsign Access List

The Callsign Access List page manages a global whitelist and blacklist, applied to every mode instance at connect/link time - not per-mode, not per-instance. If you have used urfd or XLXd, this is the same idea as their whitelist/blacklist files, now backed by SQLite and editable from the admin UI instead of hand-edited text files on the host.

Each entry is a callsign pattern: an exact callsign, or a callsign prefix followed by a trailing * wildcard (for example, W0CHP* matches any callsign starting with W0CHP). Matching is case-insensitive.

Rules are evaluated the same way as urfd:

• If the whitelist is empty, every callsign is allowed (subject to the blacklist below).
• If the whitelist is non-empty, a callsign must match an entry in it to be allowed.
• The blacklist always applies on top of the whitelist result. A blacklist match blocks the connection even if the callsign also matches the whitelist.

Changes take effect immediately for new connections - there is no polling interval and no restart required. This is a deliberate improvement over urfd/XLXd, which reload their list files on a periodic timer (around every 30 seconds).

Because the list is global, one entry protects (or opens up) D-Star, DMR, M17, NXDN, P25, VAFM, and YSF instances at once. There is no way to scope an entry to a single mode or instance.

Each row shows which admin account added the entry, alongside its “Added” timestamp - the same attribution recorded in the audit trail, surfaced directly on the list for a quick at-a-glance check.

Instances

Vexillum is built around mode instances.

A mode instance represents a configured service for a supported protocol. Operators can use instances to organize listener behavior and runtime state for each enabled mode.

Instance management includes:

• Viewing configured instances
• Checking whether an instance is enabled
• Reviewing listener information
• Inspecting mode-specific settings
• Starting from known defaults
• Separating services by protocol or purpose

For example, an operator might run three M17 instances, one YSF instance, and six VAFM instances from the same Vexillum deployment.

Publishing

The Publishing page manages activity publishing: the live feed Vexillum can send to the VexDV public directory and to your own MQTT brokers.

• Activity Publishing shows your installation ID and one row per destination configured in vexillum.toml. The public directory appears as public. Each row has its health, delivery counters (queued, sent, errors, rejected, dropped), and last error. If nothing is enabled, the page says so: nothing is published anywhere.
• Public Advertising lists every instance, with the connection endpoints the public feed would include and an Advertised switch. Instances are not advertised by default. Only advertised instances reach the public directory, or any broker set to the public profile. Endpoints with private, loopback, or link-local addresses are shown as withheld and never published.

Anyone who can view an instance sees its row. Changing Advertised needs permission to manage that instance, and every change is recorded with the user who made it. The installation ID and destination health need dashboard access, since error messages can reveal broker hostnames.

Bridges

The Bridges page marks which connected sessions are bridges rather than people. It has two parts.

• Designated Bridges lists each designation: the instance, the label, what it matches (a callsign, or on DMR a repeater ID), whether it’s required, and whether a matching session is connected now. matches N sessions warns that a designation catches more than the bridge, usually a station sharing its callsign or DMR ID (see One designation, one session). The form below the list adds a designation.
• Detected Bridge Connections lists sessions on any instance that look like a bridge running on the same host: a loopback address, or a DMR software ID starting with vex-. Each row shows whether it’s designated. Designate fills in the form from that row, leaving you to type the label.

Detection is only a hint. A session is reported as a bridge in activity publishing only once it’s designated. Each instance page’s client list shows the same thing in its Type column: Bridge with the label for a designated bridge, Undesignated bridge for one that’s only detected (it links here), and Client for everyone else. A designated bridge’s calls are labelled “via” its label, and a required bridge that isn’t connected marks its instance degraded. See Designate each bridge in Vexillum for which sessions to designate.

Labels are published with the instance’s activity, publicly too if the instance is advertised. Anyone who can view an instance sees its designations and detected connections. Adding or removing a designation needs permission to manage that instance, and each change is recorded in the audit log.

Audit log

The audit log records administrative activity.

Audit logs are useful for troubleshooting, accountability, and post-change review.

Operators should review the audit log when:

• A mode instance changes unexpectedly
• A user account changes
• Roles or policies are modified
• The callsign access list is modified
• Bootstrap credentials are rotated
• Administrative access is being reviewed
• A deployment behaves differently after a change

Audit logs are especially important on shared systems where multiple people have administrative access.

Operational recommendations

For safer administration:

• Keep the admin interface private.
• Use TLS when accessing it through a reverse proxy.
• Create named accounts for each operator.
• Use roles instead of giving everyone full admin access.
• Review audit logs after major changes.
• Rotate bootstrap credentials after setup.
• Remove accounts that no longer need access.
• Back up storage before upgrades.

Troubleshooting access

If the admin interface is not reachable:

1. Confirm Vexillum is running.
2. Check the configured admin listener.
3. Confirm the port is listening.
4. Check firewall rules.
5. Check reverse proxy configuration, if used.
6. Review logs for startup or binding errors.

Useful commands:

ss -ltnp | grep 8080

journalctl -u vexillum -n 100

If the listener is bound to 127.0.0.1, it will not be reachable from another machine unless accessed through SSH tunneling, VPN, or a reverse proxy.

Current status

The admin interface is part of the active Vexillum implementation and may continue to change as features mature. Operators should review release notes and configuration examples when upgrading.