Managed Valkey users and access control
Every Managed Valkey service comes with a user called default. You can add more users in the Control Panel or with the UpCloud API, and give each one only the access it needs. For step-by-step instructions, see How to restrict user access in Managed Valkey.
The default user
default has full access to every key and can run every command a user can be given, including FLUSHDB, which deletes every key at once. Its access can't be changed in the Control Panel. Its username and password are in the service's connection details. Keep it for your own administration and give each application a user of its own.
How access rules work
A new user can sign in, but it can't run anything until you give it access. Even PING is refused.
You give access with four lists. In the Control Panel, they're on the Access Control List step when you create a user, and in the user's Access control dialog. In the API, they're the categories, commands, keys and channels fields of valkey_access_control.
- Categories allow or block groups of related commands. An entry starts with
+@to allow a group or-@to block it. For example,+@readallows the commands that read data, and-@dangerousblocks potentially dangerous commands, such asFLUSHALL, which deletes every key on the service. - Commands allow or block single commands. An entry starts with
+or-, for example+getor-flushall. - Keys decide which keys the user can read or change. An entry is a pattern in which
*stands for any characters, socart:*covers every key whose name starts withcart:. A pattern without*covers only the key with exactly that name. A user with no key patterns can't read or change any key. - Channels decide which message channels the user can publish to or subscribe to, with the same kind of pattern. Left empty in the Control Panel, or left out of an API request, the list becomes
*, which allows every channel. An empty list sent through the API allows no channels.
For every category and the commands in it, see Command categories in the Valkey documentation.
Entry order
Entries apply in the order they're listed, and a later entry overrides an earlier one. List what you allow first and what you block after it. For example, +@all followed by -@dangerous blocks the dangerous commands, but -@dangerous followed by +@all allows them again. The Control Panel keeps entries in the order you add them.
Entries under Commands apply after the ones under Categories. You can block a category and still allow one of its commands: for example, -@dangerous after +@all under Categories and +info under Commands allows INFO but still blocks FLUSHALL.
Limiting a user to some keys
Key patterns decide which keys a user can read or change, but they don't cover commands that act on the whole service. A user with +@all and the key pattern cart:* can still run FLUSHALL and delete every key on the service. To stop that, add -@dangerous after +@all.
A user limited to some keys can still see the names of other keys with SCAN, but it can't read or change them. A command that names allowed and other keys together, such as MGET cart:1 orders:1, is refused as a whole.
When changes take effect
Changes to a user's access also apply to apps that are already connected as that user, so they don't need to reconnect.
Deleting a user closes its open connections. Changing a user's password leaves its open connections running, and new connections need the new password.
Users and their access are the same on the read-only replica hostname.
Managing users
Manage users and their access on the service's Users tab in the Control Panel, or with the UpCloud API. Valkey's own ACL commands, such as ACL SETUSER, are refused on the service, including for default.
* Valkey and the Valkey logo are trademarks of LF Projects, LLC. Any rights therein are reserved to LF Projects, LLC. Any use by UpCloud is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Valkey and UpCloud. Other names may be trademarks of their respective owners.