Public Interface

Vexillum includes a public web interface for exposing reflector information without exposing administrative controls.

The public interface is intended for users, communities, clubs, and network participants who need to know what services are available, how the reflector is configured, and whether the system appears to be online.

It is separate from the admin interface. That separation matters.

Purpose

The public interface gives operators a safe place to publish user-facing reflector information.

It used to show:

• Available reflector modes
• Enabled mode instances
• Basic service status
• Connection details
• Public documentation links
• Operator or network information
• Community notes
• Maintenance notices

The goal is to help users connect successfully without giving them access to administrative tools, internal metrics, or sensitive runtime details.

Public interface versus admin interface

The public interface and admin interface serve different audiences.

Interface	Audience	Purpose	Typical exposure
Public interface	Users and communities	Human-readable reflector information	Public or semi-public
Admin interface	Operators	Management and configuration	Private
Metrics listener	Monitoring systems	Machine-readable runtime data	Private

The public interface should answer user questions like:

• What reflector services are available?
• Which modes are enabled?
• What address or port should I use?
• Is the system currently online?
• Where can I find client setup instructions?
• Who operates this reflector?

The admin interface should answer operator questions like:

• Which users can log in?
• Which mode instances are enabled?
• What changed recently?
• Which roles and policies are assigned?
• Are there audit events to review?

Keep those worlds separate. Giving users a status page is helpful. Giving them a control panel is how support requests become evidence.

Recommended exposure

The public interface may be safely exposed through HTTPS when configured appropriately.

A common deployment pattern is:

Service	Bind address	Public exposure
Public interface	127.0.0.1 or private address	Exposed through reverse proxy
Admin interface	127.0.0.1 or private address	Restricted
Metrics listener	127.0.0.1 or private address	Private
Protocol listeners	0.0.0.0 or specific interface	Public if needed

For most deployments, expose the public interface through a reverse proxy such as Caddy, nginx, or Traefik.

Reverse proxy layout

A simple hostname layout might look like this:

Hostname	Purpose
vexillum.example.net	Public reflector status
admin.vexillum.example.net	Restricted admin interface
metrics.vexillum.example.net	Restricted metrics endpoint, if exposed at all

The public hostname can be linked from club websites, QRZ pages, dashboards, documentation, or client setup guides.

The admin and metrics hostnames should be restricted by access control, VPN, firewall policy, or private network routing.

Suggested deployment pattern

A recommended deployment pattern:

1. Bind the public interface locally or to a private address.
2. Put it behind a reverse proxy.
3. Serve it over HTTPS.
4. Keep admin and metrics listeners private.
5. Publish only user-safe connection information.
6. Test the public page from outside your network.
7. Confirm no admin routes are reachable from the public hostname.

Example layout:

Internet
  |
  | HTTPS
  v
Reverse proxy
  |
  | http://127.0.0.1:<public-port>
  v
Vexillum public interface

Admin and metrics stay separate:

Operator VPN / SSH tunnel
  |
  v
Vexillum admin interface and metrics listener

Testing the public interface

From the Vexillum host:

curl -v http://127.0.0.1:<public-port>/

From another machine:

curl -v https://vexillum.example.net/

Check that the public hostname does not expose admin routes:

curl -I https://vexillum.example.net/admin

Depending on your routing model, this should return a redirect to the public site, a 404, a 403, or another intentionally restricted response.

What it should not do is hand over an admin login page unless that is explicitly part of your access-control design.

Common problems

Public page works locally but not externally

Check:

• DNS points to the correct server.
• The reverse proxy is running.
• TLS certificates are valid.
• The firewall allows inbound HTTPS.
• The reverse proxy upstream points to the correct local port.
• The public interface is listening on the expected address.

Public page exposes admin routes

Check:

• Reverse proxy route matching.
• Hostname separation.
• Path routing rules.
• Whether admin and public interfaces share a listener.
• Whether /admin is intentionally restricted.

Do not rely on “nobody will guess the path.” They will. Then bots will. Then some search index will. Then you’ll get to invent a new swear word.

Public page shows stale information

Check:

• Whether the mode instance is actually enabled.
• Whether the public interface reads live state or stored configuration.
• Whether the service needs a restart.
• Whether a cache or reverse proxy is serving stale content.
• Whether the status page is showing configured services rather than active services.

Users cannot connect even though the public page is online

The public interface being online only proves the web page works.

Check:

• Protocol listener ports
• UDP versus TCP firewall rules
• NAT forwarding
• Mode instance state
• Client configuration
• Logs for incoming packets or sessions
• Whether the published hostname resolves to the correct address

A working website does not prove the reflector protocol ports are reachable. Naturally, users will still treat it as proof of everything.

Operator checklist

Before publishing the public interface:

• Confirm public content is accurate.
• Confirm admin routes are not exposed unintentionally.
• Confirm metrics are not exposed unintentionally.
• Confirm published ports match firewall and NAT rules.
• Confirm each enabled mode has useful connection details.
• Confirm maintenance or beta warnings are visible where needed.
• Confirm the page works over HTTPS.
• Confirm the page works from outside the local network.
• Confirm users have a clear contact or support path.

Current status

The public interface may change as Vexillum continues development. Operators should review the current web UI behavior, route layout, and deployment configuration before exposing it publicly.