Command-line reference

Every command kirto-gate accepts is here, with the flags each one takes. The page is generated from the commands themselves. The descriptions are the text -h prints and the tables are the flags as declared, so a renamed flag or a reworded explanation changes this page in the same commit or not at all.

One binary does all of it. The subcommands are here rather than in a second tool because the image ships distroless. There is no shell to curl from and nowhere to install anything beside it, so kubectl exec into a running pod reaches the admin API, the backup verbs and the offline recovery path with the binary that is already there.

Commands that call a running gateway take a door: -socket for the local Unix socket, which is authenticated by the caller’s peer credentials, or -url with the token kirto-gate login cached. Neither is guessed at when both are given. See Sign in from the command line for the sign-in flow and Reach the admin API without your identity provider for the socket.

Contents

• kirto-gate check
• kirto-gate controls
• kirto-gate admin
• kirto-gate config
  • kirto-gate config apply
  • kirto-gate config check
  • kirto-gate config diff
  • kirto-gate config rollback
• kirto-gate query
• kirto-gate login
• kirto-gate logout
• kirto-gate cluster
  • kirto-gate cluster recover
  • kirto-gate cluster prune
• kirto-gate audit
  • kirto-gate audit verify
• kirto-gate snapshot
  • kirto-gate snapshot save
  • kirto-gate snapshot restore
• kirto-gate artifacts
  • kirto-gate artifacts pin
• kirto-gate guardrails
  • kirto-gate guardrails eval
• kirto-gate pack
  • kirto-gate pack list
  • kirto-gate pack show
  • kirto-gate pack add
• kirto-gate version

kirto-gate

Command Gate runs the gateway. Two modes:

• flag mode: -upstream/-dialect/-alias describe a single provider, no virtual keys, the original passthrough spine;
• config mode: -config points at a YAML file with providers, model routing, virtual keys, CEL access rules and the admin listener.

The file is read at start and nowhere else. An edit to it is a restart, which applies both halves together.

flag	value	default
-config	string	—	configuration file path; its deployment carries or names the deployment document. When set, the flags below are ignored
-listen	string	:8484	address to serve on
-metrics-listen	string	:9464	address to serve /metrics on; none serves no metrics
-upstream	string	https://api.openai.com	provider base URL
-dialect	string	openai	upstream API dialect: openai or anthropic
-max-body	integer	32 << 20	max request body bytes
-openapi	boolean	—	print the control-plane OpenAPI 3.1 spec and exit
-config-schema	boolean	—	print the JSON Schema for a configuration source document and exit
-node-schema	boolean	—	print the JSON Schema for the configuration file, deployment included, and exit
-policy-schema	string	—	print the admin policy vocabulary as a Cedar schema in this format, cedar or json, and exit
-test-rules	string	—	run the rule suite at this path against -config and exit; non-zero when a case fails
-deployment	string	—	with -test-rules: the deployment document to test, for a clustered node whose file names none
-alias	string	—	model alias as client=upstream (repeatable)

kirto-gate check

Run this command:

kirto-gate check -config PATH [-deployment PATH] [-timeout 5s] [-offline]

Loads the configuration the way the gateway would, with the same parse, the same variable and secret expansion, every model resolved, every recognizer’s examples run and every rule compiled. It reads the rules back against the deployment they run in, and reports one naming something no request can carry or one an earlier rule has already decided. It then asks each thing it names to answer: a cheap request at every provider with its credential, discovery and the key set at every issuer, a request at every fronted MCP server, the card of every fronted agent, and the native libraries the guardrails would load. One line per answer, and a non-zero exit when any is a failure.

It starts nothing and writes nothing: no listener, no raft log, no key. A check that passes says the file is sound and its dependencies answer from this machine; the gateway may still find a port taken.

The node half is read as written. What the file leaves out is reported as what the gateway will do about it, whether that is no admin door, no public_url or plain HTTP, rather than refused, since each of those is a deployment somebody may mean.

Run this command:

kirto-gate check -config kirto-gate.yaml
kirto-gate check -config kirto-gate.yaml -offline     # in a pipeline, with placeholder variables

