📘

CLI and Terraform support

CLI and Terraform support for Valkey is currently unavailable. We're working on enabling it for GA.

Connect to a Valkey Managed Database

To connect to a Valkey Managed Database, you need to know your connection details.

To view connection details:

1. Log in to Cloud Manager

2. From the main menu, select Databases.

3. Select the Managed Database cluster of interest from the list.

   The Connection Details section contains information and credentials needed to connect to your database.

   • Username. The default user for all Valkey Managed Databases is akmadmin which replaces the non-accessible root user.

   • Password. The randomly generated password for your database cluster.

   • Host. The fully qualified domain name you can use to reach your database cluster through the public network.

   📘

   IPv6 support

   Use the IPv6 address (AAAA record) for this hostname to avoid network transfer charges when connecting to your database from Linodes within the same region.

   • Port.
   • SSL. This field is set to ENABLED, which means that it is required to use an encrypted TLS/SSL connection.

The TLS server certificate for your Valkey Managed Database is issued from a public certificate authority (CA) Let's Encrypt. Most operating systems include Let's Encrypt in their default trust store, so most popular clients verify this certificate automatically. This means that you shouldn't need to do anything to verify this server certificate. If your client doesn't use system trust by default or excludes Let's Encrypt, follow your client's instructions to trust widely recognized CAs.

🚧

Valkey Managed Databases differs from PostgreSQL and MySQL Managed Databases, which use server certificates that a private, account-specific CA issues. You can't use this private CA to verify server certificates for Valkey instances. Use public CAs instead. Always keep certificate verification enabled when you configure clients to connect to Valkey Managed Databases.

Migrate a Redis database to a Valkey Managed Database

To migrate a Redis database to Valkey Managed Database, you need to perform four steps.

1. Download RedisShake.
2. Prepare the configuration file.
3. Execute the migration.
4. Run basic validation.

Before you begin:

Check the feature support matrix for RedisShake migration, to make sure the migration is possible.

Download RedisShake

To download RedisShake:

1. Download RedisShake for your operating system from the RedisShake official releases page.
2. Use the following command to uncompress the package and verify the binary:

tar -xzf redis-shake-linux-amd64.tar.gz
chmod +x redis-shake

./redis-shake --version || ./redis-shake -v

Prepare the configuration file

1. Use the command to edit the RedisShake configuration file:

vi shake.toml

2. Use the appropriate reader section based on your source Redis configuration:
   1. If the source supports PSYNC / SYNC, use [sync_reader] for continuous replication.
   2. If PSYNC / SYNC commands are disabled, comment out the [sync_reader] section and use [scan_reader] instead for a one-time scan-based copy.
   3. Populate the values based on your source settings.
      
      

Sample source config

[sync_reader]
cluster = false             # Set to true if the source is a Redis cluster
address = "172.1.1.1:6379"  # For clusters, specify the address of any cluster node
username = "default"        # Leave empty if ACL is not in use
password = "xxxxxxx"        # Leave empty if no authentication is required
tls = true                  # Set to true if TLS is required
sync_rdb = true             # Set to false if RDB synchronization is not required
sync_aof = true             # Set to false if AOF synchronization is not required
prefer_replica = false      # Set to true to sync from a replica node
try_diskless = false        # Set to true for diskless sync if the source has repl-diskless-sync=yes

Sample target config

[redis_writer]
cluster = false
address = "valkey-1111-akamai-valkey-test.g2a.akamaidb.net:24662"
username = "default"        # Leave empty if ACL is not in use
password = "xxxxxxx"        # Leave empty if no authentication is required
tls = true
off_reply = false           # Set to true to turn off server replies

Execute the migration

1. Use the command to run RedisShake using the config file:

./redis-shake shake.toml

Example output

2026-05-27 13:37:09 INF load config from file: shake.toml
2026-05-27 13:37:09 INF log_level: [info], log_file: [/tmp/data/shake.log]
2026-05-27 13:37:09 INF changed work dir. dir=[/tmp/data]
2026-05-27 13:37:09 INF GOMAXPROCS defaults to the value of runtime.NumCPU [12]
2026-05-27 13:37:09 INF not set pprof port
2026-05-27 13:37:09 INF create SyncStandaloneReader
2026-05-27 13:37:09 INF * address: 172.1.1.1:6379
2026-05-27 13:37:09 INF * username: default
2026-05-27 13:37:09 INF * password: *********************************************
2026-05-27 13:37:09 INF * tls: true
2026-05-27 13:37:09 INF create RedisStandaloneWriter
2026-05-27 13:37:09 INF * address: valkey-1111-akamai-valkey-test.g2a.akamaidb.net:24662
2026-05-27 13:37:09 INF * username: default
2026-05-27 13:37:09 INF * password: ************************
2026-05-27 13:37:09 INF * tls: true
2026-05-27 13:37:10 INF start syncing...
2026-05-27 13:37:10 INF set target redis max qps to 300000
2026-05-27 13:37:10 INF [reader_172.1.1.1_6379] source db is not doing bgsave! continue.
2026-05-27 13:37:15 INF read_count=[20], read_ops=[0.00], write_count=[20], write_ops=[0.00], syncing aof, diff=[0]
2026-05-27 13:37:20 INF read_count=[20], read_ops=[4.00], write_count=[20], write_ops=[4.00], syncing aof, diff=[0]
2026-05-27 13:37:25 INF read_count=[20], read_ops=[0.00], write_count=[20], write_ops=[0.00], syncing aof, diff=[0]

The following values indicate that RedisShake is caught up:

read_ops=[0.00], write_ops=[0.00], diff=[0]

In sync mode, RedisShake will continue running and waiting for new changes. When you are ready to cut over, stop application writes, confirm that RedisShake is caught up, and then terminate it with Ctrl+C or

kill -TERM <redis-shake-pid>

Run basic validation

The validation consists of comparing the keyspace summary on both the source and target.

1. On source, run:

redis-cli --tls -h SOURCE_HOST -p SOURCE_PORT -a 'SOURCE_PASSWORD' INFO keyspace

2. On target, run:

redis-cli --tls -h TARGET_HOST -p TARGET_PORT -a 'TARGET_PASSWORD' INFO keyspace

3. Compare database sizes:

redis-cli --tls -h SOURCE_HOST -p SOURCE_PORT -a 'SOURCE_PASSWORD' DBSIZE
redis-cli --tls -h TARGET_HOST -p TARGET_PORT -a 'TARGET_PASSWORD' DBSIZE

4. For a basic final check, sample a few keys and compare their type and TTL on both sides:

redis-cli --tls -h SOURCE_HOST -p SOURCE_PORT -a 'SOURCE_PASSWORD' TYPE keyname
redis-cli --tls -h TARGET_HOST -p TARGET_PORT -a 'TARGET_PASSWORD' TYPE keyname

redis-cli --tls -h SOURCE_HOST -p SOURCE_PORT -a 'SOURCE_PASSWORD' TTL keyname
redis-cli --tls -h TARGET_HOST -p TARGET_PORT -a 'TARGET_PASSWORD' TTL keyname

This provides a basic validation. For exact validation, use a full comparison tool or a custom scan-based validator.

Feature support matrix for RedisShake migration

Common Redis-like databases are generally backward compatible, meaning there are no compatibility issues when migrating from a lower version instance to a higher version.