> ## 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 > Connect application environments, place a managed service on one of your clusters, size it and confirm the reviewed plan, then follow the installation in My services. **Closed beta.** Setting up a service is part of [Managed services](/concepts/managed-services), which is in closed beta and enabled per organisation on request. [Contact support](/platform/support) 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. *** ## 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](/platform/support). 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](/concepts/deployment-engines) supports. New clusters use it by default. A cluster that still deploys with ArgoCD can be [migrated](/concepts/deployment-engines#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. * **Every cluster involved has a data policy.** That means the cluster the service runs on and the clusters of the environments it connects to. See [Declare a data policy](#declare-a-data-policy). * **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. * **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](/guides/roles-and-access). *** ## Declare a data policy A data policy says where a cluster keeps data. In the new portal, open the cluster's **Settings** and find **Where managed services may keep data**. Choose **Declare data policy**, or **Change data policy** when the cluster already has one. 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. 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. 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. *** ## Set up the service In **Managed services**, open the **Catalogue** tab, choose the service and choose **Set up**. Catalogue cards also carry a **Set up** button. 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. You can add environments from several applications, up to 50. **Continue** stays disabled while the chosen environments keep data in different boundaries, or while your role cannot operate one of their clusters. An application that is not deployed yet offers no environments: deploy it first. **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. The page shows its region and data boundary. A cluster without a data policy offers **Declare a data policy**, and your choices are kept while you declare it. 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. A service's addresses resolve only inside its own cluster. Place it on the cluster your environments run on, unless you provide a network path between clusters yourself. **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](/reference/managed-services) 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. 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 an earlier service. A name stays taken once its setup is confirmed, even if the installation then fails. The form checks the characters as you type. The platform checks the rest when it prepares and confirms the review. ### 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 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. 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. | 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. A working connection from your application has not been verified. This is as far as a service goes today. | | **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 installation was released, and the record is kept as history. | Every service also reads **Readiness unverified**. Check that it answers before you rely on it: see [Check that the service answers](/guides/connect-to-a-managed-service#check-that-the-service-answers). *** ## Troubleshooting | What you see | Cause | Remedy | | - | - | - | | ` has no data policy yet.` | The service cluster or an environment's cluster has no data policy | [Declare one](#declare-a-data-policy), then continue | | `These environments keep data in different boundaries` | The chosen environments sit in more than one data boundary | Set up one service per data boundary | | `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](/concepts/deployment-engines#migrating-a-cluster-to-the-native-engine), or choose a native-engine cluster | | `This setup changed after you reviewed it, or its name is already used on that cluster.` | The plan changed, or the name is already taken on the service cluster | Choose another name and review again | | `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 | *** ## Next steps Find the addresses and credentials, and wire them into your application. Every setting of each service, with its range and default. What the services are, how they run, and their current limits. The native engine, and moving a cluster to it from ArgoCD.