CLI#

manent has two binaries:

Binary	For whom	What it does
`manent`	Developers, release managers, CI pipelines	Client: reads YAML descriptors and talks only to the server API. It contains no engine, plugins or database drivers.
`manent-server`	Platform	API, workers and database operations. See manent-server.

This page describes the client.

manent [-c <client.yml>] [--server <url>] [--token-file <file>] [--ca-file <pem>] <command> [options]

Output#

On a terminal the client prints for people: deploy, promote and rollback show every step as it ends, one line per wave with its health gate and a summary; list, inventory and status print tables; logs shows the time, colored levels and only the attributes that say something about the line. When the output goes to a pipe or a file (scripts, CI) or with --json, they print the API's JSON, as before. Colors are disabled by NO_COLOR.

$ manent deploy -f shop.yml
deploy enqueued: 8c1f…
  ✓ deploy@canary#0                  1.1s
  ◷ wave canary                      1 host released, health gate running
  ✗ wave canary                      health gate red
  ✓ rollback:deploy@canary#0         0.1s
  ↺ wave canary                      rolled back
✗ shop 1.4.0 → prod deploy failed after 2.9s
  automatic rollback: completed

Client configuration#

Every command goes through the API: the server's authentication, permissions and audit always apply.

~/.config/manent/client.yml

server: https://manent.example.com
token_file: ~/.config/manent/token    # OIDC or static token
ca_file: /etc/ssl/certs/corporate-ca.pem   # only if the server's CA is not among the system ones
timeout: 60s                          # per request

Setting	Option	Variable	File	Default
Configuration file	`-c`, `--config`	`MANENT_CLIENT_CONFIG`		`$XDG_CONFIG_HOME/manent/client.yml` or `~/.config/manent/client.yml`, if it exists
Server	`--server`	`MANENT_SERVER`	`server`	`http://127.0.0.1:8080` (local `manent-server serve`)
Token		`MANENT_TOKEN`
Token file	`--token-file`	`MANENT_TOKEN_FILE`	`token_file`
Server CA	`--ca-file`	`MANENT_CA_FILE`	`ca_file`	system CAs

The option wins over the variable, which wins over the file. For the token: --token-file (or MANENT_TOKEN_FILE), then MANENT_TOKEN, then the file's token_file. The token is never passed as an option, because it would stay in the shell history.

export MANENT_SERVER=https://manent.example.com
export MANENT_TOKEN=…
manent deploy -f release.yml

In a CI pipeline you can use the ghcr.io/manent-deployer/manent image, which contains only the client.

Deploy#

`deploy`#

Enqueues a deploy from a YAML descriptor and, by default, waits for it to finish.

manent deploy -f examples/descriptor.yml [--no-wait] [--timeout 30m] [--dry-run]

Option	Description
`-f`, `--file`	YAML descriptor (required).
`--no-wait`	Prints the ID and exits immediately, without waiting.
`--timeout`	Maximum wait (e.g. `30m`). When it expires the command exits, but the deploy continues.
`--dry-run`	Runs the deploy as a simulation.
`--after <id>`	Starts the deploy only after the deploy `<id>` has succeeded (repeatable): see Deploy chains.
`--import <name>=<id>`	Reads the exports of the deploy `<id>` as the import `<name>` of the descriptor and adds `<id>` to `after` (repeatable): see Exports and imports.
`--id`, `--version`, `--source`, `--sha256`	Replace the ID and the artifact fields of the descriptor (the pipeline gives the version).
`--tenant <tenant>` (`-t`)	Sets `tenant`: chooses among the tenants that list the application. Also on `rollback`, `promote`, `env validate` and `policy access`.
`--config-ref <ref>`	Sets `config.ref`: the revision of the environment configuration (git provider), within `descriptor_policy.config_ref`.
`--outputs <file>`, `--summary <file>`, `--ci`	`key=value` outcome and Markdown summary for CI: see CI and infrastructure as code.

Scheduled deploys (schedule in the descriptor) and those awaiting approval are not waited for: the command prints the state and exits.

`validate`#

Checks the descriptor on the server with the same checks as enqueuing (descriptor policy, environment configuration, callbacks, artifact source, rollback) and shows the plan and the effective deploy, i.e. the descriptor merged with the environment configuration. It enqueues nothing and does not contact secrets or targets, nor the artifact source unless --check-artifact is given. Requires the deployment.read permission.

manent validate -f examples/descriptor.yml
manent validate -f examples/descriptor.yml --check-artifact

The output also lists the names of the declared secrets, the governance rule that applies and any active freeze. If the environment configuration cannot be reached, the server reports it in warnings and the check is left to the worker. To check a manent configuration before installing it there is manent-server validate.

With --check-artifact the API server also looks for the artifact at its source, with the credentials of artifacts.sources and without downloading it: HEAD for an http(s) URL, the manifest for an oci:// image, the file for a local path. A missing artifact, denied access or an unreachable source make the validation fail; the result is in the artifact field. For an image the manifest digest is compared with artifact.sha256 (sha256_verified); for files and URLs that would require the download, which stays with the artifacts step (or deploy --dry-run). The request comes from the API server, not from a worker: where only the workers reach the repository, use the dry-run. It also requires the deployment.dry-run permission.

`env validate`#

Checks a candidate environment configuration before it reaches the configuration system, merging it with an example descriptor (default: the request of the deploy in service). See CI and infrastructure as code.

manent env validate -a <application> -e <environment> -f prod.yml [-d descriptor.yml]

`status`#

manent status <id>

Prints state, dates and, for finished deploys, the result of each step or the error.

`list`#

