ankra org
Commands to list, switch, create, and manage organisations.ankra org access-gateway
Inspect the Cloud proxy’s Platform organisation access gateankra org access-gateway get
Show a Cloud DNS zone’s access policyankra org access-gateway set
Set a Cloud DNS zone’s access policyankra org access-gateway status
Read both clusters live through Ankra. Check the API and relay deployments, broker URL and Secret references without revealing credentials. Redacted Secret digests are cluster-keyed and cannot prove token equality. This does not perform a browser SSO sign-in or read a Cloud DNS zone policy.ankra org access-gateway zones
List Cloud DNS zones in this organisationankra org access-policy
Show the limits every kubectl access grant in this organisation is held to, an admin’s included, or propose a change to them:ankra org access-policy get
Show the organisation’s Kubernetes access policy. The first line says whether the organisation has set a policy at all (Configured: yes or no); with none, the platform defaults apply. -o json and -o yaml carry it as is_configured. When a proposed change is waiting for an owner or admin, the last line names it and its apply link (pending_proposal in -o json and -o yaml).ankra org access-policy proposal
Show one proposed change to the organisation’s Kubernetes access policy: who proposed it and why, the policy before and after (changed rows marked *), its status, and while it is pending the link an owner or admin applies it from. The CLI cannot apply it.ankra org access-policy proposals
List proposed changes to the organisation’s Kubernetes access policy, newest first.--status pending (the default) shows the one waiting for an
owner or admin; --status all shows every proposal, and applied, dismissed,
expired or superseded show those alone.
ankra org access-policy set
Propose a change to the organisation’s Kubernetes access policy. Nothing changes when this runs. The platform records the proposal and answers a link; an organisation owner or admin must open the link, signed in, and apply it. The CLI cannot apply it: the policy is changed by a person, never by a token. Pass only what should change; every other field keeps its live value. The command prints the policy before and after (changed rows marked *), the proposal id, when it expires (7 days) and the apply link. A new proposal replaces one that is still pending.--wait blocks until the proposal is decided. Exit codes: 0 applied, 4
dismissed by an owner or admin, 1 expired or replaced by a newer
proposal, 5 still pending when --timeout ran out (it stays pending and
can still be applied).
Proposing needs kube_access.manage.
Examples:
ankra org ai-environment
Show or change the organisation’s preview settings - where an on-demand demo or PR preview is published, and how it terminates TLS - and where AI workspaces and demos run (the staging cluster), how long they live, and the mode new AI gateway connections start in.ankra org ai-environment get
Show the organisation’s AI workspace and preview settingsankra org ai-environment set
Change where PR demos are published, and how they terminate TLS. Only the flags you pass are written; the rest keep their stored values. Pass a flag with an empty value to clear that field:--staging-cluster takes a cluster name or id; an empty value clears it.
--workspace-ttl-hours is 1-168, --demo-ttl-hours 1-720, and each
--demo-ttl-role-cap (admin, operator or member) is the longest demo that role
may ask for, 1-720 hours; roles not named keep their cap.
--default-gateway-mode is the mode new AI gateway connections start in: ask
or agent.
--demo-cert-issuer only applies alongside a demo base domain: on the Ankra
subzone Ankra picks the issuer itself, from the networking stack it can
verify. Naming one without a base domain is refused rather than stored.
A write that leaves previews on plain http reports it in the output rather
than succeeding silently.
Requires organisation admin.
ankra org ai-review
Configure the organisation’s AI code review. ‘repos’ turns the review on or off for one repository (and sets its model, draft reviews and review cap); ‘related-repos’ states which other repositories a review may read. A connection’s own settings stay in the portal’s Source control & AI review settings, and the organisation-wide review model is chosen with ‘ankra ai lanes set pr_review <model>‘.ankra org ai-review related-repos
State which repositories an AI code review may also read. When a pull request removes something other code may depend on, the review searches the repositories related to the one under review for code that still uses it. Applications Ankra installs on the same cluster are related with no configuration. These commands state the relationships a deploy graph cannot know about: a client and the API it calls, or a shared library.--credential, a GitHub credential name or ID
from ‘ankra credentials list --provider github’. It can be left out when the
organisation has exactly one GitHub App credential.
Listing requires organisation membership; adding and removing require
organisation admin.
ankra org ai-review related-repos add
Relate two repositories, so an AI code review of either may read the other. Both are the provider’s repository path, owner/name. Ankra checks with GitHub that the chosen installation reaches both before it stores the pair, and refuses a pair it could never read. Requires organisation admin.ankra org ai-review related-repos list
List the related repositories stated under a GitHub App installationankra org ai-review related-repos remove
Stop an AI code review consulting a related repository. Name the relationship by its ID from ‘list’, or by its two repositories in either order. A relationship has no direction, so naming the repositories removes every stored row relating them, whichever order each was stated in. Removing a relationship changes nothing about reviews already posted.--credential is only read when the repositories are named, to find the
installation the relationship is stated under.
Requires organisation admin.
ankra org ai-review repos
Turn the AI code review on or off for one repository. Each source-control connection (a GitHub App installation, or a GitLab or Bitbucket credential) has binding-level AI review settings that every repository on it inherits. A repository rule replaces them for that one repository: whether the review runs, whether the AI answers @mentions, and whether pull requests get previews, plus optionally the review model, draft reviews and the per-pull-request review cap.--binding <provider>/<id> (from ‘list’) when that is ambiguous.
Listing requires organisation membership; set and unset require organisation
admin.
ankra org ai-review repos list
List the source-control connections, their AI review settings and repository rulesankra org ai-review repos set
Set one repository’s AI review rule. Only the switches you pass change. The others keep the repository’s current rule, or the connection’s settings when the repository has no rule yet, so ‘set my-org/my-repo--review’ never switches @mention replies or previews off
by accident.
Requires organisation admin.
ankra org ai-review repos unset
Remove one repository’s AI review rule, so it follows the connection’s settingsankra org ai-spend-cap
The organisation’s daily AI caps. The money cap bounds what chat may spend per UTC day; the token caps bound the unattended runs: past the soft cap every run degrades to the quick tier for the rest of the day, past the hard cap new runs are refused until midnight UTC.ankra org ai-spend-cap set
Set one or more caps. Each flag takes a number or “none” to clear that cap; a cap whose flag is not passed is left as it is. The hard token cap can never be set below the soft one.ankra org ai-spend-cap show
Show the caps and today’s spendankra org ci-settings
Show or change the settings every pipeline in this organisation runs under.--org flag to read or
change another organisation you administer.
ankra org ci-settings get
Show the organisation’s pipeline settings and capacityankra org ci-settings pool
Show or change the organisation’s CI cluster pool: the clusters its pipeline runs are spread across.--cluster’) is
always a member - the primary. Each run is pinned, when its first step is
dispatched, to the least-loaded member whose agent can take a step: steps in
flight over the member’s CI workers, scaled by its weight, so a member weighted
200 takes runs until it carries twice the load of a member weighted 100. When
two members are close, the one where the repository ran last wins, because it
holds the repository’s warm caches. A run never moves between clusters.
An organisation that lists no members runs every pipeline on its pipeline
cluster exactly as before.
A member must be a cluster of this organisation whose agent runs pipeline
steps (give it workers first with ‘ankra cluster agent ci set --workers N’),
and a cluster may be in one organisation’s pool only.
Reading requires organisation membership; changing requires organisation admin.
ankra org ci-settings pool add
Add a cluster (name or id) to the organisation’s CI pool, or change the weight of one already in it.--weight is the member’s relative share of runs, 1 to 1000. Without it a new
member gets 100 and a member already listed keeps its weight.
Runs queued after this land on the member as soon as it is the least loaded.
Requires organisation admin.
ankra org ci-settings pool list
List the organisation’s CI pool membersankra org ci-settings pool remove
Remove a cluster (name or id) from the organisation’s CI pool. New runs stop going to it; runs already pinned to it finish there. Removing the organisation’s pipeline cluster only drops its weight - it stays the primary member until the pipeline cluster itself is changed. Requires organisation admin.ankra org ci-settings set
Change the settings every pipeline in this organisation runs under. Only the flags you pass are written; every other setting keeps its stored value, so raising one number can never clear the image policy. Clear the pipeline cluster with an empty value:--always-run-stage, --full-run-on-default-branch and --skip-markers are the
safety net around path filters. An always-run stage (and every stage it
needs) runs whatever its path filters say; a full run on the default branch
sets the filters aside for every push there; --skip-markers decides where a
[skip ci] marker in a pushed commit skips the run: everywhere,
except_default_branch (Ankra’s default) or never. A merge train car and a tag
push never honour a marker.
--allowed-image-prefix and --egress-allowed-cidr replace their whole list
rather than adding to it, because a list you can only grow is one you cannot
correct. Passing either once with an empty value clears it: no image
restriction, or no private egress beyond the public internet.
--ignore-unfixed is the floor under every pipeline’s image gate. It is true by
default, letting a gate stage leave findings with no available fix out of its
verdict; set it to false and every unfixed finding blocks, whatever any
pipeline asks for.
One thing ‘get’ shows has no flag here and never will:
platform_builds_enabled, printed as “Platform builds enabled”. It is Ankra’s
grant of the platform-builders capability to this organisation, not a setting
of it - a read-only report of a decision only Ankra can take. The endpoint
refuses a body that names it with HTTP 422 (“platform_builds_enabled is
Ankra’s grant, not a setting of this organisation”), so writing back a ‘get’
payload wholesale is refused rather than half-applied. Ask Ankra to enable it.
Requires organisation admin. A member’s attempt is refused with exit code 7.
ankra org cloudflare
Manage the domains your Cloudflare account holds, from Ankra. Connect a scoped Cloudflare API token once, then list your domains and manage their DNS records. Records are written into your own Cloudflare account and take effect immediately - there is no pending state to wait for.ankra org cloudflare add
Add a DNS record. The name is a bare label inside the domain, a fully-qualified name inside it, or ’@’ for the domain itself.--ttl is refused with --proxied.
ankra org cloudflare connect
Connect a scoped Cloudflare API token under the given credential name. The token is read from the ANKRA_CLOUDFLARE_API_TOKEN environment variable, or from stdin with--token-stdin - never from a flag, so it does not land in your
shell history or the process list. Ankra verifies it with Cloudflare before
storing anything, and refuses a token that reaches no zones: such a token
authenticates perfectly and manages nothing.
Pass --verify-only to check a token without storing it.
ankra org cloudflare credentials
List the organisation’s connected Cloudflare credentialsankra org cloudflare delete
Delete a DNS record, referenced by its id or by its name. When several records share a name, disambiguate with--type.
The record lives in your own Cloudflare account: Ankra cannot restore it, and
removing a record live traffic depends on takes the hostname down immediately.
The prompt names the record before removing it.
ankra org cloudflare domains
List the domains (zones) the connected Cloudflare credential reaches. Pass a domain name to resolve just that one, which costs a single lookup rather than a walk through every domain in the account. An empty result means Ankra does not reach that domain - either it is not in Cloudflare, or the connected token is scoped away from it.ankra org cloudflare records
List a domain’s DNS records. The domain is referenced by name or by its Cloudflare zone id. Each record reports whether Ankra created it (MANAGED “ankra”) or it was made elsewhere (MANAGED “external”) - which is how to tell a platform-published record from one written by hand, by Terraform, or by a cluster controller.ankra org cloudflare update
Re-point a record at new content. The record is referenced by its id or by its name; a record’s name and type never change - delete and re-add instead. Only the fields you pass change: an omitted--ttl, --proxied or --priority
keeps the record’s current value.
ankra org create
Create a new organisationankra org current
Show the currently selected organisationankra org custom-dns-zones
Declare, list, and withdraw the DNS zones every cluster in the organisation serves with one of the organisation’s own DNS credentials - an external-dns webhook credential or a Cloudflare credential - alongside the generated domain Ankra serves itself. A zone declared here behaves like the generated domain: every cluster in the organisation, the ones that exist and the ones created later, gets its own external-dns for it, rendered and reconciled by Ankra with a DNS credential you supply (‘ankra org dns credentials’, or ‘ankra org cloudflare connect’ for a Cloudflare zone). Each cluster’s controller is pinned to exactly the zone with its own record ownership, so it can never fight Ankra’s controller, another cluster’s, or records you publish yourself. ‘ankra cluster custom-dns-zones’ declares the same thing for one cluster. A cluster’s own declaration of a zone wins over the organisation’s on that cluster, which is how one cluster serves the zone with a different credential. Withdrawing a zone removes the controllers Ankra rendered from every cluster that inherited it; clusters that declared the zone themselves keep theirs, and the zone’s records are yours and are left untouched.ankra org custom-dns-zones add
Declare a zone every cluster in the organisation serves, with the DNS credential that can publish into it. Ankra renders an external-dns for the zone on each cluster on the next reconciler pass, and on every cluster created afterwards without further declaration. Use--cloudflare-credential for a zone hosted at Cloudflare: the zone is
published by external-dns’s native Cloudflare provider through that
organisation Cloudflare credential, checked with Cloudflare before anything is
stored, and every cluster’s controller runs upsert-only - it never changes or
deletes a record someone else made.
Refused when the zone is not a domain name, when the organisation has no
credential of that name (or, with --cloudflare-credential, no Cloudflare
credential of that name), when a Cloudflare token cannot reach the zone or may
not edit its DNS, or when the zone overlaps the domain Ankra already serves
for the organisation - that would put a second controller on names Ankra’s own
external-dns publishes.
ankra org custom-dns-zones list
List the zones declared for every cluster in the organisationankra org custom-dns-zones remove
Withdraw an organisation-wide zone. Ankra removes the controllers it rendered from every cluster that inherited the zone on the next reconciler pass; clusters that declared the zone themselves keep theirs. The zone’s records are yours and are left untouched.ankra org dns
Manage CNAME/A/AAAA/TXT records under the organisation’s own delegated DNS zone (shown by ‘ankra org dns zone’). Records are reconciled asynchronously: a new or edited record starts in state pending and turns active once it is published to the authoritative nameservers.ankra org dns add
Add a record to the organisation’s delegated zone. The name is the label inside the zone (the zone fqdn is appended server-side), the type is one of CNAME, A, AAAA, or TXT, and the content is the record target. An AAAA record takes an IPv6 address and needs the zone on Ankra Cloud.ankra org dns credentials
Store and list the organisation’s DNS webhook credentials - the ones the custom DNS zone lane serves your own zones with (‘ankra org custom-dns-zones’ for every cluster in the organisation, ‘ankra cluster custom-dns-zones’ for one cluster). The webhook provider URL embeds the provider token, so it is written to the platform’s secret store on create and never returned by any read: ‘list’ shows names and ids only. Re-creating a credential under the same name re-points every cluster binding that names it, which is how a rotated token rolls out.ankra org dns credentials create
Store a DNS webhook credential. The webhook provider URL is the external-dns webhook endpoint including its token; it goes to the platform’s secret store and is never echoed back. Creating a credential under a name that already exists replaces its stored URL, which re-points every cluster binding that names it - the rotation path.ankra org dns credentials list
List the organisation’s DNS credentialsankra org dns delete
Delete a record, referenced by its id or by its name (the label or the full fqdn). When several records share a name, disambiguate with--type.
ankra org dns list
List the organisation’s DNS recordsankra org dns update
Re-point a record at new content. The record is referenced by its id or by its name (the label or the full fqdn); the name and type of a record never change - delete and re-add to rename. Pass--ttl to change the ttl at
the same time.
ankra org dns zone
Show the organisation’s delegated DNS zoneankra org dns zones
List every cluster-level DNS zone in the organisation: the cluster, the zone fqdn, and its reconciliation state. This is the inventory a root-domain switch has to clear. Switching the organisation’s Ankra root domain (‘ankra org domain set’) is refused while any cluster zone still lives under the old root, and a zone is removed with ‘ankra cluster domain <cluster>--remove’.
Listing is a read: it never creates a zone.
ankra org domain
Show or register the root domain every Ankra-generated hostname in the organisation nests under - the organisation’s delegated DNS zone, its clusters’ domains, and the preview hostnames built from them. Unset, the platform default (ankra.cc) applies. Registering your own domain requires it to be delegated to the Ankra nameservers first; the write is refused otherwise, naming the nameservers to point at.--demo-base-domain’, not this command.
Changing the root domain is refused while cluster DNS zones or DNS records
still live under the old root; the refusal lists exactly what to remove. Use
‘ankra org dns zones’ and ‘ankra org dns list’ to inventory them, and
‘ankra cluster domain <cluster> --remove’ and ‘ankra org dns delete <record>’
to clear them. Ankra re-creates the organisation zone under the new domain
automatically once the switch is accepted.
WHAT ANKRA TOUCHES IN YOUR DOMAIN
The domain you register becomes the organisation’s zone itself: Ankra adopts
it as the apex rather than carving a subzone out of it, and each cluster
gets its own <cluster_short_id>.<domain> subzone under it. The external-dns
Ankra installs on every cluster in the organisation holds a token pinned to
the whole domain, so an Ingress on any hostname under it - a top-level name
like app.<domain> included - is published by the cluster serving it, with no
credential of your own. Records you already publish that no cluster’s
Ingress claims are left alone: each cluster’s external-dns owns only the
records it created.
That is the lane for a domain hosted in Ankra’s own DNS account. For a zone
you hold in your own provider account, declare it with your own credential
instead (‘ankra org dns credentials create’ + ‘ankra org custom-dns-zones
add’).
WHAT A SWITCH DOES NOT CHANGE
Zone labels are derived from the organisation and cluster ids, so they are the
same under any root. A cluster keeps its label across a switch, and with it
the --txt-owner-id of the external-dns Ankra manages for it and any GitOps
path built from it. A switch never re-stamps an owner id and never leaves an
external-dns pointed at a TXT registry it no longer matches.
Reading requires organisation membership; changing it requires organisation
admin.
ankra org domain get
Show the organisation’s Ankra root domainankra org domain set
Register the organisation’s own root domain, or clear it back to the platform default with--default.
The domain must be a bare domain you own (example.com, not sub.example.com or
a domain under the platform default), already delegated to the Ankra
nameservers.
Existing records in that domain are preserved. Ankra creates one subzone,
<org_short_id>.<domain>, and confines itself to it - nothing at the apex or
under any other name is read, written or deleted, by this command or by
anything Ankra runs afterwards.
The switch is refused while cluster DNS zones or DNS records still live under
the old root; the refusal lists them, and says which of them you clear
yourself and which are published by something you have to remove first:
--help’ for what a switch does and does not change.
ankra org invite
Invite a user by email to the current organisation. Valid roles: owner, admin, operator, member (default), viewer, read-only. owner/operator alias onto admin/member on the invite until the RBAC assignments API ships; run ‘ankra org roles’ for the full list. Examples:ankra org limits
Some limits cannot be raised self-serve: the playground memory budget, the free monthly AI allowance and the registry storage limit. Requests go to the Ankra team for review; you are notified when one is decided.ankra org limits list
Show your latest limit-increase request per kindankra org limits request
Request a higher limit, reviewed by the Ankra team.ankra org list
List all organisations you belong toankra org mcp-servers
Register, inspect, and gate external MCP (Model Context Protocol) tool servers for the organisation. A registered server’s tools become callable from agent runs, subject to the server’s permission tier, its allowed-tools list, and per-tool role grants. Credential headers are never stored or sent in plaintext: ‘add--secret-header’ first stores the value in an organisation secret slot and
registers the server with the slot’s ”${SECRET_SLOT:<id>}” sentinel - the
backend refuses plaintext values under sensitive-looking header names. The
curated adapter catalog (‘ankra org mcp-servers catalog’) documents the
exact header value form each provider expects (for example “Bearer <token>”,
or “Sentry-Bearer <token>” for Sentry).
ankra org mcp-servers add
Register an MCP server so agent runs can call its tools. Credential headers come in two forms.--header sends a plaintext header (for
non-secret values only; the backend refuses plaintext under
sensitive-looking names). --secret-header stores the value in an
organisation secret slot labeled “<server-name> <Header>” and registers the
server with the slot’s ”${SECRET_SLOT:<id>}” sentinel, so the secret never
lands in the server record. Prefer passing only the header name
(--secret-header Authorization) to be prompted with hidden input, or pipe
the value on stdin - the inline Key=Value form works but leaves the secret
in your shell history and visible in process listings. The catalog
documents the exact value form each curated provider expects. If a later
step of the registration fails, slots already created for it are removed
again so no secret material is left orphaned.
With --adapter and no --allowed-tools, the allowed-tools list is seeded from
the adapter’s recommended tools. Servers start enabled unless --disabled is
given, and --cluster (repeatable) restricts which clusters’ agent runs may
use the server.
--url is required for every transport. For --transport stdio the platform
stores the value as the server’s identifier only and never dials it, so a
descriptive placeholder such as cmd://<binary-name> is expected there.
ankra org mcp-servers catalog
List the curated adapters: known MCP server products with their transport, URL placeholder, expected credential headers (including the exact value form, e.g. “Bearer <token>”), and a recommended tool allow-list. Passing an adapter key to ‘add--adapter’ records the pairing and seeds the
server’s allowed tools from the adapter’s recommendation when --allowed-tools
is not given.
ankra org mcp-servers disable
Disable a server without deleting it. Its configuration and grants are kept, but agent runs cannot call its tools until it is enabled again.ankra org mcp-servers enable
Enable a server so agent runs can call its granted tools again.ankra org mcp-servers get
Show a server’s full configuration: URL, transport, permission tier, allowed tools, configured env/header names (values are never echoed back - credential values live in secret slots), cluster allow-list, and connection state.ankra org mcp-servers grant
Grant a tool to an organisation role, making it callable from agent runs started by members holding that role. Grants are additive; revoke one with ‘revoke-grant’.ankra org mcp-servers grants
List which tools are granted to which organisation roles on a server. A tool with no grant is not callable from agent runs regardless of the allowed-tools list.ankra org mcp-servers health
Probe the server: whether the platform can reach it and which of its tools the current configuration allows. The raw probe document is available with -o json.ankra org mcp-servers list
List every registered MCP server with its transport, enabled state, permission tier, adapter pairing, grant count, and last connection error.ankra org mcp-servers remove
Delete a server and its tool grants. Agent runs can no longer call its tools; secret slots its headers referenced are not deleted (remove those separately if nothing else uses them).ankra org mcp-servers revoke-grant
Revoke one tool’s grant from one role. Other roles’ grants on the same tool are untouched.ankra org mcp-servers tools
List the server’s tool inventory as the platform sees it, after the allowed-tools filter. The raw inventory document is available with -o json.ankra org mcp-servers update
Apply a partial update to a server. Only the flags you pass change; everything else keeps its current value.--clear-allowed-tools removes the
allow-list entirely (every tool the permission tier allows becomes
callable), and is mutually exclusive with --allowed-tools. Use the separate
‘enable’ and ‘disable’ subcommands to flip the server on or off.
ankra org members
List members of an organisationankra org oidc-trust
Manage the GitHub Actions OIDC trust policies of the organisation. A policy names ONE repository exactly, by owner/name AND by the numeric repository and owner ids (which GitHub never reuses, so a renamed or re-created repository cannot inherit it), and optionally a ref, an environment and a workflow. A job from that repository then runs--allow-pull-request; pull_request_target never is.
Find the ids with: gh api repos/OWNER/NAME --jq '.id, .owner.id'
Requires organisation admin.
ankra org oidc-trust create
Create a trust policy.--repository, --repository-id, --repository-owner-id and --role are required.
No value accepts wildcards. --ttl is how long the minted token lives
(default 15m, at most 1h). Prefer pinning an --environment that requires
reviewers in GitHub.
ankra org oidc-trust delete
Delete a trust policy and revoke the tokens it mintedankra org oidc-trust list
List the organisation’s OIDC trust policiesankra org provenance
Verified provenance at deploy: a pipeline’s publish step signs a statement about every image it publishes, and a deploy can refuse an image that is not attested. This command holds the organisation default and the signing keys.ankra org provenance get
Show the organisation’s default provenance modeankra org provenance keys
List the organisation’s provenance signing keys, oldest generation first. Only public keys are shown.--public-keys prints the PEM of every key that is not revoked, one block per
key. ‘cosign verify-attestation --key’ takes one key per check, so with more than
one trusted key save each block to its own file and try them in turn.
ankra org provenance revoke
Revoke a key. Nothing it signed verifies any more: an application under enforce refuses those images until they are published again, which includes rolling back to them. Revoking the active key makes the next publish create a successor. Needs the security.manage permission. Use ‘ankra org provenance keys’ for key ids.ankra org provenance rotate
Create the next key generation. The next publish signs with it. Earlier generations stay trusted, so images already published keep verifying. At most 16 generations exist per organisation. Needs the security.manage permission.ankra org provenance set
Set the mode every application without its own mode runs under, or remove the default with--clear. Needs the security.manage permission.
Modes:
--yes
skips the question).
ankra org remove
Remove a user from the current organisationankra org roles
List the assignable organisation rolesankra org switch
Switch to a different organisation by slug, name, or IDankra org terminal-session
Every pod terminal session opened through Ankra is recorded. The open_pod_terminal audit row carries the session id in its details; this command prints the session’s facts and, with--transcript, replays the
recorded output as text (everything the container printed, in order).
--show-input lists what was typed as well, with control characters named.
Needs the audit.read permission. A recording contains whatever the shell
printed, secrets included.
Examples:
ankra org usage
Show everything the organisation used of Ankra over a window of days, per meter and period: worker vCPU-hours, ordered playground time, managed service instance time and storage, hosted logs and metrics accepted, and AI requests and tokens. The window defaults to the current month to date.--period picks this month
or last month; --from and --to (exclusive) pick any stretch of UTC days up to
93 days long, within the 400 days usage is kept. --granularity splits it
into calendar months or days, and --group-by splits each meter by cluster,
by the application a managed service serves, or by managed service instance.
Each line says how completely it was measured. A quantity is exact when
every hour of the period was measured, a lower bound (shown as >=) when
some were not or are still being counted, and ‘not measured’ when none was,
for instance a service whose cluster was offline throughout. Not measured is
never 0; in -o json the quantity is null.
Each line also says what it costs. ‘included (pilot)’ means Ankra publishes
no rate and charges nothing for it: managed services and hosted logs and
metrics during the pilot. A priced line shows the amount in EUR the
published rate makes of it, as the invoice will. A line no rate applies to
says why, for instance that AI usage has no per-unit rate.
Grouped by application, a service that serves several applications is
counted under each of them (marked shared), so application lines do not add
up to the organisation’s total. Grouped by meter, every meter answers every
period; grouped otherwise, a group that used none of a meter in a fully
measured period has no line.
-o table (the default) shows quantities in units a person reads (GB, hours,
thousands separators). -o json and -o yaml carry the platform’s own report:
raw quantities with their unit, and null where nothing was measured.
Needs the billing.read permission.
ankra org variables
Manage organisation-scoped variables that are available to every cluster in the organisation as template substitutions in stack manifests and addon values.ankra org variables delete
Delete an organisation variableankra org variables get
Get a single organisation variableankra org variables list
List all organisation variablesankra org variables reveal
Print one organisation variable’s stored value. This is the only way to read back a secret variable: list and get never show it. Revealing needs permission to change variables, and every reveal is recorded in the organisation’s audit log. The value is printed on its own line, so it can be captured in a script:ankra org variables set
Create or update an organisation variable (upsert). If the variable does not exist it is created; otherwise its value (and description, when supplied) is updated.--secret creates the variable as a secret, or marks an existing one secret:
list and get then never show its value, and only “ankra org variables reveal”
reads it back. --secret=false makes an existing secret variable plain again.
Without the flag an update keeps the variable’s current setting.
The value can also be read from stdin by passing ”-”: