manent-server#
manent-server contains the API, the worker and the platform operations on the system database. Users and CI use the manent client instead, which talks only to the API.
| Global option | Description |
|---|---|
-c, --config |
manent configuration. It can also be given with MANENT_CONFIG. Without a file the defaults apply. |
Processes#
serve#
Starts the HTTP API and, in the same process, a worker. It is the simplest way for development and for single-node installations.
| Option | Description |
|---|---|
-l, --listen |
Listen address (overrides http.listen). |
api#
Starts only the API: it enqueues and queries deploys, but does not run them. With several nodes the API instances sit behind a load balancer and execution belongs to the workers (see Scalability).
worker#
Starts only the worker, without the API. On SIGINT or SIGTERM it stops picking up deploys and waits for those in progress up to dbos.drain_timeout (drain). Interrupted deploys are resumed when a worker with the same executor_id restarts or, with recovery, by another worker. Probes and metrics are on observability.listen.
Platform operations#
They work directly on the system database, so they need its credentials (dbos.database_url or DBOS_SYSTEM_DATABASE_URL). They are reserved to platform operators: whoever has access to the database can act on DBOS without going through manent's permissions. The identity recorded in the audit log is the operating system user (cli:<user>).
admin#
manent-server admin executors # registered workers and pending workflows
manent-server admin recover --executor <id> [--dry-run] [--force] # resumes the workflows of a lost worker
manent-server admin recover --from-version <v> [--to-version <v>] [--from-start] [--dry-run]
manent-server admin prune [--max-age 2160h] [--keep-releases 10] [--dry-run]
manent-server admin specs [--hash <sha256>…] [--all] # workflows and schedules with revoked custom step specifications
manent-server admin rename-artifact -a <application> --from <name> --to <name> [--dry-run] # renames an artifact in the history
admin executors reads the database; to see workers from a workstation, through the API and with manent's permissions, use manent workers (platform.read). Recovery, retention and renames are recorded in the audit log (admin.recover, admin.prune, admin.rename-artifact). admin rename-artifact is described in Applications with several artifacts. admin specs is described in Custom steps. See Recovery, shutdown and retention and Versions and upgrades.
In Kubernetes they run in a server pod, which already has configuration and credentials:
audit verify#
Verifies the hash chain of the audit file. Without arguments it uses audit.file from the configuration; with a single file it includes its rotated files. The HMAC key is read from audit.hmac_key_ref. It exits with an error at the first modified, inserted or missing entry.
validate#
Checks a manent configuration and a descriptor locally, without a database and without a running server: useful before installing a new configuration or in a pipeline that versions it.
It shows the plan, the rollback, the governance rule and, unless --offline, the effective deploy read from the environment configuration (for example from Consul) with the stages and passes of any wave rollout. To check a descriptor against the production server use manent validate.
version#
Exit codes#
The command exits with code 0 if the operation succeeds and with a non-zero code on error.