Deploy Valkey with flags

A managed Valkey instance lives inside a project and is reachable from any container in that project — a Redis-compatible key-value datastore. Choose the cache purpose for data you can afford to lose, or store for persistent workloads.

For the YAML-mode equivalent, see Deploy Valkey with YAML.

Minimal create

reis valkey:create \
  --project my-project \
  --name "Session Cache" \
  --handle session-cache \
  --tier single \
  --purpose cache \
  --memory 256 \
  --regions falkenstein-1

That gets you a single-node Valkey cache with 256 MB of memory. Sensible defaults handle everything else — auth is on with a generated password you can reveal once from the console. Run reis valkey:create with no flags for an interactive prompt.

A persistent, highly available store

The store purpose enables persistence and requires --storage. The ha tier runs a Sentinel topology — your application needs a Sentinel-aware client driver.

reis valkey:create \
  --project my-project \
  --name "Job Queue" \
  --handle job-queue \
  --tier ha \
  --size standard \
  --purpose store \
  --memory 1024 \
  --storage 10 \
  --backup \
  --backup_schedule "0 3 * * *" \
  --regions falkenstein-1

Externally exposed with TLS

Any tier can be exposed at the platform edge on port 6379. External access requires all three of TLS, auth and a non-empty IP allowlist.

reis valkey:create \
  --project my-project \
  --name "Shared Cache" \
  --handle shared-cache \
  --tier single \
  --purpose cache \
  --memory 512 \
  --tls \
  --external \
  --allowed_ips 198.51.100.0/24 \
  --hostnames cache.example.com \
  --regions falkenstein-1

With --tls and no --tls_bundle, the platform issues a TLS bundle and manages it in your vault. To serve your own certificate, create a TLS bundle in your vault, attach it to the instance's project, then pass --tls_bundle <handle> — a bundle that is not attached to the project is rejected, and it must cover every hostname the instance answers to.

Sharded cluster with tuning

The sharded tier runs a cluster topology (minimum 3 shards) — your application needs a cluster-aware client driver. Shards are grow-only in self-service.

reis valkey:create \
  --project my-project \
  --name "Catalog" \
  --handle catalog \
  --tier sharded \
  --size hardened \
  --shards 3 \
  --purpose cache \
  --memory 2048 \
  --maxmemory_policy allkeys-lfu \
  --config tcp-keepalive=300 \
  --config databases=16 \
  --regions falkenstein-1 \
  --regions singapore-1

Flag reference

Allowlisted --config keys: tcp-keepalive, timeout, tcp-backlog, databases, loglevel. Unknown keys are rejected naming the key.

Everyday commands

reis valkey:list                          # list instances
reis valkey:show <id>                     # instance details
reis valkey:update <id> --memory 2048     # change a setting
reis valkey:delete <id>                   # terminate (asks for confirmation)

Updates re-apply the full configuration with your change on top; --purpose is immutable and cannot be updated.

Connecting from a container

Once the instance is running, containers in the same project reach it on the internal network at <handle>:6379. The tier decides the client driver: single works with any client, ha needs a Sentinel-aware driver, sharded a cluster-aware one.

Related

• Deploy Valkey with YAML — YAML-mode equivalent
• Deploy an HTTP container with flags — for the service that uses the datastore