flag	value	default
-config	string	—	node file path (required)
-deployment	string	—	deployment document to check as this node’s, for a clustered node, whose file names none
-timeout	duration	—	how long each network probe may take
-offline	boolean	—	compile only: touch no provider, issuer, server, agent or library

kirto-gate controls

Run this command:

kirto-gate controls -config PATH [-deployment PATH] [-json]

Every governance control the document cites, with the rules that name it, where they run, what they apply to, and what they still turn on. This is controls read the other way round: everywhere else it hangs off a rule, and here the control is the row.

What a rule applies to is answered on the paths the document holds: the route labels, the declared providers, the profiles, the fronted servers and agents. A rule that turns on a key’s metadata or on what a client sent has that named as open rather than guessed at, so no line here claims a control is enforced.

Two things are exact. A control cited only by rules that never run is a claim with nothing behind it, and exits non-zero. A control a control pack declares that no rule cites is reported for every pack this document draws on, and does not.

It reads the document and nothing else: no listener, no raft log, no provider contacted. A ${secret:NAME} the cluster holds has a value stood in for it, as in kirto-gate check.

Run this command:

kirto-gate controls -config kirto-gate.yaml
kirto-gate controls -config kirto-gate.yaml -json > controls.json

flag	value	default
-config	string	—	node file path (required)
-deployment	string	—	deployment document to read as this node’s, for a clustered node whose file names none
-json	boolean	—	write the ledger as JSON instead of as a report

kirto-gate admin

Run this command:

kirto-gate admin [-socket PATH | -url URL] [-d BODY] [-H HEADER]... [METHOD] PATH

Calls the admin API. METHOD defaults to GET. A body is sent as JSON unless a -H Content-Type says otherwise; the writes that take a precondition take it as a header too.

Use the following example:

-socket  the local Unix socket, which needs no token: the caller is
         named by its peer credentials and decided over by
         admin.policy_file like any other caller.
-url     over the network, presenting the token `kirto-gate login`
         cached. Renewed automatically while a refresh token lasts.

Run this command:

kirto-gate admin /admin/v1/config
kirto-gate admin -url https://gw.example /admin/v1/suspensions
kirto-gate admin PUT /admin/v1/suspensions/provider:openai \
    -d '{"reason":"INC-4471","duration":"4h"}'
kirto-gate admin DELETE /admin/v1/suspensions/provider:openai
kirto-gate admin -H 'If-None-Match: *' -H 'Content-Type: application/yaml' \
    PUT /admin/v1/config/sources/policy -d @- < policy.yaml

Exits non-zero when the API answers 400 or above.

flag	value	default
-socket	string	—	admin.local_socket path (default $KIRTO_GATE_ADMIN_SOCKET)
-url	string	—	gateway URL, using the token from kirto-gate login, or the one in $KIRTO_GATE_ADMIN_TOKEN_FILE where that is set (default $KIRTO_GATE_ADMIN_URL)
-d	string	—	request body; @- reads stdin
-H	string	—	a request header, Name: value; repeatable

kirto-gate config

Run this command:

kirto-gate config <apply|check|diff|rollback> [flags]

Use the following example:

apply     write a deployment document to the cluster as one source
check     ask the cluster whether a document would build, as a reader
diff      show what a document or a revision changes against a source
rollback  write a retained revision of a source back as the current one

kirto-gate config apply

Run this command:

kirto-gate config apply [-socket PATH | -url URL] [-source NAME] [-wait DURATION] [-dry-run] [-force] FILE

Writes the deployment document in FILE (- for stdin) to the cluster as the source NAME, whole: created when the source does not exist, replaced at the revision read otherwise, and left alone when the stored document is already these bytes. The document is parsed here before anything is sent, and the cluster builds it before anything is written, so a document that would not serve is refused with nothing changed.

A source has one manager: the identity this command runs as, which the cluster records on every write. Where somebody else wrote the source last, an edit through the console or the API, the write is refused and the objects they changed since this manager’s last write are named. -force writes over them. -dry-run runs every check the write would, on the cluster, and writes nothing.

Run this command:

kirto-gate config apply -socket /run/kirto-gate/admin.sock -source platform deployment.yaml
kirto-gate config apply -url https://gw.example -source platform - < deployment.yaml
kirto-gate config apply -url http://kirto-gate-admin:8485 -source kirto-gate -wait 5m /etc/kirto-gate/deployment.yaml

