COMMAND(3valkey)

📦
version 9.0.6 · 2 versions
, in fedora 44

💖 COMMAND 💖

okay bestie, deep breath — this is COMMAND(3valkey), straight out of the Valkey Command Manual, and it's the page that spills the tea on literally every command your server knows. it's giving "phone book, but make it cute". let's go 🫶

🎀 NAME 🎀

command — returns detailed information about all commands.

✨ SYNOPSIS ✨

COMMAND

🌈 DESCRIPTION 🌈

Returns an array, and inside that array is the full download on every single Valkey command. all of them. no cap.

COMMAND is introspective — its reply describes all the commands the server can actually process. that's why Valkey clients call it during the handshake, to suss out the server's runtime capabilities. vibe check before the friendship starts, basically 💅

COMMAND also has several subcommands — go peek at those for the extra details, i'm not spoiling them here.

Cluster note, and this one is important: this command is especially beneficial for cluster-aware clients. those clients have to know the names of keys inside commands so they can route requests to the correct shard. and like, most commands do accept a single key as their first argument, but bestie, there are so many exceptions to that rule. so you can call COMMAND and then keep the mapping between commands and their respective key specification rules cached on the client. iconic behaviour honestly.

the reply it returns is an array with one element per command. and each element that describes a Valkey command is represented as an array by itself. arrays inside arrays, she's nested, we love her 🦋

the command's array has a fixed number of elements — the exact number depends on the server's version. so don't get comfy assuming, okay?

  1. Name
  2. Arity
  3. Flags
  4. First key
  5. Last key
  6. Step
  7. ACL categories
  8. [Tips][tb]
  9. [Key specifications][td]
  10. Subcommands

💖 NAME 💖

(yes, the field is called Name, and yes, this section is also called NAME — we're doing that, it's fine)

this is the command's name, in lowercase.

Note: Valkey command names are case-insensitive. lowercase is just how it shows up here.

🔢 Arity

Arity is the number of arguments a command expects. the pattern is genuinely simple:

  • a positive integer means a fixed number of arguments.
  • a negative integer means a minimal number of arguments.

and listen: command arity always includes the command's name itself (plus the subcommand, when there is one).

Examples:

  • The arity of valkey-get(7) GET is 2, since the command only accepts one argument and always has the format GET _key_.
  • The arity of valkey-mget(7) MGET is -2, since the command accepts at least one argument, but possibly multiple ones: MGET _key1_ [key2] [key3] ....

🚩 Flags

Command flags are an array. it can contain the following simple strings (status reply):

  • admin — the command is an administrative command.
  • asking — the command is allowed even during hash slot migration. this flag is relevant in Valkey Cluster deployments.
  • blocking — the command may block the requesting client.
  • denyoom — the command is rejected if the server's memory usage is too high (see the maxmemory configuration directive).
  • fast — the command operates in constant or log(N) time. this flag is used for monitoring latency with the valkey-latency(7) LATENCY command.
  • loading — the command is allowed while the database is loading.
  • movablekeys — the first key, last key, and step values don't determine all key positions. clients need to use valkey-command-getkeys(7) COMMAND GETKEYS or [Key specifications][td] in this case. more on this below 👇
  • no_auth — executing the command doesn't require authentication.
  • no_async_loading — the command is denied during asynchronous loading (that is when a replica uses disk-less valkey-swapdb(7) SWAPDB valkey-sync(7) SYNC, and allows access to the old dataset).
  • no_mandatory_keys — the command may accept key name arguments, but these aren't mandatory.
  • no_multi — the command isn't allowed inside the context of a valkey-transactions(7) transaction.
  • noscript — the command can't be called from valkey-eval-intro(7) scripts or valkey-functions-intro(7) functions.
  • pubsub — the command is related to valkey-pubsub(7) Valkey Pub/Sub.
  • random — the command returns random results, which is a concern with verbatim script replication. this flag is a [command tip][tb].
  • readonly — the command doesn't modify data.
  • sort_for_script — the command's output is sorted when called from a script.
  • skip_monitor — the command is not shown in the output of the valkey-monitor(7) MONITOR command.
  • skip_slowlog — the command is not shown in the output of the valkey-slowlog(7) SLOWLOG command. this flag is a [command tip][tb].
  • stale — the command is allowed while a replica has stale data.
  • write — the command may modify data.

🔀 Movablekeys

Consider SORT:

       1) 1) "sort"
          2) (integer) -2
          3) 1) write
             2) denyoom
             3) movablekeys
          4) (integer) 1
          5) (integer) 1
          6) (integer) 1
          ...

Some Valkey commands have no predetermined key locations, or their key locations are just not easy to find. for those commands, the movablekeys flag is the server saying "yeah, the first key, last key and step values are insufficient to find all the keys". 😭

here are several examples of commands that have the movablekeys flag:

  • valkey-sort(7) SORT — the optional STORE, BY and GET modifiers are followed by names of keys.
  • valkey-zunion(7) ZUNION — the numkeys argument specifies the number key name arguments.
  • valkey-migrate(7) MIGRATE — the keys appear KEYS keyword and only when the second argument is the empty string.

so Valkey Cluster clients need to use other measures, as follows, to locate the keys for such commands:

