Service Management
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.
| Action | Command |
|---|---|
| Check service status | sc query ExekraHubService |
| Start the service | nssm start ExekraHubService |
| Stop the service | nssm stop ExekraHubService |
| Restart the service | nssm restart ExekraHubService |
| View service configuration | nssm 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:
- Activate the license on the activation page (see License management).
- Create the initial admin account on the bootstrap page. The admin email must match the license.
- 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
- Install the Hub on a new machine using the same connection string to the database backup.
- Restore the PostgreSQL database from your latest backup.
- Restore the Hub configuration directory.
- 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/healthreturns Hub uptime and database status.
Was this page helpful?
A quick signal helps us prioritise improvements.