flag	value	default
-socket	string	—	admin.local_socket path (default $KIRTO_GATE_ADMIN_SOCKET)
-url	string	—	gateway URL, using the token from kirto-gate login, or the one in $KIRTO_GATE_ADMIN_TOKEN_FILE where that is set (default $KIRTO_GATE_ADMIN_URL)
-source	string	api	the source the document is written as; created on the first write
-wait	duration	0	keep trying for this long while the admin API is not answering or has no leader
-dry-run	boolean	—	decide and validate the write on the cluster, and write nothing
-force	boolean	—	write over objects somebody else changed since this manager last wrote the source

kirto-gate config check

Run this command:

kirto-gate config check [-socket PATH | -url URL] [-source NAME] FILE

Asks the cluster whether the deployment document in FILE (- for stdin) would build in place of the source NAME, and writes nothing. The cluster runs the parse, the composition with every other source and the build that apply’s write runs.

The check is decided as a read on the source, so it needs no grant to write. That suits an agent or a CI job that proposes a document for somebody else to apply. It does not ask the per-object write decisions, which is the difference from apply -dry-run: a document that checks can still be refused to a writer who may not touch what it changes.

The answer names the revision the document was checked against. A source written since then refuses the apply rather than landing a document nobody checked.

Run this command:

kirto-gate config check -url https://gw.example -source team-a team-a.yaml
kirto-gate config check -socket /run/kirto-gate/admin.sock -source platform - < deployment.yaml

flag	value	default
-socket	string	—	admin.local_socket path (default $KIRTO_GATE_ADMIN_SOCKET)
-url	string	—	gateway URL, using the token from kirto-gate login, or the one in $KIRTO_GATE_ADMIN_TOKEN_FILE where that is set (default $KIRTO_GATE_ADMIN_URL)
-source	string	api	the source the document would replace

kirto-gate config diff

Run this command:

kirto-gate config diff [-socket PATH | -url URL] [-source NAME] [-from REV] [-to REV] [FILE]

Shows what changed in a source: between two of its retained revisions, or between what is stored and the document in FILE (- for stdin), which is what apply would write. Each object added, removed or changed is listed first, then the documents’ unified diff. A source that does not exist yet compares as empty, so every object in FILE is listed as added.

Run this command:

kirto-gate config diff -socket /run/kirto-gate/admin.sock -source platform deployment.yaml
kirto-gate config diff -url https://gw.example -source platform -from 41

flag	value	default
-socket	string	—	admin.local_socket path (default $KIRTO_GATE_ADMIN_SOCKET)
-url	string	—	gateway URL, using the token from kirto-gate login, or the one in $KIRTO_GATE_ADMIN_TOKEN_FILE where that is set (default $KIRTO_GATE_ADMIN_URL)
-source	string	api	the source to compare

kirto-gate config rollback

Run this command:

kirto-gate config rollback [-socket PATH | -url URL] [-source NAME] -to REV [-dry-run]

Reads the source’s document as it was at revision REV and writes it back as an ordinary write at the current revision: validated, audited, and a new revision, so the history says the deployment went there and back. A source that was since deleted is created again. The retained revisions are the last ten of each source; listConfigSourceRevisions on the admin API says which are held.

Run this command:

kirto-gate config rollback -socket /run/kirto-gate/admin.sock -source platform -to 41

flag	value	default
-socket	string	—	admin.local_socket path (default $KIRTO_GATE_ADMIN_SOCKET)
-url	string	—	gateway URL, using the token from kirto-gate login, or the one in $KIRTO_GATE_ADMIN_TOKEN_FILE where that is set (default $KIRTO_GATE_ADMIN_URL)
-source	string	api	the source to roll back
-dry-run	boolean	—	decide and validate the write on the cluster, and write nothing

kirto-gate query

Run this command:

kirto-gate query [-socket PATH | -url URL] [-o table|json] [-p VALUE]... SQL
kirto-gate query [-socket PATH | -url URL] [-o table|json] -tables

