> ## 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 Service Settings > Every setting of the seven Ankra managed services, with its range, default and unit, and what it changes in the running service - and what Ankra checks for each service's health and readiness. > [!WARNING] > > **Closed beta.** These settings belong to [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. You choose these settings when you [set up a service](https://docs.ankra.ai/guides/set-up-a-managed-service.md). Each one is a whole number within its range, and a field left empty takes the default. Changing a running service's settings from **Managed services** is not available yet, so size it for what you need from the start. Three rules hold for every service: * `memory_mib` is both the memory request and the limit, so the service is capped at it. * `cpu_millicores` is a CPU request, where 1000 is one core. CPU is not capped. * `storage_gib` is the size of each volume, taken from the cluster's default StorageClass. A volume never shrinks, and it can only grow where the StorageClass allows volume expansion. ## PostgreSQL Package `postgresql` 1.0.0: PostgreSQL 18.6, run by the CloudNativePG operator. | Setting | Range | Default | What it changes | | - | - | - | - | | `instances` | 1 to 3 | 1 | One primary plus `instances - 1` streaming replicas, spread across nodes where the cluster has more than one. 1 is a single database with no failover; 3 survives the loss of one node, with automatic failover. Each instance has its own volume. | | `storage_gib` | 1 to 1000 GiB | 10 | Size of each instance's data volume. | | `memory_mib` | 256 to 16384 MiB | 512 | Memory for each instance. PostgreSQL's `shared_buffers` stays at its 128 MB default, so the rest serves as file cache and per-connection working memory. | | `cpu_millicores` | 100 to 8000 | 250 | CPU request for each instance. | With one instance, a voluntary drain of the database's node waits until you add instances: the operator's PodDisruptionBudget holds it, rather than moving the only copy of the data. ## Valkey Package `valkey` 1.0.0: Valkey 9.1. | Setting | Range | Default | What it changes | | - | - | - | - | | `replicas` | 0 to 2 | 0 | Read-only replicas of the primary, served through the read-replicas address. 0 is a single primary. Replicas add read capacity and a warm copy of the data, but they do not take over writes while the primary is down. | | `memory_mib` | 128 to 16384 MiB | 256 | Memory for each pod. The cache holds at most 60% of it, then evicts the least recently used keys. | | `storage_gib` | 1 to 100 GiB | 2 | Size of each pod's snapshot volume. It needs to hold one snapshot of the data, which is at most 60% of `memory_mib`. Snapshots let a restarted pod come back with its data. | | `cpu_millicores` | 50 to 4000 | 100 | CPU request for each pod. | ## NATS Package `nats` 1.0.0: NATS 2.15 with JetStream. | Setting | Range | Default | What it changes | | - | - | - | - | | `replicas` | 1 | 1 | Number of servers. This version runs a single server. | | `storage_gib` | 1 to 1000 GiB | 10 | Size of the JetStream volume. Streams may use up to 90% of it. | | `memory_mib` | 128 to 16384 MiB | 256 | Memory for the server. Its Go runtime is told to stay under 80% of it. | | `cpu_millicores` | 50 to 4000 | 100 | CPU request for the server. | ## OpenSearch Package `opensearch` 1.0.0: OpenSearch 3.9, as a single node with the security plugin on. | Setting | Range | Default | What it changes | | - | - | - | - | | `storage_gib` | 5 to 1000 GiB | 20 | Size of the data volume. OpenSearch stops accepting writes when it is 95% full. | | `memory_mib` | 1024 to 32768 MiB | 2048 | Memory for the node. Half of it is the JVM heap; the rest is left to the operating system's file cache, which OpenSearch depends on. | | `cpu_millicores` | 250 to 8000 | 500 | CPU request for the node. | ## SeaweedFS Package `seaweedfs` 1.0.0: SeaweedFS 4.48 with an S3-compatible API, as one pod on one volume. | Setting | Range | Default | What it changes | | - | - | - | - | | `storage_gib` | 1 to 2000 GiB | 20 | Size of the data volume, which holds every object. | | `memory_mib` | 256 to 16384 MiB | 512 | Memory for the pod. | | `cpu_millicores` | 100 to 8000 | 250 | CPU request for the pod. | ## VictoriaLogs Package `victoria-logs` 1.0.0: VictoriaLogs 1.52, as a single server. | Setting | Range | Default | What it changes | | - | - | - | - | | `retention_days` | 1 to 365 days | 14 | Days a log line is kept before it is deleted. Once the volume is 80% full, the oldest data is deleted first, so logs that arrive faster than `storage_gib` allows for can go sooner. | | `storage_gib` | 1 to 1000 GiB | 20 | Size of the log volume. | | `memory_mib` | 256 to 16384 MiB | 512 | Memory for the server. | | `cpu_millicores` | 100 to 8000 | 250 | CPU request for the server. | ## VictoriaMetrics Package `victoria-metrics` 1.0.0: VictoriaMetrics 1.153, as a single server. | Setting | Range | Default | What it changes | | - | - | - | - | | `retention_days` | 1 to 3650 days | 30 | Days a sample is kept before it is deleted. | | `storage_gib` | 1 to 1000 GiB | 20 | Size of the data volume. VictoriaMetrics stops accepting writes when it is full. | | `memory_mib` | 256 to 16384 MiB | 512 | Memory for the server. VictoriaMetrics sizes its caches to 60% of it. | | `cpu_millicores` | 100 to 8000 | 250 | CPU request for the server. | ## Health checks Ankra decides a service's [health](https://docs.ankra.ai/concepts/managed-services.md#health) from these checks, read from its synced view of the service's cluster, in the service's namespace. | Service | Workload, ready against the plan | Kubernetes Service | Secret, with every key [the connection lists](https://docs.ankra.ai/guides/connect-to-a-managed-service.md#addresses-and-secrets) | | - | - | - | - | | PostgreSQL | CloudNativePG pods labelled `cnpg.io/cluster=postgresql`: the primary Ready, `instances` pods Ready, and one `Bound` volume claim per instance | `postgresql-rw` | `postgresql-app` | | Valkey | StatefulSet `valkey`, `1 + replicas` ready | `valkey` | `valkey-credentials` | | NATS | StatefulSet `nats`, `replicas` ready | `nats` | `nats-credentials` | | OpenSearch | StatefulSet `opensearch`, 1 ready | `opensearch` | `opensearch-credentials` | | SeaweedFS | Deployment `seaweedfs-all-in-one`, 1 available | `seaweedfs-all-in-one` | `seaweedfs-s3-secret` | | VictoriaLogs | StatefulSet `victoria-logs`, 1 ready | `victoria-logs` | `victoria-logs-credentials` | | VictoriaMetrics | StatefulSet `victoria-metrics`, 1 ready | `victoria-metrics` | `victoria-metrics-credentials` | Every service is also checked for the stack that owns it: a member that failed to apply or is being removed, or a stack that is gone or being removed, reads `degraded`. | Value | Applies to | | - | - | | About 1 minute | How often each service is observed | | 5 minutes | How long an observation stands before it reads `unknown` | | 15 minutes | How recent Ankra's view of a resource type on the cluster must be for a missing object to count as missing; older reads `unknown` | | 10 minutes (PostgreSQL, OpenSearch), 5 minutes (the others) | Grace window after a successful deployment, during which a failing check reads `progressing` | | 30 minutes | How long after its last write a stack member's apply still counts as in progress | ## Readiness check Every service has a [readiness](https://docs.ankra.ai/concepts/managed-services.md#readiness) check: a short-lived pod the cluster's agent starts in the service's namespace, which connects to the service's primary address as a client would. `` stands for the service name. | Service | Image | Credentials, by reference from the service's Secret | | - | - | - | | PostgreSQL | `postgres:16-alpine` | `password` of `postgresql-app` | | Valkey | `valkey/valkey:9.1.2-alpine` | `username` and `password` of `valkey-credentials` | | NATS | `natsio/nats-box:0.19.3` | `username` and `password` of `nats-credentials` | | OpenSearch | `curlimages/curl:8.16.0` | `username`, `password` and `ca.crt` of `opensearch-credentials` | | SeaweedFS | `curlimages/curl:8.16.0` | `admin_access_key_id` and `admin_secret_access_key` of `seaweedfs-s3-secret` | | VictoriaLogs | `curlimages/curl:8.16.0` | `username` and `password` of `victoria-logs-credentials` | | VictoriaMetrics | `curlimages/curl:8.16.0` | `username` and `password` of `victoria-metrics-credentials` | The images other than PostgreSQL's are pinned by digest. What each check does is listed under [Readiness](https://docs.ankra.ai/concepts/managed-services.md#readiness). The PostgreSQL check runs `psql -h postgresql-rw..svc.cluster.local -p 5432 -U app -d app -c "SELECT 1"`. | Property | Value | | - | - | | Pod label | `app.kubernetes.io/name=ankra-postgres-connection-test` for PostgreSQL, `app.kubernetes.io/name=ankra-service-canary` for the others. The pod is deleted when it finishes. | | Credential values | Passed to the pod by reference. They never leave the cluster. | | Interval | About every 5 minutes, measured from the last attempt | | Result stands | 15 minutes | | Pod time limit | 60 seconds | | Grace window | While no check has passed yet: 10 minutes after a successful deployment for PostgreSQL and OpenSearch, 5 minutes for the other services | | Agent | The checks for services other than PostgreSQL need an agent recent enough to run them. Until it is, the service reads `unverified` and `readiness_check.reason` says to upgrade the agent. | At most one check pod runs on a cluster at a time. ## Related > **[Set up a managed service](https://docs.ankra.ai/guides/set-up-a-managed-service.md)** > > Where these settings are chosen. > **[Connect to a managed service](https://docs.ankra.ai/guides/connect-to-a-managed-service.md)** > > Addresses and credentials for each service. > **[Managed services](https://docs.ankra.ai/concepts/managed-services.md#health-and-readiness)** > > What each health and readiness state means. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.