Skip to main content

Service Management

AudienceIT Administrators
CoversHub service operations, logs, backups
Reading Time5 minutes

The Hub installs as a Windows service named ExekraHubService. Day-to-day operation requires no manual intervention; the commands below are for upgrades, troubleshooting, and operator control.

Service commands

The Hub uses NSSM (the Non-Sucking Service Manager) to wrap the Node.js runtime as a Windows service.

ActionCommand
Check service statussc query ExekraHubService
Start the servicenssm start ExekraHubService
Stop the servicenssm stop ExekraHubService
Restart the servicenssm restart ExekraHubService
View service configurationnssm edit ExekraHubService

The same commands work for the bundled Redis service (ExekraHubRedis) when an installation uses the bundled Redis.

Log locations

| Source | Path | | --- | --- | | Hub application logs | <install-dir>\logs\hub-*.log | | Service stdout / stderr (from NSSM) | <install-dir>\logs\service-*.log | | Bundled Redis logs | <install-dir>\runtime\redis\redis.log | | Audit log (immutable, in database) | PostgreSQL audit_log table |

<install-dir> defaults to C:\Program Files\Exekra\Hub.

Application logs rotate automatically. For long-term audit retention use the PostgreSQL audit log, which is append-only and the authoritative record.

Initial setup tasks

After the Hub installation completes:

  1. Activate the license on the activation page (see License management).
  2. Create the initial admin account on the bootstrap page. The admin email must match the license.
  3. Sign in and access the dashboard.

Managing users

Administrators create users with email, password, name, and role (ADMIN, DEVELOPER, or OPERATOR). The default role is OPERATOR (least privilege). Only administrators can create users and assign roles. See Security model for what each role can do.

Managing Runners

Register Runners from the Runners page. Monitor status, metrics, and connectivity. Rotate credentials with Regenerate Secret if a Runner's Machine Secret is suspected to be compromised. Regenerating a secret immediately invalidates the previous one.

Backup strategy

| Surface | Recommended cadence | Method | | --- | --- | --- | | PostgreSQL database | Daily, plus WAL archiving if available | pg_dump or your standard database backup tooling | | Hub configuration | After every config change | Back up <install-dir>\config\hub-config.json, <install-dir>\.env, and the TLS certificates under <install-dir>\config\certs | | TLS certificates | At issuance and renewal | Same as configuration | | Redis | Not required | Redis holds transient queue state only |

Disaster recovery

  1. Install the Hub on a new machine using the same connection string to the database backup.
  2. Restore the PostgreSQL database from your latest backup.
  3. Restore the Hub configuration directory.
  4. Start the Hub service. Runners will reconnect automatically using their existing credentials.

Common operations

  • Restart after configuration change: stop the service, edit hub-config.json, start the service.
  • Rotate TLS certificate: stop the service, replace the certificate files in <install-dir>\config\certs, start the service.
  • Free disk space: prune old log files in <install-dir>\logs (audit log is in the database, not here).
  • Quick health check: https://<hub-host>:<port>/api/health returns Hub uptime and database status.

Was this page helpful?

A quick signal helps us prioritise improvements.