Runs one SQL statement over the admin API’s list views: keys, profiles, budgets, backends, models, mcp_servers, a2a_agents, suspensions, secrets, sources, cluster_members, audit_heads, reconcile and reconcile_verdicts. Each table is the matching list endpoint’s response, row for row, and exists for a caller who may call that endpoint; the statement joins and sums them in one read of one node. SQL may be - to read the statement from stdin.

Nested values are JSON text; read into them with ->>. NULL prints as an empty cell in a table; -o json keeps the distinction.

Run this command:

kirto-gate query -socket /run/kirto-gate/admin.sock -tables
kirto-gate query -url https://gw.example \
  'SELECT k.name, p.budget, b.status FROM keys k JOIN profiles p ON p.name = k.profile JOIN budgets b ON b.budget = p.budget'
kirto-gate query -url https://gw.example -p openai \
  'SELECT day, class, metered, reported, ratio FROM reconcile_verdicts WHERE provider = ? AND breach = 1'

flag	value	default
-socket	string	—	admin.local_socket path (default $KIRTO_GATE_ADMIN_SOCKET)
-url	string	—	gateway URL, using the token from kirto-gate login, or the one in $KIRTO_GATE_ADMIN_TOKEN_FILE where that is set (default $KIRTO_GATE_ADMIN_URL)
-o	string	table	output: table or json
-tables	boolean	—	describe the tables this caller may query instead of running a statement
-p	string	—	a value for the next ? in the statement (repeatable)

kirto-gate login

Run this command:

kirto-gate login [-issuer NAME] [-device] [URL]

Signs in at the gateway’s identity provider and caches the token, so kirto-gate admin -url URL can call the API afterwards. URL defaults to $KIRTO_GATE_ADMIN_URL.

The flow is PKCE with a loopback redirect where there is a browser to open, and the device grant where there is not, over SSH for example, which is where somebody otherwise reaches for a long-lived token.

Run this command:

kirto-gate login https://gw.example
kirto-gate login -device https://gw.example

flag	value	default
-issuer	string	—	which issuer to sign in at, when the gateway trusts more than one
-device	boolean	—	use the device flow even where a browser could be opened

kirto-gate logout

Run this command:

kirto-gate logout [-all] [-list] [URL]

Forgets this machine’s cached token for a gateway. The token stays valid at the identity provider until it expires; revoking it there is a separate act.

flag	value	default
-all	boolean	—	forget every cached sign-in
-list	boolean	—	print the cached sign-ins and change nothing

kirto-gate cluster

Run this command:

kirto-gate cluster recover [flags]
kirto-gate cluster prune [flags]

recover is an offline operation on this node’s raft data directory; run it with the gateway stopped. prune declares a running cluster’s membership over its forward listener, with the cluster secret.

kirto-gate cluster recover

Run this command:

kirto-gate cluster recover [-config FILE | -data-dir DIR -node-id ID] [-keep IDS] [-confirm]

Recovers a cluster that has lost quorum for good: rewrites this node’s raft state to believe in a smaller membership, so the survivors can elect a leader again. Keys, budget ledgers, certificates, suspensions and config sources on this disk are kept.

Run it on a STOPPED node. Run it once, on the survivor with the highest last index, and bring the rest back with a blank data directory and cluster.join. It can only drop members, never add one.

Without -confirm it prints what it found and exits, writing nothing.

Run this command:

kirto-gate cluster recover -config /etc/kirto-gate/config.yaml
kirto-gate cluster recover -config /etc/kirto-gate/config.yaml -confirm
kirto-gate cluster recover -data-dir /var/lib/kirto-gate/raft -node-id gw-a \
    -keep gw-a,gw-b -confirm

flag	value	default
-config	string	—	node file to read cluster.node_id and cluster.data_dir from
-data-dir	string	—	raft data directory (overrides -config)
-node-id	string	—	this node’s cluster.node_id (overrides -config)
-keep	string	—	comma-separated node ids to keep (default: this node alone)
-confirm	boolean	—	write the recovered configuration; without it, nothing is written

kirto-gate cluster prune

Run this command:

kirto-gate cluster prune -addr HOST:PORT[,...] -keep IDS [-attempts N]

Tells a running cluster that its members are exactly -keep, and removes every other one. The request goes to the first address that answers; a follower relays it to the leader, which hands leadership over first if it is among the removed. Keeping every current member is a no-op.

