> ## 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.
# Managed Services
> Run PostgreSQL, Valkey, NATS, OpenSearch, S3-compatible object storage, VictoriaLogs and VictoriaMetrics on your own cluster from a package Ankra publishes, and connect them to your applications.
**Closed beta.** Managed services are in closed beta. They are part of the new Ankra portal and are enabled per organisation on request. Ankra does not verify that a service is ready yet, so check it yourself before you rely on it. [Contact support](/platform/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 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 under **Managed services**.
## 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](/reference/managed-services) 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.
* **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.
* **Cluster-internal only.** Nothing is exposed outside the cluster. Applications reach the service at fixed in-cluster addresses; see [Connect to a Managed Service](/guides/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](/concepts/deployment-engines) evaluates. On an ArgoCD cluster every sync would generate new credentials under running applications, so Ankra only places services on native-engine clusters.
## Data policies
Every cluster a service touches needs a **data policy**: the region the cluster keeps data in and its data boundary. That covers the cluster the service runs on and the clusters of the application environments it connects to. Your organisation declares the policy in the cluster's settings. Ankra records who declared it and does not verify the location.
The policy decides where a service may run:
* One service connects only environments within one data boundary. Environments in two boundaries need two services.
* A cluster can declare that services bound to it must run on that cluster only.
## Limits and good to know
* **Readiness is not verified.** When the deployment finishes, a service shows **Verification needed**, and that is as far as it goes today. A PostgreSQL service can report its deployment finished 30 to 100 seconds before the database accepts connections.
* **Credentials are not delivered to your applications.** Ankra shows where the credentials are, and applications in other namespaces must be given the values by you. Ankra will deliver credentials into application environments in a later release.
* **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, recovering or deleting a service from **Managed services** is not available yet.
* **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. To create an OpenSearch service again under a name you used before on the same cluster, delete the old service's namespace first: the old data volume rejects the new password.
* **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.
**Removing a SeaweedFS service's stack deletes its data immediately.** Its volume is released with the stack, and every object in it goes at once. Export anything you need first.
## Related
Prerequisites, the four setup steps, and following the installation.
Addresses, credential Secrets, and wiring them into an application.
Every setting of each service, with its range and default.
The applications whose environments use a service.