Running it

Running the API as a Windows service or a systemd unit, and what to set when it sits behind a reverse proxy.

01Running as a service

Windows. From an elevated prompt, prem setup --windows-service registers the API as the service Premagentic under its own virtual account, NT SERVICE\Premagentic, which can read the application's credentials file, HTTPS settings and certificate and nothing else. Its files default to C:\ProgramData\Premagentic. Start it with sc.exe start PremAgentic.

Linux. deploy/systemd/premagentic-api.service is a unit template: a system account, Type=notify, and the application's three files handed to the service by systemd, so they stay readable by root only. Run setup as root with --credentials-dir /etc/premagentic, then install and enable the unit.

Either way, the API refuses to start, with exit code 2 and a sentence saying what to set, when it has no database configured. Neither service path, nor the bundled database as a service, has yet been run on a clean machine with the rights it needs; see Known state.

02Behind a reverse proxy

Set PREM_TRUSTED_PROXIES to your proxies' addresses or ranges (10.0.0.5, 10.1.0.0/16). The API then believes their X-Forwarded-For and X-Forwarded-Proto, so sign-in over HTTPS that ends at the proxy works and the sign-in throttle counts each client. Nothing else is believed. Do not set ASPNETCORE_FORWARDEDHEADERS_ENABLED; the API refuses to start with it, because it believes anyone. The portal's origin check compares with the host the server sees, so a proxy that rewrites the host needs this setting too.