The cluster secret is read from KIRTO_GATE_CLUSTER_SECRET. It authenticates the request and derives the certificate the forward listener requires.

Use the following example:

KIRTO_GATE_CLUSTER_SECRET=... kirto-gate cluster prune \
    -addr kirto-gate-0.kirto-gate-headless:7001,kirto-gate-1.kirto-gate-headless:7001 \
    -keep kirto-gate-0,kirto-gate-1 -attempts 30

flag	value	default
-addr	string	—	comma-separated forward addresses of members to try, in order
-keep	string	—	comma-separated node ids that remain; every other member is removed
-attempts	integer	1	passes over the addresses, five seconds apart, before giving up

kirto-gate audit

Run this command:

kirto-gate audit verify [flags] FILE...

Offline checks on an exported audit trail.

kirto-gate audit verify

Run this command:

kirto-gate audit verify [-heads FILE] [-key KID=BASE64]... FILE...

Reads an exported audit trail, either the gateway’s stderr or a collector’s dump of the kirto-gate/audit scope written back as lines, and checks every chain in it: each record hashes to its entry, each entry links to the one before it, each is signed by the key the chain started with, and no sequence number between the first and last seen is missing. Other lines on the stream are ignored. FILE may be - for stdin.

What it cannot see is a trail cut at the end. Give it -heads with what the cluster or an operator witnessed and it will report a trail that stops short of a witnessed head.

Exit status is 0 when every chain verified, 1 otherwise.

Run this command:

kirto-gate audit verify gateway.log
kubectl logs kirto-gate-0 | kirto-gate audit verify -
kirto-gate audit verify -heads heads.json -key 3f2a9c1b8d7e6f50=BASE64 export.jsonl

flag	value	default
-heads	string	—	JSON file of witnessed chain heads ([{node,kid,seq,hash}]) the trail must reach
-key	string	—	public key for a chain whose start record is not in the input, as KID=BASE64 (repeatable)
-q	boolean	—	print findings only

kirto-gate snapshot

Run this command:

kirto-gate snapshot save [-socket PATH | -url URL] [-stale] FILE
kirto-gate snapshot restore [-socket PATH | -url URL] FILE

Back up the cluster’s replicated state to an archive, or restore it.

kirto-gate snapshot save

Run this command:

kirto-gate snapshot save [-socket PATH | -url URL] [-stale] FILE

Forces a raft snapshot on the node and writes it to FILE (- for stdout) as a gzipped tar of meta.json, state.bin and SHA256SUMS: every key, budget, configuration source with its history, sealed secret, keyring, certificate and witnessed audit head. Only the leader answers unless -stale is given; a follower’s state may trail by a commit round.

Secrets stay sealed in the archive. Only a cluster holding the same cluster secret can open them again.

Run this command:

kirto-gate snapshot save -socket /run/kirto-gate/admin.sock backup.snap
kirto-gate snapshot save -url https://gw.example - | aws s3 cp - s3://backups/kirto-gate.snap

flag	value	default
-socket	string	—	admin.local_socket path (default $KIRTO_GATE_ADMIN_SOCKET)
-url	string	—	gateway URL, using the token from kirto-gate login, or the one in $KIRTO_GATE_ADMIN_TOKEN_FILE where that is set (default $KIRTO_GATE_ADMIN_URL)
-stale	boolean	—	take the snapshot from this node even if it is not the leader

kirto-gate snapshot restore

Run this command:

kirto-gate snapshot restore [-socket PATH | -url URL] FILE

Replaces the cluster’s replicated state with the archive in FILE (- for stdin). Membership is kept: the archive restores into whichever cluster receives it, which is how a wiped or replaced cluster gets its state back. Any node accepts it and forwards to the leader. Every node rebuilds from the restored state at once, and the previous state is gone. Take a snapshot first if there is any chance you want it back.

Run this command:

kirto-gate snapshot save -socket /run/kirto-gate/admin.sock before-restore.snap
kirto-gate snapshot restore -socket /run/kirto-gate/admin.sock backup.snap

