> ## Documentation Index > Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt > Use this file to discover all available pages before exploring further. # ankra registry > Manage the organisation's Ankra registry ## ankra registry Manage the organisation's Ankra registry. Every organisation publishes to a private project on the Ankra registry. Ankra mints the logins its own lanes use - the organisation's ci and pull robots, and one push robot per application - and these commands cover the robot accounts you need on top of that: a login for CI you run outside Ankra, a laptop pushing an image by hand, or a cluster Ankra does not manage pulling from the project. 'ankra registry robots list' shows both: yours, and the ones Ankra manages. A robot account is bound to one registry project. 'ankra registry projects' creates extra projects beside the organisation's own, so a robot can be given access to only what is kept in one of them. Every project has a storage limit; a full one refuses every push. 'ankra registry storage' shows how full it is, what fills it, the image retention policy that frees it, and asks Ankra for more. ## ankra registry projects Create, list and delete the organisation's registry projects. Every organisation has one project on the Ankra registry, named default here, and everything it publishes lands there. A robot account is bound to one project, so a robot on the default project reaches all of it. An extra project is how you give a login less: push what should be kept apart into the extra project and bind a robot to it with 'ankra registry robots create \ `--project` \'. An extra project is private and has the same scan policy, retention policy and storage quota as the default one. Deleting one never deletes anything else on the way: a project that still holds repositories, or that robot accounts are still bound to, is refused. ## ankra registry projects create Create an extra registry project for the organisation. The name is 2 to 30 lower-case letters, digits and single hyphens; 'default' is the organisation's own project and is reserved. The project is private and has the same scan policy, retention policy and storage quota as the default one. Bind a robot account to it with 'ankra registry robots create \ `--project` \'. ```bash theme={null} ankra registry projects create [flags] ``` **Examples** ```bash theme={null} ankra registry projects create staging ankra registry robots create staging-ci --project staging ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry projects delete Delete an extra registry project. Nothing else is deleted on the way. A project that still holds repositories is refused until they are deleted from the registry, and one that robot accounts are still bound to is refused until they are revoked. The organisation's own project (default) cannot be deleted. ```bash theme={null} ankra registry projects delete [flags] ``` **Examples** ```bash theme={null} ankra registry projects delete staging --yes ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `-y`, `--yes` | `false` | Skip the confirmation prompt | ## ankra registry projects list List the organisation's registry projects: its own (default) first, then the extra ones, each with the path images are pushed under, how many repositories it holds and how many of your robot accounts are bound to it. With `--registry` and `--admin-credential` it lists the projects of a Harbor your organisation runs itself instead, as that credential sees them - the names to bind a robot to with 'ankra registry robots create \ `--registry` ... `--project` \'. That listing acts as the admin credential, so it needs credentials.reveal. ```bash theme={null} ankra registry projects list [flags] ``` **Examples** ```bash theme={null} ankra registry projects list ankra registry projects list -o json ankra registry projects list --registry smartoptics-harbor --admin-credential smartoptics-harbor-robot-admin ``` **Flags** | Flag | Default | Description | | - | - | - | | `--admin-credential` | | With `--registry`: the organisation's registry credential that may manage robot accounts on that registry | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--registry` | | An integrated OCI registry entry - a Harbor your organisation runs - instead of the Ankra registry ('ankra helm registries list' shows them) | ## ankra registry robots Create, list, rotate and revoke robot accounts on the organisation's registry project. A robot is a named login bound to one registry project: it reaches the organisation's project and nothing else on the registry. It holds a preset - push (push and pull) or pull - or its own list of permissions, and can be set to expire. Its secret is shown once, when it is created or rotated; the login is also stored as the managed registry credential ankra-harbor-robot-\, so it can be referenced from clusters and applications like any other registry credential. Revoking a robot deletes it from the registry and drops that credential in one step. The robots Ankra mints for its own lanes (ci, pull, one per application) are listed too. They are managed: Ankra rotates them and hands the new secret to the builds and clusters that use it, so 'rotate' and 'delete' refuse them. ## ankra registry robots create Create a robot account on the organisation's registry project and show its secret once. The name is 2 to 32 lower-case letters, digits and hyphens. The registry login becomes robot\$\+user-\. `--scope` push (the default) grants push and pull; `--scope` pull grants pull only. For anything else - a cleanup job that deletes artifacts, a release job that moves tags, a scanner - grant exactly what it needs with `--permission`, repeated or comma-separated, instead of a scope; 'ankra registry robots permissions' lists what can be granted. Whatever it holds, the robot reaches the organisation's project and no other. `--expires-in-days` makes the registry stop honouring the robot after that many days; without it the robot never expires. `--project` binds the robot to one of the organisation's extra registry projects instead of its own ('ankra registry projects list' shows them); it then reaches that project and nothing else. `--registry` creates the robot on a Harbor your organisation runs itself instead: name the OCI registry entry it is integrated as ('ankra helm registries list' shows them) and, with `--admin-credential`, a registry credential of the organisation that may manage robot accounts there (project administrator on the project). Ankra acts on that registry only with that credential, never its own; a robot login Ankra manages cannot be used. `--project` is required there: the one project of that registry the robot is bound to, such as collectorcharts, and the only one it reaches ('ankra registry projects list `--registry` ... `--admin-credential` ...' shows them). Rotate, delete, get and list work the same afterwards. The secret is printed exactly once, with a docker login command that reads it from stdin - copy it now, it is not stored anywhere you can read it back from. The secret is never put on a command line, where the shell history and 'ps' would keep it. Rotate it with 'ankra registry robots rotate' if it is lost or leaked. Creating a robot needs the credentials.write permission. A `--permission` list that reaches past repository:pull and repository:push (deleting artifacts, moving tags, and the like) also needs credentials.reveal, and so does a robot on an integrated registry (`--registry`), which is minted by acting as the admin credential. With `--permission` or `--expires-in-days` the CLI first checks that the platform offers them by reading the robot listing, and with `--project` that the organisation has the project; a token without credentials.read skips those checks, and if the robot then comes back broader, longer-lived or on another project than asked it is deleted again before its secret is shown. ```bash theme={null} ankra registry robots create [flags] ``` **Examples** ```bash theme={null} ankra registry robots create jenkins --description "Jenkins on the office server" ankra registry robots create edge-cluster --scope pull ankra registry robots create contractor --scope pull --expires-in-days 30 ankra registry robots create cleanup --permission repository:pull,artifact:list,artifact:delete ankra registry robots create staging-ci --project staging ankra registry robots create jenkins --registry smartoptics-harbor \ --admin-credential smartoptics-harbor-robot-admin --project smart-hub-images ankra registry robots create jenkins -o json | jq -r .secret ``` **Flags** | Flag | Default | Description | | - | - | - | | `--admin-credential` | | With `--registry`: the organisation's registry credential that may manage robot accounts on that registry | | `--description` | | What this robot is for (shown in the listing) | | `--expires-in-days` | `0` | Days until the registry stops honouring the robot (default: it never expires) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--permission` | `[]` | A permission to grant instead of a preset scope, written resource:action; repeat the flag or separate with commas ('ankra registry robots permissions' lists them) | | `--project` | | The registry project to bind the robot to (default: the organisation's own; 'ankra registry projects list' shows the others) | | `--registry` | | An integrated OCI registry entry - a Harbor your organisation runs - instead of the Ankra registry ('ankra helm registries list' shows them) | | `--scope` | `push` | Rights on the project: push (push and pull) or pull | ## ankra registry robots delete Revoke a robot account: delete it from the registry and drop the managed credential holding its login. Everything still logging in with the robot stops working, which is the point of a revoke. Prefer 'rotate' when the robot should keep working under a new secret. A robot Ankra manages is refused: it is not yours to revoke. ```bash theme={null} ankra registry robots delete [flags] ``` **Examples** ```bash theme={null} ankra registry robots delete jenkins --yes ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `-y`, `--yes` | `false` | Skip the confirmation prompt | ## ankra registry robots get Show one robot account: its registry login, what it may do, the project it is bound to, the managed credential holding its login, and when it was created, last rotated and expires. One of your own robots is read by its name; one Ankra manages by the name the listing gives it (ci, pull, app-\). The secret is never shown here; rotate the robot to get a new one. ```bash theme={null} ankra registry robots get [flags] ``` **Examples** ```bash theme={null} ankra registry robots get jenkins ankra registry robots get ci ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry robots list List every robot account the organisation holds on its registry project. Your own robots come first, then the ones Ankra manages: the organisation's ci and pull robots and one push robot per application. Each row shows the robot's kind, registry login, what it may do, the project it is bound to, when it expires, and when it was created and last rotated. Secrets are never listed. `--kind` narrows the listing: user (the ones you created), managed (everything Ankra minted), organisation (ci and pull) or application. Managed robots are shown so you can see every login that reaches the organisation's images; they are rotated by the lane that owns them, not from here. ```bash theme={null} ankra registry robots list [flags] ``` **Examples** ```bash theme={null} ankra registry robots list ankra registry robots list --kind user ankra registry robots list --kind managed -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `--kind` | `all` | Which robots to list: all, user (yours), managed (Ankra's), organisation or application | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry robots permissions List the permissions a robot account can be created with. Each one is a value for 'ankra registry robots create `--permission`'. They are all rights on the content of the organisation's own registry project - pulling, pushing, listing and deleting repositories and artifacts, managing tags, scanning - never on the project's settings or on any other project. ```bash theme={null} ankra registry robots permissions [flags] ``` **Examples** ```bash theme={null} ankra registry robots permissions ankra registry robots permissions -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry robots rotate Mint a new secret for a robot account and show it once. The previous secret stops working the moment the registry answers, which makes this the response to a leaked or lost secret. Update every place that logs in with the robot afterwards. A robot the registry no longer has is minted again under the same name, with the same permissions and the rest of its lifetime. A rotation never extends a robot: one that has expired is refused, and so is a robot Ankra manages. Asks first, because a mistyped name would take another robot's consumers down; `--yes` skips the prompt for scripts. ```bash theme={null} ankra registry robots rotate [flags] ``` **Examples** ```bash theme={null} ankra registry robots rotate jenkins ankra registry robots rotate jenkins --yes -o json | jq -r .secret ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `-y`, `--yes` | `false` | Skip the confirmation prompt | ## ankra registry storage See how full the organisation's registry is, free space, or ask for more. Every registry project has a storage limit (50 GiB by default). Once a project is full the registry refuses every image push to it, so builds stop publishing. Run on its own, this shows the usage against the limit for each project. ```bash theme={null} ankra registry storage usage against the limit ankra registry storage repositories what takes the space, largest first ankra registry storage retention the image retention policy ankra registry storage retention set ... keep fewer or more images ankra registry storage retention run clean up now instead of at the daily run ankra registry storage buy --blocks buy more storage, billed monthly ankra registry storage request ... ask Ankra for a bigger limit ``` ```bash theme={null} ankra registry storage [flags] ``` **Examples** ```bash theme={null} ankra registry storage ankra registry storage -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry storage buy Set how many paid storage blocks the organisation holds on top of its included registry storage. Each block adds its size to the limit of every registry project and is billed monthly for the days it is held. `--blocks` is the number to hold, not the number to add; 0 stops paying for extra storage. It shows the limit and the monthly price before and after, and asks first; `--yes` skips the prompt. Lowering it below what the registry already holds is refused: free space first. For more than the self-serve maximum, ask Ankra with 'ankra registry storage request'. ```bash theme={null} ankra registry storage buy [flags] ``` **Examples** ```bash theme={null} ankra registry storage buy --blocks 2 ankra registry storage buy --blocks 0 --yes ankra registry storage buy --blocks 4 --yes -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `--blocks` | `0` | How many paid storage blocks to hold (0 stops paying for extra storage) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `-y`, `--yes` | `false` | Skip the confirmation prompt | ## ankra registry storage repositories Show which repositories take the registry space, largest first. Repositories under ankra-ci/ hold the images Ankra builds and scans in CI, one per pipeline run and pull request; they are usually what fills the registry. The others hold the images your applications publish. The Retention column names the rule that governs each repository, or the organisation policy. Sizes are approximate: a layer shared by several images is counted for each of them, so use the sizes to rank repositories, not to add up to the usage. This reads every image in the registry and can take a while. ```bash theme={null} ankra registry storage repositories [flags] ``` **Examples** ```bash theme={null} ankra registry storage repositories ankra registry storage repositories --limit 0 -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `--limit` | `20` | How many repositories to show, largest first (0 shows all) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry storage request Ask Ankra for a bigger registry storage limit. `--size` is the limit you need for each registry project, in GiB (more than today's, at most 10240); `--reason` says why. The Ankra team reviews the request and you are notified when it is decided; once approved the registry applies the new limit within about 5 minutes. 'ankra org limits list' shows the request's state. ```bash theme={null} ankra registry storage request [flags] ``` **Examples** ```bash theme={null} ankra registry storage request --size 100 --reason "Three services now publish nightly images" ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--reason` | | Why the organisation needs it (required) | | `--size` | `0` | The storage limit you need for each registry project, in GiB | ## ankra registry storage retention Show or change the image retention policy: which images the registry keeps. An image is kept when it was pushed within the policy's days, or is among the newest images of its repository; everything else is deleted when retention runs (daily). The newest image of every repository is never deleted. Deleted images free their space at the registry's next garbage collection (weekly). The organisation policy governs every repository. A rule replaces it for the repositories its pattern matches - for example a shorter one for CI images: ```bash theme={null} ankra registry storage retention rule add 'ankra-ci/**' --keep-days 7 --keep-latest 2 ``` Patterns are lower-case letters, digits and . \_ / - with \* matching within one path segment and \*\* across segments; braces and commas are not accepted, so write one rule per pattern. ```bash theme={null} ankra registry storage retention [flags] ``` **Examples** ```bash theme={null} ankra registry storage retention ankra registry storage retention -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry storage retention rule Add, remove and list retention rules. A rule replaces the organisation policy for the repositories its pattern matches. Patterns are lower-case letters, digits and . \_ / - with \* matching within one path segment and \*\* across segments; braces and commas are not accepted, so write one rule per pattern. '\*\*' alone is the organisation policy itself ('retention set'). A rule needs an organisation policy that keeps something: when the policy in force keeps nothing, the platform refuses rules until one is set with 'ankra registry storage retention set'. ## ankra registry storage retention rule add Add a retention rule for the repositories a pattern matches, or change the rule already stored for that pattern. `--keep-days` and `--keep-latest` work as in 'retention set'; a flag not passed takes the existing rule's value, or the organisation policy's for a new rule. `--application` ties the rule to an application, so it shows with it. A rule that keeps fewer images than what governs those repositories now asks first; `--yes` skips the prompt. Quote the pattern so the shell does not expand it. ```bash theme={null} ankra registry storage retention rule add [flags] ``` **Examples** ```bash theme={null} ankra registry storage retention rule add 'ankra-ci/**' --keep-days 7 --keep-latest 2 ankra registry storage retention rule add 'investor-update/*' --keep-latest 10 --application ``` **Flags** | Flag | Default | Description | | - | - | - | | `--application` | | The application the rule belongs to (its id) | | `--keep-days` | `0` | Keep every image pushed in this many days (0 turns it off) | | `--keep-latest` | `0` | Always keep this many newest images of each matching repository (at least 1) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `-y`, `--yes` | `false` | Skip the confirmation prompt when the rule keeps fewer images | ## ankra registry storage retention rule list List the retention rules ```bash theme={null} ankra registry storage retention rule list [flags] ``` **Examples** ```bash theme={null} ankra registry storage retention rule list ankra registry storage retention rule list -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry storage retention rule remove Remove the retention rule for a pattern; the repositories it matched follow the organisation policy again. When that policy keeps fewer images than the rule did, it asks first; `--yes` skips the prompt. ```bash theme={null} ankra registry storage retention rule remove [flags] ``` **Examples** ```bash theme={null} ankra registry storage retention rule remove 'ankra-ci/**' ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `-y`, `--yes` | `false` | Skip the confirmation prompt when the organisation policy keeps fewer images | ## ankra registry storage retention run Start the retention cleanup now instead of at its daily time: images the policy does not keep are deleted. The space they held is freed at the registry's next garbage collection (weekly), not at once. ```bash theme={null} ankra registry storage retention run [flags] ``` **Examples** ```bash theme={null} ankra registry storage retention run ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry storage retention set Change the organisation retention policy: the one every repository without a rule follows. `--keep-days` keeps every image pushed in that many days (0 turns it off, so only the newest are kept); `--keep-latest` always keeps that many newest images of each repository (at least 1). A flag not passed keeps its current value. `--reset` goes back to the platform default. Rules are not touched. A change that keeps fewer images asks first, because what it no longer keeps is deleted at the next retention run; `--yes` skips the prompt. The change is made to the retention as it is stored when it is written: if someone else changes it between the read and the write, the platform refuses the write and the change is applied again to the new retention, once. ```bash theme={null} ankra registry storage retention set [flags] ``` **Examples** ```bash theme={null} ankra registry storage retention set --keep-days 14 ankra registry storage retention set --keep-days 7 --keep-latest 2 --yes ankra registry storage retention set --reset ``` **Flags** | Flag | Default | Description | | - | - | - | | `--keep-days` | `0` | Keep every image pushed in this many days (0 turns it off) | | `--keep-latest` | `0` | Always keep this many newest images of each repository (at least 1) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--reset` | `false` | Go back to the platform default policy | | `-y`, `--yes` | `false` | Skip the confirmation prompt when the change keeps fewer images | ## ankra registry storage retention show Show the image retention policy ```bash theme={null} ankra registry storage retention show [flags] ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra registry storage show Show the registry storage usage against the limit ```bash theme={null} ankra registry storage show [flags] ``` **Examples** ```bash theme={null} ankra registry storage show ankra registry storage show -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.