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#
- 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#
- Navigate to the Services left menu and click New Service.
- Enter Name (for example
ValkeyService). - Select Kind: Valkey Service (
service/valkey:9.1). - Select the Location: your data service location. Leave Network unset to let Ametnes manage it.
- Select the Setup Architecture: Starter for evaluation, Small and above for production.
- 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.
- Leave Public unset for a private endpoint, or enable it to make the endpoint reachable from the internet.
- Click Create Service and wait for the status
ready.
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:
--askpass prompts for the password without putting it in your shell history.
For scripting, use the REDISCLI_AUTH environment variable:
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:
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:
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
readyin Ametnes Platform. -
redis-cli --tls ... PINGreturnsPONGas thedefaultuser. - Unauthenticated
PINGis rejected. -
SETandGETround-trip a key. -
INFO serverreports the expected Valkey version.
Next#
- Service Location - choose where the service runs.
- Network Access Resources - control how the service is exposed.
- Resource Reference - resource kinds, capacities and connection data.