eKYC Deployer

This is work software, built for the internal team that deploys and supports a Botswana-based company's eKYC platform on customer infrastructure. It is an operations console for a fleet of customer deployments, where each deployment is a site with its own production, staging and test environments on separate virtual machines.

It runs scheduled checks against every environment over HTTP and SSH, and carries the deployment work itself: licence generation, database cloning, host migration and patch builds.

Before this tool, checking the health, version, disk state and licence status of each deployment meant connecting to each host by hand. This centralises that work, keeps a record of every check run, and turns applying a patch into a repeatable procedure gated on a digest match rather than a manual file copy.

The App

Screens

Landing screen with a dark header, four status tiles counting sites up, warn, down and unknown, and a donut chart of 72 checks by status — The landing screen counts every managed site and check by current status.

Sites table listing six sites with type, VM operating system, environment count, application version badges, status and last checked time — The site list filters the estate by version, operating system and health status.

Estate overview with filter bar and four cards: check status by severity, site status, probes and firing alerts — The estate overview aggregates check and site status across every deployment, with a severity breakdown.

Failing checks table grouped by site with worst severity, number of checks failing and failure duration, beside a version spread bar chart and a coverage matrix — The failing view groups current failures by site and ranks them by severity and how long they have been failing.

Site page environments table showing production, staging and test rows with base URL, version, status, per check results and storage state — A site page lists its environments with the result of every check on each.

Site checks table with check name, type, status and last run time, each row offering run now, restart, terminal output, edit and delete, above a log reader panel — Checks can be run on demand from the site page, with the command output and service logs read back over SSH.

Environment page showing base URL, version, operating system, SSH host, user and port, database type, and a licence generator with customer limit and expiry fields — An environment page holds its connection details and the licence generator for that deployment.

Patching page with a new build form taking a git ref and artifact type, an empty build list, and a run section describing the digest check before anything is written to a target — The patching page builds one commit into one artifact and lays it over a target only after the preflight and staged digest both pass.

1. Scheduled checks

Every environment is checked on a schedule over HTTP and SSH: reachability, TLS certificate expiry, systemd service state, disk headroom, database size, queue workers, log queries and audit scans. Each run is stored with its terminal output.

2. Estate dashboard

Check results aggregate into a dashboard covering pass rate by severity, which checks are failing and for how long, the spread of application versions across deployments, VM operating system inventory, and a coverage matrix of which sites have logs, metrics and probes confirmed.

3. Deployment operations

Per-environment licence generation, database clone runs and host migration are handled from the same console as monitoring, rather than as separate manual procedures.

4. Patch builds

A patch build turns one commit into one artifact with a digest, then verifies that digest on the target before anything is written.

5. Reminders and notifications

Reminders support multi-step assignment, with email notification templates for the people they are assigned to.

6. Access control

Access is role-based, with per-user permission overrides where a role's default access needs an exception.