Customer Portal¶

The self-service portal lets your customers sign in and look at the bandwidth on their own circuits, instead of calling the NOC to ask.

The portal is optional and off by default. Get the circuit list straight before you turn it on: every chart the portal draws comes from one record — which circuit lands on which port of which device. Get one wrong and a customer sees somebody else's traffic, which is why auto-linking only takes unique matches and leaves the rest for a human.

Start with the circuits¶

Visualization → Customer portal. It does exactly one thing: it ties device interfaces to customers, sites and circuit IDs. Its four tabs are Circuits, Customers, Customer accounts and Self-service portal.

Circuits is a plain circuit list — customer code / service name / service code / bandwidth / device / interface / interface description. Circuits get there three ways, and you can mix them:

Sync from config insight — interface descriptions are parsed in one place, config insight (this page does not parse them a second time: two parsers drift apart, and this data is what the portal reads). The sync condition ships empty; set it once to match your own description convention, e.g. "description contains CUS".
Import — one CSV row per circuit, optionally carrying its termination. The template is a download, and an export imports straight back in.
New circuit — by hand, for the occasional one-off.

Auto-link customers asks what to match on first: customer code (exact) or customer name (does the name appear in the circuit ID or interface description). Name matching only takes unique hits; anything matching two or more customers is listed separately for a human to decide. Links made by hand are marked as entered by hand and later syncs will not overwrite them.

Turning the portal on¶

Visualization → Customer portal → Self-service portal → Enable. That is the whole operation: the app writes a deployment request into its data volume, the host-side agent picks it up and starts the container, and the progress shows up in the UI.

The portal is a separate process running the same image (VCONFIG_ROLE=portal). It never connects to the database — it fetches everything over an internal API, and tenant filtering happens on the vConfig side. Nothing business-related is stored on the machine running the portal, so putting it in a DMZ does not expose your database.

To run it on another machine, choose another machine under Add portal instance; the UI gives you a command to run there.

Disabling takes effect immediately: every portal token is revoked on the spot and signed-in customers are cut off, rather than being left until their session expires.

Customer accounts¶

Visualization → Customer portal → Customer accounts. Creating an account also opens the portal for that customer. The password is shown when you create it, with one-click copy; resetting works the same way.

A customer can have several accounts. The owner flag is only a marker — there is no "manage other accounts" on the customer side, so the accounts carry the same rights.

Domain and port¶

By default the portal and the admin UI both answer on 443, routed by domain name (aiops.example.com inside, portal.example.com outside, in the usual arrangement). This needs no second IP address: the router reads only the server name from the TLS handshake and hands connections for the portal domain to the portal. Everything else — unknown names, and connections with no name at all — goes to the admin UI, so it can never drop a visitor into the portal by accident.

Leave the portal domain empty and you fall back to "the portal gets its own port", which means your customers have to remember an address with a port number in it.

Switching to name-based routing recreates the containers, so the UI is unreachable for about 30 seconds; you are asked to confirm first. The admin UI also keeps an internal port (18443) as a way back in if the router itself ever fails.

Certificates¶

Self-service portal → Upload certificate. Upload the certificate and key files, or press Reuse the system certificate to take the one the admin UI already uses — most ISPs hold a *.yourcompany.com wildcard, and the two are on the same domain anyway.

Uploads are validated on the spot: does the key match the certificate, has it expired, which names does it cover.
The key must not be password-protected — the portal starts unattended and nobody is there to type one.
Without a certificate the portal falls back to a self-signed one, and the first thing your customer sees is the browser's "not secure" warning, which undoes everything else you did here.

What the customer sees¶

Their sites and circuits on the left, the bandwidth chart on the right: inbound and outbound, peak, 95th percentile, and how much of the contracted bandwidth that represents. Ranges run from one hour to one year, and any period can be dragged out directly on the chart.

Device and interface names are hidden by default (Show device and interface names, off by default) — most ISPs would rather their customers did not know which box they land on.
The customer picks the interface language from 8 options; the first visit follows their browser.
Your logo and portal name sit top left, and the footer is the one you set in system settings. Your customer sees your brand, not ours.
When the data is incomplete it says so: how many interfaces are missing, and the date the history actually starts. "Nothing older was kept" beats a curve we made up.

Upgrades¶

The portal container lives outside compose, so vconfigctl update refreshes it onto the new image as its final step. There is nothing to do by hand.