> ## 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 services > Set up, inspect and retire managed services (PostgreSQL, Valkey, OpenSearch, ...) ## ankra services Set up, inspect and retire managed services: PostgreSQL, Valkey, OpenSearch, VictoriaMetrics, VictoriaLogs and the other engines in the service catalogue, run on your own cluster as reviewed, health-checked platform services. A service is set up in four steps: 1. Pick a package from the catalogue: ankra services packages list 2. Declare where the cluster is: ankra services policy set `--cluster` \ `--region` \ `--data-boundary` \ 3. Bind the application namespace that will use the service: ankra services consumers bind `--application` \ `--cluster` \ `--namespace` \ 4. Review and confirm the setup: ankra services setup \ `--package` postgresql `--cluster` \ `--consumer` \ Setup and retirement are two-step on the platform. A review is prepared first: the platform resolves a plan, stores it with a digest for ten minutes, and changes nothing. The plan is shown, and only confirming it by its digest sets the service up or removes it. Every confirmation asks first; `--yes` skips the question for scripts. Retiring a service deletes its data, so delete also needs `--acknowledge-data-loss`. 'ankra services list' and 'ankra services get \' show each service's deployment state, health, readiness (for PostgreSQL, a consumer-path canary logs in with the generated credentials) and connection: its endpoints and the Secret holding its credentials. Credential values are never shown; they stay in the cluster. **Examples** ```bash theme={null} ankra services packages list ankra services setup orders-db --package postgresql --cluster prod --consumer 5b1f0c7e-... ankra services list ankra services get orders-db ankra services delete orders-db --acknowledge-data-loss ``` ## ankra services consumers Bind, list and unbind consumers: the application namespaces a service is set up for. A consumer is one application's namespace on one cluster, with a stable id. Setup takes one or more consumer ids (`--consumer`), and the plan records each with the cluster policy it was resolved against. A binding normally resolves to the application's installation on that cluster; `--allow-planned` binds a namespace the application is not installed in yet. A binding a service still uses cannot be unbound until that service is retired. ## ankra services consumers bind Bind an application's namespace on a cluster as a service consumer and print its consumer id, which 'ankra services setup `--consumer`' takes. The cluster needs a placement policy first ('ankra services policy set'). The application must be installed in that namespace unless `--allow-planned` is given. A binding is created once per application, cluster and namespace; changing an existing one needs `--revision` with its current revision ('ankra services consumers list `--application` \' shows it); a setting not given on the command line keeps the binding's current value. Binding deploys nothing and delivers no credentials. ```bash theme={null} ankra services consumers bind [flags] ``` **Examples** ```bash theme={null} ankra services consumers bind --application orders --cluster prod --namespace orders ankra services consumers bind --application orders --cluster prod --namespace orders --allow-planned ``` **Flags** | Flag | Default | Description | | - | - | - | | `--allow-planned` | `false` | Bind even though the application is not installed in the namespace yet | | `--application` | | The application that will consume the service (name or id) | | `--cluster` | | The cluster the application runs on (name or id; default: the selected cluster) | | `--local-only` | `false` | The consumer may only use a service on its own cluster | | `--namespace` | | The application's namespace on that cluster | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--revision` | `0` | The current revision of the binding being changed (omit to create one) | ## ankra services consumers get Show a consumer binding resolved as setup would resolve it: the cluster's declared region and data boundary, the policy and binding revisions, and the application installation it binds (none for a planned binding). ```bash theme={null} ankra services consumers get [flags] ``` **Examples** ```bash theme={null} ankra services consumers get 5b1f0c7e-0d7a-4c55-a6f4-2f1f4a9b1c11 ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services consumers list List an application's consumer bindings as last saved: each binding's id (what setup's `--consumer` takes), cluster, namespace and revision. Bindings on clusters you cannot read are not listed. ```bash theme={null} ankra services consumers list [flags] ``` **Examples** ```bash theme={null} ankra services consumers list --application orders ``` **Flags** | Flag | Default | Description | | - | - | - | | `--application` | | The application (name or id) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services consumers unbind Remove a consumer binding: the application namespace stops being a consumer services can be set up for. Nothing is deployed or removed on any cluster. A binding a service still uses - one that has not been retired - is kept; retire the service first ('ankra services delete'). A setup review still pending that names the binding can no longer be confirmed. The platform removes a binding only at the revision you last read. Without `--revision` the current one is read from the binding. A binding whose application or cluster has since been removed can still be unbound, but it can no longer be read by id: pass `--revision` with the revision 'ankra services consumers list `--application` \' shows. Asks first; `--yes` skips the question. ```bash theme={null} ankra services consumers unbind [flags] ``` **Examples** ```bash theme={null} ankra services consumers unbind 5b1f0c7e-0d7a-4c55-a6f4-2f1f4a9b1c11 ankra services consumers unbind 5b1f0c7e-0d7a-4c55-a6f4-2f1f4a9b1c11 --revision 3 --yes ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--revision` | `0` | The binding's current revision (default: read from the binding) | | `-y`, `--yes` | `false` | Remove without asking | ## ankra services delete Retire a managed service, in two steps, deleting its data. First a retirement review is prepared: the platform resolves what retiring removes and keeps - the service's stack and its members, its namespace with everything in it (objects it did not create are listed), every volume claim with the reclaim policy that decides its data, the consumers it is disconnected from and the shared operators it keeps - and stores that plan with a digest for ten minutes. Preparing changes nothing on the cluster. The plan is shown, and the service is retired only when you confirm it: at the prompt, or with `--yes`. Retiring deletes the namespace, its volume claims and its Secrets, generated credentials included, and no export is offered; restore points stay in their backup vault under its retention. A volume whose reclaim policy is Retain keeps its data until someone removes it, and the settled retirement names it. So delete always needs `--acknowledge-data-loss`, before anything is prepared. A retirement review you prepared earlier that is still open (for example one whose answer was lost) is resumed instead of preparing another; `--new-review` prepares a fresh one. `--review-only` stops after the review and prints the command that confirms it. `--wait` follows the retirement until it settles. ```bash theme={null} ankra services delete [flags] ``` **Examples** ```bash theme={null} ankra services delete orders-db --acknowledge-data-loss ankra services delete orders-db --acknowledge-data-loss --review-only ankra services delete orders-db --cluster prod --acknowledge-data-loss --yes --wait ``` **Flags** | Flag | Default | Description | | - | - | - | | `--acknowledge-data-loss` | `false` | Acknowledge that retiring deletes the service's data (required) | | `--cluster` | | The cluster the service runs on, when its name is not unique (name or id) | | `--new-review` | `false` | Prepare a new retirement review even if one of yours is still open | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--review-only` | `false` | Prepare and show the retirement review, but do not confirm it | | `--timeout` | `30m0s` | How long `--wait` follows the retirement | | `--wait` | `false` | Follow the retirement until it settles; exit non-zero unless it settled retired | | `-y`, `--yes` | `false` | Confirm the reviewed retirement without asking | ## ankra services get Show one managed service by name or id: its package, cluster and location, its deployment state, health and readiness with the evidence behind each, how it is reached (endpoints and the Secret holding its credentials), the consumers it was set up for, and the latest retirement if one was confirmed. The connection names the Secret and its keys only. Credential values are never shown here; they stay in the service's namespace on the cluster. A name that runs on more than one cluster needs `--cluster`. ```bash theme={null} ankra services get [flags] ``` **Examples** ```bash theme={null} ankra services get orders-db ankra services get orders-db --cluster prod -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `--cluster` | | The cluster the service runs on, when its name is not unique (name or id) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services list List the organisation's managed services: each with its cluster, package, deployment state, health and readiness. Deployment state is the recorded operation progress (accepted, deploying, verification\_pending, deployment\_failed, ...), not current health. Health is what the platform last observed from the cluster (serving, progressing, degraded, unknown). Readiness says whether a consumer can use the service: for PostgreSQL a canary logs in with the generated credentials (ready, verifying, degraded, stale); engines without a canary read unverified. `--application` keeps the services an application uses: those whose reviewed plan names one of the application's namespaces as a consumer. The application is given by name or id, and a Used by column says which of its environments each service serves (or the namespace, where the application is not deployed yet). Retired services keep their record; `--include-released` lists them too. ```bash theme={null} ankra services list [flags] ``` **Examples** ```bash theme={null} ankra services list ankra services list --cluster prod ankra services list --application storefront ankra services list -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `--application` | | Only services this application uses (name or id) | | `--cluster` | | Only services on this cluster (name or id) | | `--include-released` | `false` | Also list retired services | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services packages Browse the service catalogue: the immutable package versions this organisation may set up, Ankra's own (PostgreSQL, Valkey, OpenSearch, ...), any shared with it, and its own. 'init' and 'publish' turn one of your stack profiles into a package that connects to applications like Ankra's own. Being listed is not being deployable: setup re-checks access and the pinned profile when the review is prepared. ## ankra services packages collisions Read a running demo of a stack profile and check whether two services set up from a package built on it could run on the same cluster: a cluster-scoped object (a ClusterRole, a CRD, a webhook, a StorageClass) whose name does not change with the service's namespace would be claimed by both. It also lists the Services and Secrets whose names do change with it, which a package's connection cannot name as fixed values. Exits 0 only when every kind was read and nothing collides; collisions exit 1 with the objects named, and a check that could not read everything (the verdict unknown) exits 1 with the reason, so it never reads as no collision. ```bash theme={null} ankra services packages collisions [flags] ``` **Examples** ```bash theme={null} ankra services packages collisions --profile --demo ``` **Flags** | Flag | Default | Description | | - | - | - | | `--demo` | | id of the running demo (its workspace id) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--profile` | | id of the stack profile the demo runs | ## ankra services packages get Show a package version's contract: the modes it can run in, the parameters a setup may choose (with their bounds and defaults), the secret inputs it needs and the outputs it publishes. The package is a name, name\@version or id. ```bash theme={null} ankra services packages get [flags] ``` **Examples** ```bash theme={null} ankra services packages get postgresql ankra services packages get postgresql@1.0.0 -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services packages init Write a service package (contract schema 2) for one version of a stack profile this organisation owns, so the services it deploys can be set up from the catalogue and connected to applications like Ankra's own. The skeleton pins the profile version and names the protocol consumers speak (nats, opensearch, postgres, redis, s3, victorialogs, victoriametrics). Before publishing, fill in what only you know about the engine the profile deploys: ```text theme={null} connection.endpoints[0].service the Service consumers connect to connection.endpoints[0].port its port connection.secret_name the Secret holding its credentials connection.fields which key of that Secret holds each field ``` Publication refuses the package until these are filled in. To make a service from one Helm chart rather than a stack profile, pass `--addon` with `--registry` and `--chart-version` instead of `--profile` and `--profile-version`: init first creates a stack profile holding that chart alone (installed into a namespace named after each service), then writes the package pinned to it. With `--generate-secret`, that profile also generates the service's credentials: a Secret of that name in each service's namespace, created on the first install and kept unchanged across upgrades. Name its keys with `--generate-key`: "password" for a random value, "password:48" for a random value of 48 characters. Random values are generated in the cluster and Ankra never sees them. "username=app" sets a fixed value, which is stored in the profile and visible on the command line, so use it only for names (a user or database name), never for a password. Point the chart at the Secret in `--values` (most charts take an existing-secret setting); the package's connection names it already. ```bash theme={null} ankra services packages init [flags] ``` **Examples** ```bash theme={null} ankra services packages init --profile --profile-version \ --name dragonfly-cache --protocol redis -f dragonfly-cache.json ankra services packages init --addon dragonfly --registry dragonfly --chart-version 1.2.0 \ --values dragonfly-values.yaml --name dragonfly-cache --protocol redis -f dragonfly-cache.json ankra services packages init --addon postgresql --registry bitnami --chart-version 16.4.2 \ --generate-secret orders-db-auth --generate-key username=app --generate-key password \ --values orders-db-values.yaml --name orders-db --protocol postgres -f orders-db.json ankra services packages publish -f dragonfly-cache.json ``` **Flags** | Flag | Default | Description | | - | - | - | | `--addon` | | make the service from this Helm chart instead of a stack profile | | `--capability` | | what the package provides (defaults to the protocol's usual one) | | `--chart-version` | | the chart version `--addon` pins | | `-f`, `--file` | | write the skeleton to this file instead of standard output | | `--generate-key` | `[]` | a key of `--generate-secret`: key (random), key:length (random of that length) or key=value (a fixed, non-secret name such as a user); repeatable | | `--generate-secret` | | with `--addon`, a Secret of this name the profile generates in each service's namespace | | `--name` | | package name (a DNS label, for example dragonfly-cache) | | `--profile` | | id of the stack profile the package deploys | | `--profile-version` | | id of the profile version to pin | | `--protocol` | | wire protocol consumers speak: nats, opensearch, postgres, redis, s3, victorialogs, victoriametrics | | `--registry` | | the Helm registry `--addon` comes from (as named in Ankra) | | `--values` | | a values file for the `--addon` chart | | `--version` | `1.0.0` | package version (semantic version) | ## ankra services packages list List the service packages this organisation can set up: each version's name, capability (database, cache, search, metrics, logs, ...), publisher and id. Pass the name, name\@version or id to 'ankra services setup `--package`'. ```bash theme={null} ankra services packages list [flags] ``` **Examples** ```bash theme={null} ankra services packages list ankra services packages list -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services packages probe Probe the connection a package file declares against a running demo of its stack profile, before publishing: Ankra runs the protocol's readiness canary in the demo's namespace, the same one that verifies a published package. Without `--wait` the probe is only queued. With `--wait` the command follows it and exits 0 only when the verdict is passed; failed and unknown (the canary could not run, or the demo stopped) exit 1 with the reason, and a probe still running when `--timeout` ends exits 5. ```bash theme={null} ankra services packages probe [flags] ``` **Examples** ```bash theme={null} ankra services packages probe --profile --demo -f dragonfly-cache.json --wait ``` **Flags** | Flag | Default | Description | | - | - | - | | `--demo` | | id of the running demo (its workspace id) | | `-f`, `--file` | | package file whose connection is probed (- for standard input) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--profile` | | id of the stack profile the demo runs | | `--timeout` | `10m0s` | how long `--wait` follows the probe | | `--wait` | `false` | follow the probe to its verdict; exit 0 only if it passed | ## ankra services packages propose Read a running demo of a stack profile on the organisation's staging cluster and propose the connection blocks a service package made from that profile could declare: one per Service port speaking a protocol Ankra connects applications to, each field mapped to a key of the Secret that holds the most of the credentials. Only Service ports and Secret key names are read, never Secret values, and nothing is tried: probe a proposal with 'ankra services packages probe' before publishing. With -f, the best complete proposal is written into that package file (made by 'ankra services packages init'), replacing its connection. A demo whose namespace could not be observed exits 1 with the reason, so an unobserved namespace is never read as one with nothing to propose. ```bash theme={null} ankra services packages propose [flags] ``` **Examples** ```bash theme={null} ankra services packages propose --profile --demo ankra services packages propose --profile --demo -f dragonfly-cache.json ``` **Flags** | Flag | Default | Description | | - | - | - | | `--demo` | | id of the running demo (its workspace id) | | `-f`, `--file` | | write the best complete proposal into this package file | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--profile` | | id of the stack profile the demo runs | ## ankra services packages publish Publish a service package version from its contract document. The document is sent as written; the platform validates it and refuses it with the path that failed. A published version is immutable: publishing the same name and version again with identical content returns it, and different content is refused, so a change needs a new version. Publishing makes the package available to set up in this organisation; it does not make Ankra operate it or qualify it. ```bash theme={null} ankra services packages publish [flags] ``` **Examples** ```bash theme={null} ankra services packages publish -f dragonfly-cache.json ankra services packages init ... | ankra services packages publish -f - ``` **Flags** | Flag | Default | Description | | - | - | - | | `-f`, `--file` | | package document to publish, or - for standard input | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services policy Read or declare a cluster's service placement policy: the physical region it runs in, the data boundary its data may stay within, and whether services on it are local-only. This is the organisation's declaration, not verified location evidence. Setup refuses a cluster without one, and a setup's region and data boundary default to it. ## ankra services policy get Show a cluster's service placement policy ```bash theme={null} ankra services policy get [flags] ``` **Examples** ```bash theme={null} ankra services policy get --cluster prod ``` **Flags** | Flag | Default | Description | | - | - | - | | `--cluster` | | The cluster (name or id; default: the selected cluster) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services policy set Declare a cluster's service placement policy: the physical region it runs in (for example eu-north-1), the data boundary its data may stay within (for example eu) and whether services on it are local-only. The first declaration creates the policy. Replacing one needs `--revision` with the revision you reviewed ('ankra services policy get' shows it), so two people cannot overwrite each other's declaration unseen. Nothing is deployed. ```bash theme={null} ankra services policy set [flags] ``` **Examples** ```bash theme={null} ankra services policy set --cluster prod --region eu-north-1 --data-boundary eu ankra services policy set --cluster prod --region eu-north-1 --data-boundary eu --local-only --revision 1 ``` **Flags** | Flag | Default | Description | | - | - | - | | `--cluster` | | The cluster (name or id; default: the selected cluster) | | `--data-boundary` | | Boundary the data may stay within, for example eu | | `--local-only` | `false` | Services on this cluster serve only consumers on this cluster | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--region` | | Physical region the cluster runs in, for example eu-north-1 | | `--revision` | `0` | The current revision of the policy being replaced (omit to create one) | ## ankra services retirements List, read and confirm your own retirements of a service. 'ankra services delete' prepares a retirement review and confirms it. A review that was prepared with `--review-only`, declined at the prompt or whose answer was lost stays pending for ten minutes: 'list `--state` pending' finds it and 'confirm' confirms it instead of preparing another (each person may hold 10 open retirements). 'get' follows a confirmed retirement and, once it settled, shows what became of every volume. ## ankra services retirements confirm Confirm one of your pending retirement reviews by its digest. This is the step that retires the service and deletes its data, so it needs `--acknowledge-data-loss` as well as a yes at the prompt (or `--yes`). `--digest` names the digest you reviewed ('delete `--review-only`' prints it); a review whose digest differs is refused, because it is not the plan you saw. Without `--digest` the digest of the review shown is the one confirmed. ```bash theme={null} ankra services retirements confirm [flags] ``` **Examples** ```bash theme={null} ankra services retirements confirm orders-db 7d3c1f0a-5b2e-4c9d-8e1f-0a2b3c4d5e6f --digest sha256:9f2c... --acknowledge-data-loss ankra services retirements confirm orders-db 7d3c1f0a-5b2e-4c9d-8e1f-0a2b3c4d5e6f --acknowledge-data-loss --yes --wait ``` **Flags** | Flag | Default | Description | | - | - | - | | `--acknowledge-data-loss` | `false` | Acknowledge that retiring deletes the service's data (required) | | `--cluster` | | The cluster the service runs on, when its name is not unique (name or id) | | `--digest` | | The digest you reviewed (sha256:...); refused if the review's differs | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--timeout` | `30m0s` | How long `--wait` follows the retirement | | `--wait` | `false` | Follow the retirement until it settles; exit non-zero unless it settled retired | | `-y`, `--yes` | `false` | Confirm the reviewed retirement without asking | ## ankra services retirements get Show one of your retirements: the plan, its progress and what became of the volumes ```bash theme={null} ankra services retirements get [flags] ``` **Examples** ```bash theme={null} ankra services retirements get orders-db 7d3c1f0a-5b2e-4c9d-8e1f-0a2b3c4d5e6f ankra services retirements get orders-db 7d3c1f0a-5b2e-4c9d-8e1f-0a2b3c4d5e6f -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `--cluster` | | The cluster the service runs on, when its name is not unique (name or id) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services retirements list List your retirements of a service, newest first ```bash theme={null} ankra services retirements list [flags] ``` **Examples** ```bash theme={null} ankra services retirements list orders-db ankra services retirements list orders-db --state pending ``` **Flags** | Flag | Default | Description | | - | - | - | | `--cluster` | | The cluster the service runs on, when its name is not unique (name or id) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--state` | | Only retirements in this state: pending, expired, in\_progress or settled | ## ankra services reviews List, read and confirm your own setup reviews. 'ankra services setup' prepares a review and confirms it. A review that was prepared with `--review-only`, declined at the prompt, or whose answer was lost stays pending for ten minutes: find it here and confirm it instead of preparing another (each person may hold 20 open reviews). An expired review needs a new setup. Reviews are personal: nobody else sees or confirms yours. ## ankra services reviews confirm Confirm one of your pending setup reviews by its digest. This is the step that sets the service up. The review is shown and confirmed after a yes at the prompt, or with `--yes`. `--digest` names the digest you reviewed (setup `--review-only` prints it); a review whose digest differs is refused, because it is not the plan you saw. Without `--digest` the digest of the review shown is the one confirmed. A review that already expired needs a new 'ankra services setup'. ```bash theme={null} ankra services reviews confirm [flags] ``` **Examples** ```bash theme={null} ankra services reviews confirm 0b6f2a8e-3a1c-4b8e-9a51-2c7d4f1e9a20 --digest sha256:4e86... ankra services reviews confirm 0b6f2a8e-3a1c-4b8e-9a51-2c7d4f1e9a20 --digest sha256:4e86... --yes ``` **Flags** | Flag | Default | Description | | - | - | - | | `--digest` | | The digest you reviewed (sha256:...); refused if the review's differs | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `-y`, `--yes` | `false` | Confirm without asking | ## ankra services reviews get Show one of your setup reviews ```bash theme={null} ankra services reviews get [flags] ``` **Examples** ```bash theme={null} ankra services reviews get 0b6f2a8e-3a1c-4b8e-9a51-2c7d4f1e9a20 ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra services reviews list List your setup reviews, newest first ```bash theme={null} ankra services reviews list [flags] ``` **Examples** ```bash theme={null} ankra services reviews list ankra services reviews list --state pending ``` **Flags** | Flag | Default | Description | | - | - | - | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--state` | | Only reviews in this state: pending, expired or confirmed | ## ankra services setup Set up a managed service on a cluster, in two steps. First a review is prepared: the platform resolves the package, the cluster's placement policy and every consumer, and stores the plan with a digest for ten minutes. Preparing changes nothing. The plan is shown, and the service is set up only when you confirm it: at the prompt, or with `--yes`. The confirmation carries the digest of the plan you saw, so a plan that changed in between is refused rather than deployed. `--review-only` stops after the review and prints the command that confirms it ('ankra services reviews confirm \ `--digest` \'), for a person or a pipeline that approves separately. The name becomes the service's namespace on the cluster: lower-case letters, digits and single hyphens, starting with a letter. Ankra's engines also need it to be at most 36 characters and not a system namespace (default, kube-*, ankra*, cert-manager, ...); the platform refuses any other name when the review is prepared, before anything is stored. Every setup needs at least one consumer (`--consumer`, from 'ankra services consumers bind'). The region and data boundary default to the cluster's placement policy. Parameters (`--param`) default to the package's defaults; 'ankra services packages get \' lists them with their bounds. Confirming starts the deployment; it is not proof that the service is ready. Follow it with 'ankra services get \'. ```bash theme={null} ankra services setup [flags] ``` **Examples** ```bash theme={null} ankra services setup orders-db --package postgresql --cluster prod --consumer 5b1f0c7e-0d7a-4c55-a6f4-2f1f4a9b1c11 ankra services setup orders-db --package postgresql@1.0.0 --consumer --param storage_gib=20 --param instances=3 ankra services setup orders-db --package postgresql --consumer --review-only ankra services setup orders-db --package postgresql --consumer --yes -o json ``` **Flags** | Flag | Default | Description | | - | - | - | | `--cluster` | | The cluster to run the service on (name or id; default: the selected cluster) | | `--consumer` | `[]` | Consumer binding id the service is for (repeatable; 'ankra services consumers bind') | | `--data-boundary` | | Data boundary (default: the cluster's placement policy) | | `--mode` | `customer` | Operating mode: customer (runs on your cluster) or existing | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--package` | | The package to set up: name, name\@version or id ('ankra services packages list') | | `--param` | `[]` | Package parameter as name=value (repeatable) | | `--region` | | Physical region (default: the cluster's placement policy) | | `--review-only` | `false` | Prepare and show the review, but do not confirm it | | `--secret-reference` | `[]` | Secret input as name=\ (repeatable); values are never accepted | | `-y`, `--yes` | `false` | Confirm the reviewed plan without asking | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.