flag	value	default
-socket	string	—	admin.local_socket path (default $KIRTO_GATE_ADMIN_SOCKET)
-url	string	—	gateway URL, using the token from kirto-gate login, or the one in $KIRTO_GATE_ADMIN_TOKEN_FILE where that is set (default $KIRTO_GATE_ADMIN_URL)

kirto-gate artifacts

Run this command:

kirto-gate artifacts pin [-revision REV] [-model PATH] [-endpoint URL] [-token TOKEN] OWNER/NAME

Resolve a HuggingFace repository to a commit and print the model_artifacts entry to paste.

kirto-gate artifacts pin

Run this command:

kirto-gate artifacts pin [-revision REV] [-model PATH] [-endpoint URL] [-token TOKEN] OWNER/NAME

Resolves the revision to its commit and prints the model_artifacts entry a configuration takes. A gateway accepts a commit and nothing else, so that the artifact behind a detector cannot change under a configuration that did not; this is where a branch becomes one.

Run this command:

kirto-gate artifacts pin Xenova/bert-base-multilingual-cased-ner-hrl
kirto-gate artifacts pin -model onnx/model_quantized.onnx Xenova/bert-base-multilingual-cased-ner-hrl

flag	value	default
-revision	string	main	branch, tag or commit to resolve
-model	string	—	path of the ONNX graph within the repository
-endpoint	string	—	the Hub, or a mirror of it
-token	string	—	bearer token for a gated repository (default $HF_TOKEN)
-name	string	—	the name detectors will reference (default: the repository name)

kirto-gate guardrails

Run this command:

kirto-gate guardrails eval -config FILE [flags] DATA...

Score the config’s guardrail ensemble against labelled text.

kirto-gate guardrails eval

Run this command:

kirto-gate guardrails eval -config FILE [flags] DATA...

Compiles the config’s guardrails exactly as the gateway does, with models fetched and verified, native libraries loaded and thresholds applied, and runs every case of each DATA file through the ensemble as one chat turn, scoring what it found against what the file marks.

A .jsonl file holds one case per line:

Use the following example:

{"text": "...", "spans": [{"start": 0, "end": 12, "type": "PERSON"}], "tags": ["clitic"]}
{"text": "...", "labels": ["INJECTION"]}      an empty list is a clean text
{"text": "...", "kind": "tool_result", "system": "You are ...", "labels": ["INJECTION"]}

Any other file is read as CoNLL: a token and its tag per line, blank lines between sentences. Offsets are bytes into the text. A case’s kind is the segment it is presented as (default -kind); its system is the instruction sent as the system turn before it, and findings on that turn are not the case’s.

Spans are scored exactly and with overlap allowed (the ~ columns); labels as sets. A tag on a case repeats the totals for that slice.

Run this command:

kirto-gate guardrails eval -config eval/ner.yaml -types PERSON data/anercorp-test.conll
kirto-gate guardrails eval -config eval/injection.yaml -sweep data/deepset-test.jsonl

flag	value	default
-config	string	—	deployment document whose guardrails are measured, or a node file naming one (required)
-detector	string	—	score one detector’s findings, by name (default: every detector’s)
-kind	string	user	present a case that names no kind as this segment kind: user, system, assistant, tool_result or output
-types	string	—	comma-separated entity types or labels to score (default: the ones the data carries)
-sweep	boolean	—	recompile with thresholds lowered and report the average precision plus precision, recall and F1 at every 0.05 and at the quantiles of the scores seen
-errors	integer	10	how many wrong cases to print
-parallel	integer	1	cases inspected at once
-limit	integer	0	score only the first N cases of each file
-json	boolean	—	print the report as JSON
-invariance	boolean	—	read the cases as one meaning per row in several languages, ids --, and report how the verdict changes with the language
-reference	string	en	with -invariance: the language the others are read against
-verdicts	boolean	—	with -json: every case’s gold and findings, the whole matrix rather than the -errors sample
-rename	string	—	rename a type in the data, as FROM=TO (repeatable; default PER/PERS=PERSON, LOC/GPE=LOCATION, ORG=ORGANIZATION, MIS=MISC)

kirto-gate pack

Run this command:

kirto-gate pack list
kirto-gate pack show PACK
kirto-gate pack add [-deployment FILE] [-write] PACK...
kirto-gate pack add -source NAME [-socket PATH | -url URL] PACK...