you can use the valkey-command-getkeys(7) COMMAND GETKEYS command and have your Valkey server report all keys of a given command's invocation. very "just tell me directly" of it.

clients can use the key specifications to identify the positions of key names. and here's the fine print: the only commands that require using COMMAND GETKEYS are SORT and MIGRATE, for clients that parse keys' specifications.

for more information, please refer to the [key specifications page][tr].

1️⃣ First key

the position of the command's first key name argument. for most commands, the first key's position is 1. position 0 is always the command name itself.

🔚 Last key

the position of the command's last key name argument. Valkey commands usually accept one, two or multiple number of keys.

commands that accept a single key have both first key and last key set to 1.

commands that accept two key name arguments — e.g. valkey-brpoplpush(7) BRPOPLPUSH, valkey-smove(7) SMOVE and valkey-rename(7) RENAME — have this value set to the position of their second key.

multi-key commands that accept an arbitrary number of keys, such as valkey-mset(7) MSET, use the value -1.

🪜 Step

the step, or increment, between the first key and the position of the next key.

consider the following two examples:

       1) 1) "mset"
          2) (integer) -3
          3) 1) write
             2) denyoom
          4) (integer) 1
          5) (integer) -1
          6) (integer) 2
          ...

       1) 1) "mget"
          2) (integer) -2
          3) 1) readonly
             2) fast
          4) (integer) 1
          5) (integer) -1
          6) (integer) 1
          ...

the step count is what lets us find keys' positions. for example valkey-mset(7) MSET: its syntax is MSET _key1_ _val1_ [key2] [val2] [key3] [val3]..., so the keys are at every other position — step value of 2. unlike valkey-mget(7) MGET, which uses a step value of 1. see how that works? 💅

🔐 ACL categories

this is an array of simple strings — the ACL categories to which the command belongs. please refer to the Access Control List page for more information.

💡 Command tips

helpful information about the command. to be used by clients/proxies.

please check the [Command tips][tb] page for more information.

🗝️ Key specifications

this is an array consisting of the command's key specifications. each element in the array is a map describing a method for locating keys in the command's arguments.

for more information please check the [key specifications page][td].

🪆 Subcommands

this is an array containing all of the command's subcommands, if any. some Valkey commands have subcommands (e.g., the valkey-config-rewrite(7) REWRITE subcommand of CONFIG). each element in the array represents one subcommand and follows the same specifications as those of COMMAND's reply. it's self-referential, she contains herself, we stan 🧚

📬 REPLY 📬

valkey-protocol(7) Array reply: a nested list of command details. and heads up — the order of the commands in the array is random. do not assume an order, bestie, fr fr.

⏱️ COMPLEXITY ⏱️

O(N) where N is the total number of commands

🎟️ ACL CATEGORIES 🎟️

@connection @slow

📜 HISTORY 📜

  • Available since: 2.8.13

🌟 EXAMPLES 🌟

the following is COMMAND's output for the valkey-get(7) GET command:

       1)  1) "get"
           2) (integer) 2
           3) 1) readonly
              2) fast
           4) (integer) 1
           5) (integer) 1
           6) (integer) 1
           7) 1) @read
              2) @string
              3) @fast
           8) (empty array)
           9) 1) 1) "flags"
                 2) 1) read
                 3) "begin_search"
                 4) 1) "type"
                    2) "index"
                    3) "spec"
                    4) 1) "index"
                       2) (integer) 1
                 5) "find_keys"
                 6) 1) "type"
                    2) "range"
                    3) "spec"
                    4) 1) "lastkey"
                       2) (integer) 0
                       3) "keystep"
                       4) (integer) 1
                       5) "limit"
                       6) (integer) 0
          10) (empty array)
       ...

wait wait wait, don't close the tab — there's more coming in the next part, keep scrolling ⬇️

💖 SEE ALSO 💖

okay bestie, this is the part where we hand you the whole friend group 🫶 — every single page that lives next to this one. no gatekeeping, no "you'll find out later," just the full roster so you can go read whatever your heart desires. they're all 3valkey pages, so i'm gonna write them exactly how they're written, section-suffix and all, because that part is sacred ✨

the acl girlies 👑

permissions, users, passwords, logs — the whole access-control cinematic universe 💅

saving the day 💾

background vibes only, periodt.

the command introspection squad 🔍

yes these are literally the same family as the page you're on rn, they're the cousins at the same table 🍽️

command log besties 📜

config, but make it a group chat ⚙️

server-side main characters 👑

the latency committee ⏱️

they're diagnosing your server's sleep schedule and honestly? relatable 😭

the icon, the legend 🎨

no notes. absolute queen behaviour. 👑

memory lane (literally) 🧠

module besties 🧩

watching, syncing, and other server lore 🌐

slowlog, my beloved 🐌

and the last three, closing us out 🎀

fr fr though — if you're ever stuck, just pick a page off this list and go read it. the docs are your bestie too, i promise. 🦋

and that's a wrap on COMMAND(3valkey), bestie!! this whole thing is from the 9.0.0 release, dated 2025-10-21, so if you're reading this and it's somehow still 2025-10-21 somewhere in the world, hi, you're right on time ✨ go forth and command-info your little heart out 💖🌸🫶

📦 where this page comes from