Skip to content

Creating a Valkey data service#

Valkey is an open source, Redis-compatible in-memory datastore for caching, messaging and real-time workloads. This tutorial shows you how to create an Ametnes-managed Valkey service and connect to it over TLS with the default ACL user.

Ametnes currently offers one release series, service/valkey:9.1 (Valkey v9.1.3). Starter is a single standalone node; Small and above run three-node replication with Sentinel and a stable HAProxy write endpoint. Tiers differ by CPU, memory, total storage and ACU.

Prerequisites#

  1. A service location (see Service Location).

Networking is automatic by default

Creating a network access resource is optional. If you do not create one, Ametnes manages network access for the location and the service attaches automatically. Create your own only if you want to control exposure (see Network Access Resources).

Connections#

Valkey publishes one TLS connection:

Connection Default port Purpose
valkey 6379 Valkey/Redis protocol over TLS

The host is the service's DNS name on your zone. Use the host and port returned in the service's connection; the control plane may allocate an external port when the default is already in use.

TLS is mandatory. The endpoint uses the account zone wildcard certificate, so clients must connect with TLS and verify the server certificate. Valkey does not require a client certificate: server authentication only.

Create the Valkey service#

  1. Navigate to the Services left menu and click New Service.
  2. Enter Name (for example ValkeyService).
  3. Select Kind: Valkey Service (service/valkey:9.1).
  4. Select the Location: your data service location. Leave Network unset to let Ametnes manage it.
  5. Select the Setup Architecture: Starter for evaluation, Small and above for production.
  6. Enter the Admin Password and store it in a secrets manager. If you leave it blank, Ametnes generates one and returns it with the service.
  7. Leave Public unset for a private endpoint, or enable it to make the endpoint reachable from the internet.
  8. Click Create Service and wait for the status ready.
service.tf
resource "ametnes_service" "valkey" {
  name     = "ValkeyService"
  project  = data.ametnes_project.project.id
  location = data.ametnes_location.location.id
  kind     = "valkey:9.1"
  capacity {
    storage = 10
  }
  config = {
    "architecture"   = "Starter"
    "admin.password" = "<admin-password>"
  }
}

output "connections" {
  value = ametnes_service.valkey.connections
}

Store the admin password immediately

The password is stored in the per-resource Kubernetes Secret and is shown at create time. Store it in a secrets manager before leaving the create screen.

Connect#

The admin user is Valkey's built-in default ACL user. Authenticate with the password you supplied (or the generated one) and the service's host and port.

Check that the service is healthy with redis-cli:

redis-cli --tls -h <host> -p <port> --user default --askpass PING

--askpass prompts for the password without putting it in your shell history. For scripting, use the REDISCLI_AUTH environment variable:

REDISCLI_AUTH='<admin-password>' \
  redis-cli --tls -h <host> -p <port> --user default PING

A healthy service returns PONG. An unauthenticated PING is rejected.

Write and read a key:

REDISCLI_AUTH='<admin-password>' \
  redis-cli --tls -h <host> -p <port> --user default SET greeting "hello from Ametnes"

REDISCLI_AUTH='<admin-password>' \
  redis-cli --tls -h <host> -p <port> --user default GET greeting

From Python, install redis and connect over TLS:

pip install redis
import redis

client = redis.Redis(
    host="<host>",
    port=<port>,
    username="default",
    password="<admin-password>",
    ssl=True,
    ssl_cert_reqs="required",
    decode_responses=True,
)
client.set("greeting", "hello from Ametnes")
print(client.get("greeting"))

The equivalent connection URL is:

rediss://default:<admin-password>@<host>:<port>/0

Replication and failover#

  • Starter runs one standalone Valkey node. There is no automatic failover.
  • Small and above run a three-node replication set. Sentinel (quorum 2) monitors the nodes and promotes a replica when the master fails.
  • The service connection points at the HAProxy write endpoint, which routes to the current master. Clients do not need to speak Sentinel or discover the master themselves.

Architectures#

Storage is the service total and is split across the tier's nodes. Requests are half of the limits.

Architecture Nodes CPU / memory per node Storage (total) ACU
Starter 1 1 CPU / 2Gi 10Gi 2.19
Small 3 2 CPU / 4Gi 25Gi 13.52
Basic 3 2 CPU / 4Gi 50Gi 13.52
Medium 3 4 CPU / 8Gi 100Gi 25.52
Large 3 8 CPU / 16Gi 250Gi 49.52
XLarge 3 16 CPU / 32Gi 500Gi 97.52
2XLarge 3 24 CPU / 64Gi 1000Gi 193.52
3XLarge 5 32 CPU / 96Gi 2000Gi 481.9
4XLarge 5 48 CPU / 128Gi 4000Gi 641.9

Scale#

Use Modify Resource in the console to move to a larger architecture. Changing tiers updates CPU, memory and the requested storage split.

Moving out of Starter does not migrate data

Starter is a standalone Deployment with one data volume. Small and above are StatefulSets with one volume per node, so a Starter -> Small (or any replicated tier) change starts the new topology with empty volumes: the Starter volume is not mounted by the new cluster.

Back up the data first (SAVE/BGSAVE, redis-cli --rdb, or SCAN + DUMP) and restore it into the new tier, or provision the target tier and migrate with your normal tooling.

Moving between replicated tiers (Small through 4XLarge) keeps the same StatefulSet and per-node volumes, so data persists. Adding nodes at 3XLarge and 4XLarge (three to five) replicates from the current master. Existing PVCs keep their current size; plan storage before scaling rather than relying on online volume growth.

Validation checklist#

  • Valkey resource status is ready in Ametnes Platform.
  • redis-cli --tls ... PING returns PONG as the default user.
  • Unauthenticated PING is rejected.
  • SET and GET round-trip a key.
  • INFO server reports the expected Valkey version.

Next#