On this page

Operating Webserver-Front

Webserver-Front (FRONT) is a read-only replica of the Webserver that you place in a DMZ or any untrusted network to show dashboards and reports to end users — without exposing the internal control plane, the probes, or any secret. This page covers the day-to-day operation: deploying it, declaring the replication link, starting it, and verifying it stays fresh.

Throughout this page, ADMIN is the normal (licensed, internal) Webserver and FRONT is the read-only replica. For the architecture and trust model behind FRONT, see Webserver-Front (DMZ Replica).

When to deploy a FRONT replica

Deploy a FRONT replica when you need to publish dashboards to people who must not reach the internal Webserver:

  • Public or partner-facing status pages.
  • Dashboards embedded in a corporate portal that lives outside your management network.
  • Any audience on a network segment you do not fully trust.
FRONT is read-only. End users can browse applications, dashboards, history, SLA, and discovery maps, but they cannot add, edit, or delete anything, push to components, or reach the probes. All management stays on ADMIN.

Prerequisites

Before you start, make sure you have:

Requirement Notes
A licensed ADMIN Webserver FRONT is fed entirely by ADMIN; FRONT itself needs no license.
A DMZ host for FRONT Linux or Windows, reachable by your end users on the WEB port.
Network path ADMIN → FRONT ADMIN initiates and pushes. FRONT never connects back to ADMIN.
Replication material Shared key and certificates, provisioned out-of-band (see Configuration).

Deploy FRONT on the DMZ host

  1. Place the FRONT binary and its UI assets on the DMZ host. The static UI is served from disk in the ./web-front/ folder next to the binary (it is not embedded), so the host needs both the executable and that folder.

  2. Create the configuration file webserver.json next to the binary, then install it as a service or daemon exactly like a normal Webserver.

Linux:


# install and start the daemon
./webserver_front install
./webserver_front start

Windows:


webserver_front.exe install
webserver_front.exe start

You can run it in the foreground for a first test with ./webserver_front run (Linux) or webserver_front.exe run (Windows).

Replication uses two distinct channels, so two settings describe the FRONT host:

Setting Meaning
Replication endpoint The host:port of FRONT’s protected receiver. ADMIN pushes encrypted batches here.
Public URL The browser URL of FRONT’s web UI (for example https://front.example.com:9090). Used only to build shareable embed links that point at FRONT.

The cryptographic material itself (the shared key and the certificates) is provisioned out-of-band in webserver.json on both hosts. It never travels over the replication channel and is never entered in the Settings UI. The exact field list lives on the component page.

Declare FRONT from the ADMIN Settings page

Once the key material is in place on both hosts, enable and target the replication from ADMIN:

  1. Log in to ADMIN as an administrator and open the Settings page.
  2. In the Webserver-Front replication section, turn replication on, then fill in:
    • the replication endpoint (FRONT receiver host:port),
    • the public URL of the FRONT web UI,
    • the reconcile interval (how often ADMIN pushes a full snapshot — default 5 minutes),
    • the optional grace period (see below).
  3. Click save.
ADMIN Settings page: Webserver-Front replication configuration

Note:

Toggling replication on or off applies immediately to the running ADMIN, but a full effect (starting or stopping the push subsystem cleanly) is guaranteed after the next ADMIN restart. The replication key material is only re-read at startup — change it on both hosts and restart both.

Verify FRONT is live and fresh

  1. Browse to FRONT’s public URL and log in with a normal user account. User accounts (and their bcrypt password hashes) are replicated from ADMIN, so the same credentials work.
  2. Confirm the dashboards render and that the freshness indicator shows recent data. FRONT stamps each batch with the reconcile cadence and flags the feed as stale if no batch has arrived within a multiple of that interval.
Webserver-Front read-only dashboard with replication freshness indicator

What end users see on FRONT

FRONT renders the same dashboards as ADMIN, with two differences operators should expect:

  • Read-only everywhere. Management actions are hidden or disabled. There is no path to the probes, integrators, or settings.
  • Some live monitor types show as UNKNOWN. The Webserver fetches the status of url, api, tcp, udp, ping, nslookup, db, and sys monitors live from the probe on each request. Those types have no stored per-item status to replicate, so they appear as UNKNOWN in FRONT’s application-dependency graph. Device and discovery status are stored and replicated, and display normally.
FRONT application-dependency graph showing live monitor types as UNKNOWN

Status grace period

By default FRONT shows a status change as soon as it replicates. You can optionally configure a grace period so that a fresh OK → non-OK application status is held back from FRONT’s end users for a few minutes after the transition. This gives the operations team a short window to react before an outage becomes visible on a public dashboard.

The grace period affects only what FRONT shows. ADMIN’s own real-time views, status history, SLA calculations, and alerting are never delayed.

Day-to-day operations

Task How
Update the FRONT UI (logos, layout tweaks) Edit the files under ./web-front/ on the FRONT host and refresh the browser — no rebuild needed.
Restart FRONT Use the service/daemon commands (stop then start). FRONT re-reads its config and key material at startup.
Rotate replication keys Replace the key material on both hosts out-of-band, then restart both.
Check feed health Watch the freshness indicator on FRONT, and the push status on ADMIN.

Troubleshooting

Note:

The feed shows as stale. ADMIN cannot reach FRONT, or pushes are being rejected. Check that ADMIN → FRONT connectivity on the replication endpoint is open, that the key material matches on both hosts, and that FRONT logged no startup warning about missing replication material. Failed pushes are buffered to disk on ADMIN and retried automatically, so a brief outage self-heals once connectivity returns.
  • FRONT logs a loud warning at startup. Replication material is missing or incomplete on FRONT. Until it is fixed, FRONT rejects every incoming batch and the dashboards never update.
  • Everything shows UNKNOWN. Expected for the live monitor types listed above; not an error. Device and discovery status should still display normally.
  • A user cannot log in on FRONT. User records replicate from ADMIN on each reconcile. Confirm the account exists on ADMIN and that at least one successful reconcile has run since it was created.

See also

Translations

Embedding dashboards in a portal