Skip to main content
Closed beta. Setting up a service is part of Managed services, which is in closed beta and enabled per organisation on request. Contact 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. The quickest way in is from the application that will use the service: 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. 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 supports. New clusters use it by default. A cluster that still deploys with ArgoCD can be migrated.
  • 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.
  • Your role allows it:
The built-in owner, admin and operator roles hold all of them. See Roles and access.

​
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 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 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.
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=<application-id>&environment=<environment-id>). 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. 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.
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.
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.Each setting shows its range and default. A package with more than three settings keeps the rest under More settings. Managed Service Settings 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.
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 <application>.
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. 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.

​
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:
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

​
Next steps

Connect to a managed service

How your application receives the connection, and the variables it reads.

Delete a managed service

Remove a service and its data through a reviewed plan.

Managed service settings

Every setting of each service, with its range and default.

Managed services

What the services are, how they run, their health and readiness, and their current limits.

Deployment engines

The native engine, and moving a cluster to it from ArgoCD.