ankra org
Commands to list, switch, create, and manage organisations.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.ankra org ai-environment get
Show the organisation’s 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:--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 settingsankra 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:--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 the organisation’s own external-dns webhook 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’). 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. Refused when the zone is not a domain name, when the organisation has no DNS credential of that name, 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/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, or TXT, and the content is the record target.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 and the free monthly AI allowance. 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 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: