Managed Services

Closed beta. Managed services are in closed beta. They are part of the new Ankra portal and are enabled per organisation on request. Contact support to have managed services turned on for your organisation.

A managed service is a backing service your applications use, such as a database, a cache or a queue, set up from a package Ankra publishes. You add one from the application that will use it, or from the catalogue. You choose the application environments that will use it, the cluster it runs on and its size. Ankra prepares a plan from those choices, and nothing is installed until you confirm it. Ankra then installs the service on your cluster and shows its progress, its health and how to connect to it under Managed services and on the Services card of each application it serves. An application on the same cluster receives the service’s connection as environment variables on its next deploy. When you no longer need a service, you delete it through a reviewed plan. While managed services are in the pilot, Ankra charges nothing for them. Their running time and storage are recorded as usage.

The services

Ankra publishes seven services, each built on an open-source engine:

Service	Provides	Engine	Licence
`postgresql`	Database	PostgreSQL 18.6, run by the CloudNativePG operator	PostgreSQL Licence (operator: Apache-2.0)
`valkey`	Cache	Valkey 9.1	BSD-3-Clause
`nats`	Queue	NATS 2.15 with JetStream	Apache-2.0
`opensearch`	Search	OpenSearch 3.9	Apache-2.0
`seaweedfs`	Object storage (S3 API)	SeaweedFS 4.48	Apache-2.0
`victoria-logs`	Logs	VictoriaLogs 1.52	Apache-2.0
`victoria-metrics`	Metrics	VictoriaMetrics 1.153	Apache-2.0

Managed Service Settings lists every setting of each one.

Who runs it

Every service in the catalogue runs on Your infrastructure: Ankra installs it on one of your clusters, and your team operates it. You own the cluster, the service’s availability and the cost of the capacity it uses. Ankra supplies the package, installs the plan you confirmed and keeps a record of the installation. Ankra-hosted services, which Ankra would run for you, are not available yet.

How a service runs

One stack, one namespace. Each service is deployed as a stack named after the service, into a namespace of the same name. Several services can share a cluster, including several of the same kind.
The service owns its stack. Deleting the stack on its own is refused. To remove the service, delete it: that removes the stack and then deletes the namespace with its data, after you review the plan.
Credentials are generated in the cluster. When a service is first installed, it generates its own password or keys and keeps them in a Kubernetes Secret in its namespace. Every later apply reuses them. Ankra never sees or stores the values, and deleting the service deletes them with its namespace.
Cluster-internal only. Nothing is exposed outside the cluster. Applications reach the service at fixed in-cluster addresses.
Connections are delivered inside the cluster. Each application environment the service was set up for, on the service’s cluster, receives a <service>-connection Secret in its own namespace on its next deploy, copied in the cluster from the service’s credentials Secret, and its workloads read it as environment variables such as DATABASE_URL. Ankra never sees the values. See Connect to a Managed Service.
Native deployment engine. The credentials are generated with a Helm lookup against the live cluster, which only Ankra’s native deployment engine evaluates. On an ArgoCD cluster every sync would generate new credentials under running applications, so Ankra only places services on native-engine clusters.

Health and readiness

Ankra reports two things about a running service, and they answer different questions: whether it is running as planned (health), and whether a client can connect to it (readiness).

Health

Ankra observes each service about once a minute from its own synced view of the service’s cluster: the service’s workload against the size you chose, the Kubernetes Service its addresses name, the credentials Secret with every key the connection details list, and the stack that owns it. It never reads the Secret’s values. Each observation stands for five minutes. Health checks lists what is checked for each service.

Health	In the portal	Meaning
`serving`	Serving	Every check passed.
`progressing`	Not serving yet	A check has not passed while the deployment is still being applied, or within the first minutes after it finished: 10 minutes for PostgreSQL and OpenSearch, 5 for the other services.
`degraded`	Service degraded	A check failed after that window, a member of the stack failed to apply or is being removed, or the stack that owns the service is gone or being removed. The portal shows the reason.
`unknown`	Health unknown	Nothing failed, but Ankra could not see enough of the cluster to judge: the cluster’s agent is offline, or Ankra’s view of a resource type on the cluster is more than 15 minutes old. An observation older than five minutes also reads unknown.

Health describes the running service, not the operation that deployed it: a failed deployment whose workloads all run reads serving, and one that left a workload missing reads degraded at once. A cluster that is offline reads unknown, never degraded. In the portal, each service in My services carries a Health badge, and the service’s page has a Service health section with the state, when it was observed and what decided it. Until Ankra has observed the service, the section reads Not observed. Health is not shown for a deleted service or while a service is being deleted.

Readiness

Health does not prove that your applications can connect. A serving PostgreSQL service has a ready primary and its credentials Secret, but that does not show a client can reach it and log in. Readiness does. Ankra checks readiness for every service it publishes, about every five minutes. The cluster’s agent starts a short-lived pod in the service’s namespace that connects to the address the service publishes, as a client would, with the credentials taken from the service’s credentials Secret by reference, and does one small round trip:

Service	What the check does
PostgreSQL	Connects to the read-write address as `app` and runs `SELECT 1`.
Valkey	Sends `PING`, then sets a key with a 60-second expiry, reads it back and deletes it.
NATS	Answers a request on a check subject from one connection and sends it from another, so a message makes the round trip through the server.
OpenSearch	Over TLS, trusting the service’s own CA: cluster health must be green or yellow, then it writes, reads and deletes one document in the hidden index `.ankra-canary`.
S3-compatible object storage	Writes, reads and deletes one object in the bucket `ankra-canary`, creating the bucket when it is missing.
VictoriaLogs	Writes one log line to the stream `{ankra_canary="readiness"}` and reads it back.
VictoriaMetrics	Imports one sample of `ankra_canary_probe`, reads it back and deletes the series.

Everything a check writes is its own, named after the check run, and deleted in the same run. The one exception is the VictoriaLogs line: VictoriaLogs cannot delete single lines, so it stays in the ankra_canary stream until your retention removes it. A query that selects your own streams never sees it. The credentials never leave the cluster, and Ankra keeps no log of the check. A result stands for 15 minutes.

Readiness	Meaning
`verifying`	No check has passed yet. None has run, or the latest failed or could not run while the service was still deploying, or within the grace window after its deployment finished: 10 minutes for PostgreSQL and OpenSearch, 5 for the other services.
`ready`	A check passed within the last 15 minutes.
`degraded`	A check ran and failed after the service had its chance to start. Once a check has passed, a failure reads degraded straight away.
`stale`	Readiness cannot be established right now. The check could not run - no agent, the cluster unavailable, or the pod refused or not finishing - or the last result is more than 15 minutes old. A check that could not run never reads as a failure, and the last result stands until it expires.
`unverified`	No check covers the service, or the cluster’s agent is too old to run it. For any service other than PostgreSQL, the agent must be recent enough to run the check: until it is, the service reads unverified and `readiness_check.reason` says to upgrade the agent.

Readiness is reported on the service in the API, as readiness and readiness_check on Get a managed service instance. The portal shows it on the service’s page and in My services: Ready, Verifying, Not ready (degraded), Not checked recently (stale) or Not verified (unverified). While a service reads unverified, check it yourself before you rely on it: see Check that the service answers.

Data policies

A data policy declares the region a cluster keeps data in and its data boundary. It is optional: you can set up services without one. Declare a policy when services must keep data within a boundary. Your organisation declares it in the cluster’s settings. Ankra records who declared it and does not verify the location. A cluster without a declared policy reads region and data boundary unspecified. That boundary is shared by every cluster without a policy, and cannot be declared by hand. Once a cluster declares a policy, it decides where a service may run:

One service connects only environments within one data boundary. Environments in two boundaries need two services. A cluster that declares a policy and one that does not are in different boundaries, so one service cannot serve both.
A cluster can declare that services bound to it must run on that cluster only.

A plan records the policy it was reviewed against. A review prepared before a cluster declares or changes its policy needs a new review.

Limits and good to know

A finished deployment is not yet a ready service. A PostgreSQL service can report its deployment finished 30 to 100 seconds before the database accepts connections; any service’s readiness reads verifying until a check passes.
Readiness checks need a pod they can start. The check pods pull their images from Docker Hub (postgres:16-alpine for PostgreSQL, valkey/valkey, natsio/nats-box and curlimages/curl for the others); a cluster that cannot pull the image in time cannot run the check, and readiness then reads stale. The PostgreSQL check pod sets no security context, so a namespace that enforces the restricted Pod Security Standard refuses it. The other check pods run as non-root with every capability dropped and a read-only root filesystem. On a cluster whose DNS domain is not cluster.local the checks fail, as the published addresses do.
Connections are delivered within one cluster, on a deploy. An application environment receives a service’s connection on its next deploy after the service is running, not when the service is set up. An application on another cluster than the service is not connected for you: give it the values yourself, as in Connect from another cluster.
No backups. Ankra does not back these services up yet. Do not keep data you cannot recreate in them without a backup of your own.
Settings are fixed after setup. Changing, upgrading or recovering a service from Managed services is not available yet. You can delete a service and set it up again, which starts it with new credentials and none of its data.
NATS runs a single server. The nats package has no clustered option yet.
OpenSearch runs a single node. An index created with replicas stays yellow.
SeaweedFS keeps its data on one volume. It runs as a single pod and is unavailable while that pod restarts, which happens once, for about 40 seconds, the first time Ankra reconciles it after installation.

Deleting a service deletes its data. Its namespace is deleted with every volume claim and Secret in it, and no export is made first. A SeaweedFS service’s volume goes with its stack, the first thing a deletion removes, so its objects can be gone even when the deletion then stops short. Export anything you need first. See Delete a Managed Service.

Set up a managed service

Prerequisites, the four setup steps, and following the installation.

Connect to a managed service

Addresses, credential Secrets, and wiring them into an application.

Delete a managed service

Review what is removed and kept, confirm, and follow the deletion.