manent list [-s <schedule>] [-a <application>] [-e <environment>] [--state SUCCESS] [-n 20]

Lists deploys from the most recent, including those awaiting approval or rejected. With --schedule it shows only the runs of a recurring schedule. Filters (and permissions) do not reduce the number of results: the list keeps going through older deploys up to -n.

`cancel`#

manent cancel <id>

A queued, scheduled or awaiting-approval deploy is removed. A running deploy stops at the start of the next step: the step in progress still completes.

Governance#

See Release governance.

manent inventory [-a <application>] [-e <environment>] [--out-of-sync]
manent promote -a <application> --from <environment> --to <environment> [--version <v>] [--deploy-file <yaml>] [--config-ref <ref>]
manent rollback -a <application> -e <environment> [--to <version>]
manent approve <id> [-m <comment>]
manent reject <id> -m <reason>
manent freezes [-a <application>] [-e <environment>]
manent approvals                # deploys waiting for a decision that you can take
manent whoami                   # your identity on the server and your roles

promote and rollback also accept --id, --dry-run, --freeze-override <reason>, --no-wait and --timeout, with the same meaning as for deploy.

Artifacts#

See Applications with several artifacts.

manent list|inventory|dora -A <artifact>
manent promote -a <application> --from <env> --to <env> -A <artifact>
manent rollback -a <application> -e <env> -A <artifact>      # required with more than one artifact in the environment
manent env validate -a <application> -e <env> -A <artifact> -f <yaml>
manent freeze add --name <name> -e <env> -A <artifact pattern> --for 4h
manent-server -c manent.yml admin rename-artifact -a <application> --from <name> --to <name> [--dry-run]

Tenants#

See Tenants.

manent tenants list [-a <application>] [--selector <tenant selector>]
manent tenants show <tenant>                             # applications with their tags, queue
manent list|inventory|activity|dora -t <tenant>          # dora --by-tenant: metrics per tenant
manent list|inventory --selector <application selector>  # e.g. criticality=high, tenant=payments
manent freeze add ... --selector <application selector>

Freezes and policies#

See Policies in Rego.

manent freeze add --name <name> -e <environment> [-a <application>] [--region <r>] (--for <duration> | --until <RFC 3339>) [--from <RFC 3339>] [--reason <text>] [--hard]
manent freeze delete <name>
manent freeze list

manent policy list
manent policy show <revision|current>
manent policy pull <revision|current> -d <dir>
manent policy push -d <dir> [-m <comment>]
manent policy diff <revision> <revision>
manent policy eval <revision|current> -f <yaml> [--phase submit|validate|start|stage|tick] [--kind deploy|promotion|rollback]
manent policy impact <revision> [--since 7d]
manent policy access <revision|current> --subject <method:name> [--group <g>]... [--claim k=v]... [--compare]
                     [--action <action> -a <app> -e <env> [-A <artifact>] [-f <yaml>]] [--json]   # rbac.engine: opa
manent policy approve <revision>         # activates a draft
manent policy activate <revision>        # back to a revision already active in the past

Logs, timeline and metrics#

manent logs [-f] [--json] [--level warn] <id>   # deploy log; -f follows it until completion, --level hides the lower levels
manent steps <id>                      # recorded steps with times, duration, outputs and errors
manent dora [--since 30d] [-a <application>] [-e <environment>]

See Observability.

Composite releases#

manent release submit -f release.yml [--no-wait] [--timeout 2h]   # submits and follows the release
manent release status <id>
manent release list [-n 20]
manent release cancel <id>

submit prints a line for every change of state of a deploy (and of its rollback) and exits with an error if the release does not succeed. See Deploy chains.

Activity and workers#

manent activity [-a <application>] [-e <environment>] [-w 5s] [--json]   # active deploys
manent workers [-w 5s] [--json]                                           # workers, resources, queues and their work
manent queues [-w 5s] [--json]                                            # queues, limits and listening workers

activity shows the deploys that have not finished yet, grouped as running (with the worker that runs them, the last recorded step and the wave progress), awaiting approval, waiting for dependencies (with the deploys still awaited), queued (waiting for a free slot of the environment) and scheduled (schedule.at). Only deploys you can read are listed.

workers lists the registered workers with state (alive, stale when the heartbeat is missing, stopped, unregistered for an executor that has pending workflows but is not in the registry), region, workflow and binary versions, last heartbeat and the workflows running on each: deploys, wave steps in a region, health gates, approvals waiting for a decision. It requires the platform.read permission; workflows of applications you cannot read are only counted. A second table shows the resources each worker reports at every heartbeat (CPU used against the CPUs it may use, process memory against the container limit or the host memory, host load, free space of the workdir, deploys it runs together) and the queues it listens to.

queues lists the queues: the deploy queue, partitioned by application and environment, the queue of approvals and waits, which takes no deploy slot, and one queue per region with region routing. For each: workflows waiting for a slot, running and scheduled, the oldest wait, the concurrency limits and the live workers that listen to it. A queue with work and no listening worker (for example a region whose workers are all down) is the first thing to check when deploys do not start. It requires platform.read.

All three print a table; --json prints the API response, -w repeats the list at the given interval until Ctrl-C.

Schedules#

manent schedule list
manent schedule show <name>
manent schedule pause <name>
manent schedule resume <name>
manent schedule delete <name>

Schedules are created with a descriptor containing schedule.cron. See Scheduled deploys.

Version#

manent version     # client version, commit and build date

Exit codes#

The command exits with code 0 if the operation succeeds and with a non-zero code on error, including a deploy that ended with an error when deploy waits for its outcome.