List the control packs this binary ships, read one, or copy one or more into a deployment document or a stored configuration source. PACK is a built-in id or a pack directory.

kirto-gate pack list

Run this command:

kirto-gate pack list

Prints one line per built-in pack: its id, its version, how many rules and controls it carries, and its title. The id is what pack show and pack add take; pack show prints one pack whole, README included.

kirto-gate pack show

Run this command:

kirto-gate pack show PACK

Prints the pack: its README, the controls it cites with their citations, the controls it attaches to other packs’ rules, the controls it maps to a mechanism rather than a rule, and the deployment fragment pack add would copy, comments included. That is everything a reviewer needs and everything there is; a pack has no hidden half. PACK is a built-in id (see pack list) or the path of a pack directory, which is checked before it is shown.

kirto-gate pack add

Run this command:

kirto-gate pack add [-deployment FILE] [-write] PACK...
kirto-gate pack add -source NAME [-dry-run] [-force] [-socket PATH | -url URL] PACK...

Copies each pack’s detectors, guardrail rules and access rules into the deployment document, at their own addresses, leaving every other line of the document as it was, comments included. The result is compiled the way the gateway compiles it before anything is printed or written, so a pack whose rule names a detector the document calls something else is refused with the gateway’s reason. Variables the document takes from the environment have to be set, as they do for kirto-gate check.

With -source the document is a stored configuration source read through the admin API, spliced the same way, and written back at the revision that was read, so a change landed in between is refused rather than overwritten. Nothing is compiled here: a source is a fragment of the deployment, and the gateway compiles the whole before the write lands. Name the source that owns guardrails; the block has one owner. The door is chosen as for kirto-gate admin: -socket, or -url with the token kirto-gate login cached. -dry-run sends the write with every check and stores nothing, and reports what would have landed. A source somebody else wrote last is refused the way config apply refuses it, naming what they changed since you last wrote it; -force writes over them.

An object the document already has is compared with the pack’s by meaning. Equal, it is kept; different, the add is refused and names it, and nothing is written. So adding a pack twice changes nothing, and adding a newer edition of a pack lists what the edition changed.

A pack that builds on another attaches its control identifiers to rules that pack carries, and add unions them onto the rule’s controls. Name the base pack first on the command line, or add it earlier; a pack whose base is absent is refused and names it.

What was added and what was already there is reported on stderr, one line per object. Flags come before the packs, as in every command of this binary. Without -write the merged document goes to stdout:

Run this command:

kirto-gate pack add -deployment deployment.yaml sa-pdpl > merged.yaml
kirto-gate pack add -deployment deployment.yaml -write sa-pdpl

A pack directory of your own is added the same way, and is held to the same checks as a built-in first:

Run this command:

kirto-gate pack add -deployment deployment.yaml -write ./packs/acme-controls

Into a running deployment, through the local socket or a signed-in URL:

Run this command:

kirto-gate pack add -source policy -socket /run/kirto-gate/admin.sock sa-pdpl
kirto-gate pack add -source policy -url https://gw.example sa-pdpl

flag	value	default
-deployment	string	deployment.yaml	the deployment document to copy the pack into; a file that does not exist is an empty document
-write	boolean	—	rewrite the document in place. Without it the merged document is printed and the file is untouched
-source	string	—	copy into this stored configuration source through the admin API instead of a file; created when there is none of the name
-dry-run	boolean	—	with -source: run every check on the cluster and write nothing
-force	boolean	—	with -source: write over a source somebody else wrote last
-socket	string	—	admin.local_socket path (default $KIRTO_GATE_ADMIN_SOCKET)
-url	string	—	gateway URL, using the token from kirto-gate login, or the one in $KIRTO_GATE_ADMIN_TOKEN_FILE where that is set (default $KIRTO_GATE_ADMIN_URL)

kirto-gate version

Run this command:

kirto-gate version

Prints one line: the build, its commit and date, the Go toolchain and the platform, which is what to paste into a bug report. A build made outside the release pipeline reads what the toolchain stamped, so it answers with something true rather than “unknown”, and says -dirty when it was made from a modified tree.