Connect to Valkey

Valkey is the Redis-compatible cache strackt runs for your cache, sessions, and queues. Several applications can share one Valkey service. A new connection gives your app its own key prefix and access name (Valkey username), along with its own password. An existing app keeps working with its current details until strackt moves it. This page lists what your application gets, how those values reach it, and how far the separation between applications goes.

To connect Valkey in the first place, see Add a service.

What each environment gets

When you connect an application's environment to Valkey, strackt gives that environment its own:

Value	What it is
Username	Your app's Valkey access name. New connections get a separate name for each environment. An existing connection keeps its current name until strackt moves it.
Password	Unique to this environment's username.
Key prefix	New connections get a separate prefix for each app connection. An existing connection keeps its current prefix until strackt moves it. Your credentials can use keys under the prefixes currently granted to them.
Database numbers	Two numbered databases on the service that no other connected environment is assigned: one for queues and sessions, and one for cache, so clearing the cache never empties your queue. WordPress sites and Node applications get a single database.
Host and port	Where the service is reachable from your application's server.

You never copy these values yourself. strackt looks up the current values every time you deploy and writes them into the environment file your application reads.

The database lines are set on every deploy, whatever your template or settings say: REDIS_DB and REDIS_CACHE_DB always carry the numbers assigned to this environment. A REDIS_URL of the form redis://[username:password@]host:port[/number], with the service's host and port, has its database number removed, so your queue and your cache each use their own line. A REDIS_URL with anything more in it, such as options after a ?, is left exactly as you wrote it, so check that it names your database.

The service's own page lists every application connected to it, and shows that each one has its own credentials. Opening a remote connection from that page is only available for SQL databases, not for Valkey.

Strackt handles moving existing connections; you do not need to run a migration. For now, only Laravel and WordPress apps with a key prefix are moved. Other apps keep their current access name and prefix. During a move, your app keeps access to its old prefix until strackt confirms it is using the new connection details.

Using your config template

If you use a config template, put these tokens where your application expects each value:

Token	Value
${strackt:valkey.host}	Host
${strackt:valkey.port}	Port
${strackt:valkey.username}	Username for this environment
${strackt:valkey.password}	Password for this environment
${strackt:valkey.db}	Database number for queues and sessions
${strackt:valkey.cache_db}	Database number for cache (the same as valkey.db for WordPress and Node)
${strackt:valkey.prefix}	Key prefix
${strackt:valkey.horizon_prefix}	Key prefix for Laravel Horizon, inside your key prefix

For a Laravel application, the Valkey section of your template looks like this:

REDIS_HOST=${strackt:valkey.host} REDIS_PORT=${strackt:valkey.port} REDIS_USERNAME=${strackt:valkey.username} REDIS_PASSWORD=${strackt:valkey.password} REDIS_DB=${strackt:valkey.db} REDIS_CACHE_DB=${strackt:valkey.cache_db} REDIS_PREFIX=${strackt:valkey.prefix} HORIZON_PREFIX=${strackt:valkey.horizon_prefix}

Laravel's standard Redis and Horizon configuration already reads every one of these variables, so you don't need to change any config files.

For a Node background worker using BullMQ, read its key prefix from REDIS_PREFIX. New Node templates include REDIS_PREFIX=${strackt:valkey.prefix} when Valkey is detected. If you already saved a tokenized Node template, add that line in Environment settings; saved templates are not regenerated. See Background workers for worker setup.

Make sure REDIS_USERNAME is in your template. When strackt builds a starting template from your repository's .env.example, it only fills in the lines that file already has, and many .env.example files have no REDIS_USERNAME line. Without it, your application tries to sign in without a username, and Valkey refuses the connection. Add the line and deploy again.

Every token is replaced when you deploy. If you use a Valkey token and no Valkey service is connected to the environment, the deploy is blocked before it starts and tells you what's missing.

Without template tokens

If your environment settings don't use any ${strackt:...} tokens, strackt adds the connection details for you at deploy time:

Variable	Value
REDIS_HOST	Host
REDIS_PORT	Port
REDIS_USERNAME	Username for this environment
REDIS_PASSWORD	Password for this environment
REDIS_DB	Database number for queues and sessions
REDIS_CACHE_DB	Database number for cache
REDIS_PREFIX	Key prefix
HORIZON_PREFIX	Key prefix for Laravel Horizon, inside your key prefix

These replace any value with the same name that you set yourself.

As soon as your template uses even one ${strackt:...} token, strackt stops adding these variables automatically. From then on it only fills in the tokens you've written, so add every Valkey value you need to the template.

WordPress sites

When strackt generates a WordPress site's wp-config.php and Valkey is connected, it includes the connection for you: WP_REDIS_HOST, WP_REDIS_PORT, WP_REDIS_DATABASE, WP_REDIS_PREFIX, and WP_REDIS_PASSWORD, which carries both the username and the password. These are the settings the Redis Object Cache plugin uses. Like any template, they're filled in with the current values at every deploy.

Keep your keys inside your prefix

Your credentials can read and write keys under the prefixes currently granted to your connection. After strackt finishes moving an existing connection, that is your new prefix. Other key names are refused with a permission error (NOPERM).

If you see that error, check for something that writes keys without the prefix:

• REDIS_PREFIX is missing or changed. Use ${strackt:valkey.prefix} rather than a value of your own.
• Laravel Horizon uses its own prefix. Horizon ignores REDIS_PREFIX, and its default prefix falls outside the one you're allowed to use. Set HORIZON_PREFIX as in the example above.
• Your code talks to Valkey directly through a client that doesn't apply the prefix. Add the prefix to the key names yourself.

What other applications can see

Valkey limits your credentials by key name. That separation has limits, so here's exactly what it covers:

• Other applications can't reach your keys by name. An environment signed in with its own credentials can't read, write, or delete keys under your prefix, and yours can't touch theirs, with one exception below.
• Older prefixes can overlap. An existing connection keeps its current prefix until strackt moves it, and older prefixes built from app and environment names can overlap. For example, shop can be the start of shop-blog. A new connection gets a separate prefix. During a move, the old prefix remains accessible until strackt finishes it.
• Publish/subscribe channels are shared. Any application connected to the same service can publish to and subscribe to any channel, including yours. Don't send anything over a channel that another application on the service shouldn't see.
• Commands that administer the whole service are refused. Your credentials can't flush every database at once, change the service's settings, shut it down, list or manage other users, or list all key names or connected clients. Laravel's queue counters and job inspection that list keys, and BullMQ's worker listing, stop working because of this. Adding, reading and removing jobs and cache entries keeps working.
• Clearing your cache clears only one database. Clearing your application's cache empties only that database, so your queued jobs and sessions survive it.
• Your databases can be fenced in. When strackt has verified that your Laravel or WordPress application only uses its own databases, strackt can confine its connection to them, so it can no longer switch to another database number to read or clear it. strackt applies this; there's nothing for you to configure, and an application stays unconfined until strackt has verified it. If a later deploy changes which database your application uses, strackt lifts the confinement again.
• Applications that aren't fenced in can still reach other databases. Such a connection can switch to another database number and clear it, including yours, and the service's INFO output shows how many keys every database holds. The prefix limits which key names you can read and write; it doesn't stop a database from being cleared.

If an application needs a harder boundary than that, give it its own Valkey service.

When connection details change

Because strackt reads the current username, password, and address every time you deploy, you don't need to update anything by hand. Keep the tokens in your template instead of pasting in values, and the next deploy picks up whatever is current.