> ## 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. # Set Up a Managed Service > Add a database, cache or queue from the application that will use it, or from the catalogue - connect its environments, place it on one of your clusters, size it and confirm the reviewed plan, then follow the installation. > [!WARNING] > > **Closed beta.** Setting up a service is part of [Managed services](https://docs.ankra.ai/concepts/managed-services.md), which is in closed beta and enabled per organisation on request. [Contact support](https://docs.ankra.ai/platform/support.md) to have it turned on for your organisation. Setting up a managed service takes four steps: **Connect**, **Place**, **Configure** and **Review**. The last step shows the plan Ankra prepared from your choices, and nothing is installed until you confirm it. The quickest way in is from the application that will use the service: [Start from your application](#start-from-your-application) opens the same four steps with the application and its environment already chosen, and brings you back to the application when you are done. You can also start from the catalogue in **Managed services**. *** ## Prerequisites Managed services are in the new Ankra portal. Choose **Managed services** in its sidebar, or open `/next/services` on your portal's address, for example `https://platform.ankra.app/next/services`. If the page says managed services are not offered to your organisation yet, [contact support](https://docs.ankra.ai/platform/support.md). Before you start, check the following: * **The service cluster uses the native deployment engine.** Services generate their credentials in the cluster, which only the [native engine](https://docs.ankra.ai/concepts/deployment-engines.md) supports. New clusters use it by default. A cluster that still deploys with ArgoCD can be [migrated](https://docs.ankra.ai/concepts/deployment-engines.md#migrating-a-cluster-to-the-native-engine). * **The service cluster has a default StorageClass.** Every service keeps its data on persistent volumes from the cluster's default StorageClass. * **The application is deployed.** Setup offers only the environments an application is actually deployed to, each one a namespace on a cluster. All environments that one service connects must be in the same data boundary. * **To be connected for you, the application runs on the service cluster.** Setup also accepts environments on other clusters, but Ankra delivers the service's connection only to environments on the cluster the service runs on. See [How your application receives the connection](https://docs.ankra.ai/guides/connect-to-a-managed-service.md#how-your-application-receives-the-connection). * **Your role allows it:** | Permission | Needed to | | - | - | | `applications.deploy` and `profiles.read` | Set up a service at all | | `clusters.operate` on each cluster involved | Connect an environment on that cluster, or place the service on it | | `clusters.write` on a cluster | Declare or change its data policy | | `applications.read` | See **My services** | The built-in `owner`, `admin` and `operator` roles hold all of them. See [Roles and access](https://docs.ankra.ai/guides/roles-and-access.md). *** ## Declare a data policy A data policy says where a cluster keeps data. It is optional: a cluster without one takes services in the default location, region and data boundary `unspecified`. Declare one when services must keep data within a boundary; see [Data policies](https://docs.ankra.ai/concepts/managed-services.md#data-policies) for what it then restricts. In the new portal, open the cluster's **Settings** and find **Where managed services may keep data**. **1. Open the policy** Choose **Declare data policy**, or **Change data policy** when the cluster already has one. **2. Enter the region and data boundary** Enter a **Region**, such as `eu-north`, and a **Data boundary**, such as `eu`. Both take lowercase letters, digits and single hyphens, start with a letter, and are at most 63 characters. **3. Choose whether services must stay on this cluster** Tick **Services bound to this cluster must run on this cluster only** if an application on this cluster may only use services running on the same cluster. **4. Review and confirm** Choose **Review policy**, read the summary, then **Confirm data policy**. The policy is your organisation's declaration. Ankra records who made it and when, and does not verify the location. A service already reviewed against an earlier policy needs a new review. *** ## Start from your application In the new Ankra portal, open the application. Its **Overview** has a **Services** card listing the managed services the application uses: each one's name, kind and package, which of the application's environments it serves, and how it is doing (deployment progress until it finishes, then its health and readiness). Services that need a look come first, and **My services** opens the full list for this application. **1. Choose what to add** Choose **Add a service** to pick from the catalogue, or one of the quick choices, such as **Add a database** or **Add a cache**. A quick choice goes straight to setting up the newest package of that kind. The card offers a quick choice only for a kind the catalogue has a package for that can be set up. **2. Set it up for the application** The setup page says which application and environment it is for, and **Connect** starts with that environment's namespaces chosen. Continue with the [four steps](#set-up-the-service) below. If the application is not deployed to that environment yet, Connect says so: deploy it there first. **3. Deploy the application** After you confirm, the service's page follows its deployment. Once the service is running, deploy the application to that environment: its next deploy connects it to the service, and its containers read the connection as environment variables such as `DATABASE_URL`. See [How your application receives the connection](https://docs.ankra.ai/guides/connect-to-a-managed-service.md#how-your-application-receives-the-connection). The application's other pages lead into the same flow, with the application and environment chosen: * **Settings › Secrets** offers **Connect a managed service**. * The deploy form offers **Add a managed service** under its secrets and dependencies. It opens in a new tab, so the deployment you are preparing stays open. Every one of these opens the same setup page, with the application and environment in its address (`?application=&environment=`). The card and the links appear only where managed services are offered to your organisation and your role may set one up. Anyone else is told to ask someone who can deploy applications. *** ## Set up the service **1. Open the package** From an application, **Add a service** or a quick choice brings you here: see [Start from your application](#start-from-your-application). From **Managed services**, open the **Catalogue** tab, choose the service and choose **Set up**. Catalogue cards also carry a **Set up** button. **2. Connect: choose the application environments** Find an application and tick the environments that will use the service. Each environment is listed as a namespace on a cluster, together with that cluster's data policy when it declares one. You can add environments from several applications, up to 100. When you came from an application, its environment is already ticked. **Continue** stays disabled while the chosen environments keep data in different boundaries, including a cluster that declares a policy beside one that does not, or while your role cannot operate one of their clusters. An application that is not deployed yet offers no environments: deploy it first. **3. Place: choose who runs it and where** **Your infrastructure** is how every service runs today: Ankra installs it on one of your clusters, and your team operates it. Choose the **Service cluster** from the clusters your environments run on. When the cluster declares a data policy, the page shows its region and data boundary. An environment that cannot use a service on the chosen cluster is listed with the reason before you continue. The usual reasons are a different data boundary, or a cluster that keeps its services local. > [!TIP] > > A service's addresses resolve only inside its own cluster, and Ankra connects only the environments on that cluster. Place it on the cluster your environments run on. An environment on another cluster needs a network path you provide and the values set by hand: see [Connect from another cluster](https://docs.ankra.ai/guides/connect-to-a-managed-service.md#connect-from-another-cluster). **4. Configure: name it and size it** **Service name** is suggested from the application and the package, for example `storefront-postgresql`. It must follow the [name rules](#service-name-rules). Each setting shows its range and default. A package with more than three settings keeps the rest under **More settings**. [Managed Service Settings](https://docs.ankra.ai/reference/managed-services.md) explains each one. Choose **Review setup**. This records the chosen environments as consumers of managed services and asks Ankra to prepare a plan. It installs nothing. **5. Review: confirm the plan** The plan lists the service name, the package and version, who operates it, the service cluster with its region and data boundary, every setting, and the connected environments. Choose **Confirm setup** before the review window ends, **10 minutes** after the plan was prepared. The page shows when that is. **Change choices** takes you back. If the window passes, **Review again** prepares a fresh plan with the same choices. A review waiting for confirmation is also listed under **My reviews**, where you can confirm it within its window. Each person can hold at most 20 reviews waiting for confirmation, and each organisation 100. ### Service name rules The name becomes the service's namespace and its stack name on the service cluster. It must: * be a DNS label: lowercase letters, digits and single hyphens, starting with a letter; * be at most **36 characters**; * not be `default`, and not start with `kube-`, `ankra`, `cnpg-system`, `cert-manager`, `ingress-nginx`, `argocd` or `flux-system`; * not already be used on that cluster, by a stack or by another service. A name stays taken from the moment its setup is confirmed, even if the installation then fails, until that service is [deleted](https://docs.ankra.ai/guides/delete-a-managed-service.md). The form checks the characters as you type. The platform checks the rest when it prepares and confirms the review. A name another service on the cluster holds is refused at both points: the page says `Another service on the service cluster already uses this name.` and flags the name until you change it. A stack of that name that no service holds is found only when Ankra installs the service, after you confirm, and the installation then needs attention. ### What confirming does Confirming asks Ankra to install the service. It does not verify that the service is ready or that your applications can reach it. After you confirm: 1. The service appears in **My services** and on the **Services** card of each application it serves, and its page opens with **Setup confirmed. Deployment submitted; readiness is not yet verified.** 2. For PostgreSQL, Ankra makes sure the cluster runs the CloudNativePG operator. It is installed once per cluster, as its own stack `cloudnative-pg` in the `cnpg-system` namespace. A cluster that already runs CloudNativePG, installed by Ankra or any other way, keeps its operator. The operator is shared by every PostgreSQL service on the cluster, so leave it in place while any of them run. 3. Ankra deploys the service as a stack named after the service, into a namespace of the same name. 4. Each environment on the service cluster receives the service's connection on the application's next deploy after the service is running. Once that environment is waiting for a deploy, the service's page offers **Deploy \**. The first PostgreSQL service on a cluster can take a few minutes longer while its operator comes up. *** ## Follow the installation Open **My services** and choose the service. **Deployment progress** shows where it stands, and **View cluster operations** opens the cluster's operations with the detail. Once Ankra has observed the deployed service, it also carries a **Health** badge in **My services**, and its page's **Service health** section shows what was observed: see [Health](https://docs.ankra.ai/concepts/managed-services.md#health). | Status | Meaning | | - | - | | **Installation requested** | Your request is saved. Deployment has not been confirmed yet. | | **Deployment in progress** | The deployment operation has not finished. | | **Verification needed** | The deployment finished. Ankra has not yet verified that a client can connect, and has not yet observed the service serving. | | **Running** | The deployment finished and Ankra observes the service serving in its cluster. Its readiness check has not passed yet, or has not run. | | **Deployed** | The deployment finished and the service passed its last readiness check: a client could connect. | | **Installation needs attention** | The installation request did not complete. Check the cluster's operations before trying again. | | **Deployment needs attention** | The deployment did not complete successfully. Check the cluster's operations for the next step. | | **Progress unavailable** | Ankra does not have enough current operation records to report progress. Your request is still saved. | | **Retired** | The service was [deleted](https://docs.ankra.ai/guides/delete-a-managed-service.md) and its name released. The record is kept as history. | While a deletion runs, **My services** shows the service as **Deleting** instead. Next to the progress, the page reads **Readiness unverified**: a finished deployment does not show that your application can connect. Check that the service answers before you rely on it: see [Check that the service answers](https://docs.ankra.ai/guides/connect-to-a-managed-service.md#check-that-the-service-answers). ### See the services an application uses The application's **Services** card lists them, and **My services** next to it opens the full list for that application. From the command line, give the application's name or id: ```bash theme={null} ankra services list --application ``` A service is listed when its reviewed plan names one of the application's namespaces as a consumer. The **Used by** column says which of the application's environments it serves, or the namespace where the application is not deployed yet. Retired services are left out unless you add `--include-released`. *** ## Troubleshooting | What you see | Cause | Remedy | | - | - | - | | ` is not deployed to yet.` | You came from an application whose environment has no deployment yet | Deploy the application to that environment, then add the service again | | `The environment this link names is not one of 's environments now.` | The link names an environment the application no longer has | Choose an environment in **Connect** | | `These environments keep data in different boundaries` | The chosen environments sit in more than one data boundary, or one cluster declares a data policy and another does not | Set up one service per data boundary, or declare the same boundary on each cluster | | `Services it uses must run on itself.` | That environment's cluster keeps its services local | Place the service on that cluster, or set up a separate service for it | | `Your role cannot operate ...` | You lack `clusters.operate` on that cluster | Remove the environment, or ask an administrator for access | | `The platform refused these choices.` | The service name breaks a [name rule](#service-name-rules), usually by being longer than 36 characters, or a setting is out of range | Shorten or change the name, check the settings, and review again | | `The setup could not be completed.` when preparing the review | Often a service cluster that deploys new stacks through ArgoCD | [Migrate the cluster to the native engine](https://docs.ankra.ai/concepts/deployment-engines.md#migrating-a-cluster-to-the-native-engine), or choose a native-engine cluster | | `Another service on the service cluster already uses this name.` | A service that has not been deleted holds the name on the service cluster | Choose another name in **Configure** (when confirming, **Choose another name** takes you there) and review again, or [delete the other service](https://docs.ankra.ai/guides/delete-a-managed-service.md) first | | `This setup changed after you reviewed it.` | Something in the plan changed after it was prepared | **Review again** to see the current plan | | `This review expired before it was confirmed.` | The 10-minute window passed | **Review again** | | `You have too many setup reviews waiting.` | 20 reviews of yours, or 100 in the organisation, are waiting | Confirm one in **My reviews**, or let them expire after 10 minutes | | `An application is no longer deployed in one of the chosen environments.` | The application was removed from that namespace | Remove the environment, or deploy the application again | | **Installation needs attention**, with `Ankra cannot currently tell whether the selected cluster runs this service's shared operator` | Ankra could not see whether the cluster runs CloudNativePG, so it did not risk installing a second operator | Make sure the cluster's agent is online and reporting. Then set the service up again under a new name, or [delete the service](https://docs.ankra.ai/guides/delete-a-managed-service.md) to release its name and set it up again under the same one | *** ## Next steps > **[Connect to a managed service](https://docs.ankra.ai/guides/connect-to-a-managed-service.md)** > > How your application receives the connection, and the variables it reads. > **[Delete a managed service](https://docs.ankra.ai/guides/delete-a-managed-service.md)** > > Remove a service and its data through a reviewed plan. > **[Managed service settings](https://docs.ankra.ai/reference/managed-services.md)** > > Every setting of each service, with its range and default. > **[Managed services](https://docs.ankra.ai/concepts/managed-services.md)** > > What the services are, how they run, their health and readiness, and their current limits. > **[Deployment engines](https://docs.ankra.ai/concepts/deployment-engines.md)** > > The native engine, and moving a cluster to it from ArgoCD. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.