valkey-io · milliehartnt123 · Jul 1, 2025 · Jul 1, 2025 · Jul 1, 2025 · Jul 2, 2025
diff --git a/commands/acl-getuser.md b/commands/acl-getuser.md
@@ -3,7 +3,7 @@ The command returns all the rules defined for an existing ACL user.
 Specifically, it lists the user's ACL flags, password hashes, commands, key patterns, channel patterns (Added in version 6.2) and selectors (Added in version 7.0).
 Additional information may be returned in the future if more metadata is added to the user.
 
-Command rules are always returned in the same format as the one used in the `ACL SETUSER` command.
+Command rules are always returned in the same format as the one used in the [`ACL SETUSER`](acl-setuser.md) command.
 Before version 7.0, keys and channels were returned as an array of patterns, however in version 7.0 later they are now also returned in same format as the one used in the `ACL SETUSER` command.
 Note: This description of command rules reflects the user's effective permissions, so while it may not be identical to the set of rules used to configure the user, it is still functionally identical.
 

diff --git a/commands/acl-list.md b/commands/acl-list.md
@@ -2,7 +2,7 @@ The command shows the currently active ACL rules in the Valkey server. Each
 line in the returned array defines a different user, and the format is the
 same used in the valkey.conf file or the external ACL file, so you can
 cut and paste what is returned by the ACL LIST command directly inside a
-configuration file if you wish (but make sure to check `ACL SAVE`).
+configuration file if you wish (but make sure to check [`ACL SAVE`](acl-save.md)).
 
 ## Examples
 

diff --git a/commands/acl-log.md b/commands/acl-log.md
@@ -1,6 +1,6 @@
 The command shows a list of recent ACL security events:
 
-1. Failures to authenticate their connections with `AUTH` or `HELLO`.
+1. Failures to authenticate their connections with [`AUTH`](auth.md) or [`HELLO`](hello.md).
 2. Commands denied because against the current ACL rules.
 3. Commands denied because accessing keys not allowed in the current ACL rules.
 

diff --git a/commands/acl-setuser.md b/commands/acl-setuser.md
@@ -14,7 +14,7 @@ Then, you can use another `ACL SETUSER` call to modify the user rules:
 
     ACL SETUSER virginia +get
 
-The above rule applies the new rule to the user `virginia`, so other than `SET`, the user `virginia` can now also use the `GET` command.
+The above rule applies the new rule to the user `virginia`, so other than [`SET`](set.md), the user `virginia` can now also use the [`GET`](get.md) command.
 
 ACL rules can also be grouped into multiple distinct sets of rules, called _selectors_.
 Selectors are added by wrapping the rules in parentheses and providing them just like any other rule.
@@ -25,7 +25,7 @@ For example:
 
 This sets a user with two sets of permissions, one defined on the user and one defined with a selector.
 The root user permissions only allow executing the get command, but can be executed on any keys.
-The selector then grants a secondary set of permissions: access to the `SET` command to be executed on any key that starts with `app1`.
+The selector then grants a secondary set of permissions: access to the [`SET`](set.md) command to be executed on any key that starts with `app1`.
 Using multiple selectors allows you to grant permissions that are different depending on what keys are being accessed.
 
 When we want to be sure to define a user from scratch, without caring if
@@ -56,7 +56,7 @@ This is a list of all the supported Valkey ACL rules:
 
 ### Command rules
 
-* `~<pattern>`: Adds the specified key pattern (glob style pattern, like in the `KEYS` command), to the list of key patterns accessible by the user. This grants both read and write permissions to keys that match the pattern. You can add multiple key patterns to the same user. Example: `~objects:*`
+* `~<pattern>`: Adds the specified key pattern (glob style pattern, like in the [`KEYS`](keys.md) command), to the list of key patterns accessible by the user. This grants both read and write permissions to keys that match the pattern. You can add multiple key patterns to the same user. Example: `~objects:*`
 * `%R~<pattern>`: Adds the specified read key pattern. This behaves similar to the regular key pattern but only grants permission to read from keys that match the given pattern. See [key permissions](../topics/acl.md#key-permissions) for more information.
 * `%W~<pattern>`: Adds the specified write key pattern. This behaves similar to the regular key pattern but only grants permission to write to keys that match the given pattern. See [key permissions](../topics/acl.md#key-permissions) for more information.
 * `%RW~<pattern>`: Alias for `~<pattern>`.
@@ -66,7 +66,7 @@ This is a list of all the supported Valkey ACL rules:
 * `allchannels`: Alias for `&*`, it allows the user to access all Pub/Sub channels.
 * `resetchannels`: Removes all channel patterns from the list of Pub/Sub channel patterns the user can access.
 * `+<command>`: Adds the command to the list of commands the user can call. Can be used with `|` for allowing subcommands (e.g "+config|get").
-* `+@<category>`: Adds all the commands in the specified category to the list of commands the user is able to execute. Example: `+@string` (adds all the string commands). For a list of categories, check the `ACL CAT` command.
+* `+@<category>`: Adds all the commands in the specified category to the list of commands the user is able to execute. Example: `+@string` (adds all the string commands). For a list of categories, check the [`ACL CAT`](acl-cat.md) command.
 * `+<command>|first-arg`: Allows a specific first argument of an otherwise disabled command. It is only supported on commands with no sub-commands, and is not allowed as negative form like -SELECT|1, only additive starting with "+". This feature is deprecated and may be removed in the future.
 * `allcommands`: Alias of `+@all`. Adds all the commands there are in the server, including *future commands* loaded via module, to be executed by this user.
 * `-<command>`: Remove the command to the list of commands the user can call. It can be used with `|` for blocking subcommands (e.g., "-config|set").
@@ -75,8 +75,8 @@ This is a list of all the supported Valkey ACL rules:
 
 ### User management rules
 
-* `on`: Set the user as active, it will be possible to authenticate as this user using `AUTH <username> <password>`.
-* `off`: Set user as not active, it will be impossible to log as this user. Please note that if a user gets disabled (set to off) after there are connections already authenticated with such a user, the connections will continue to work as expected. To also kill the old connections you can use `CLIENT KILL` with the user option. An alternative is to delete the user with `ACL DELUSER`, that will result in all the connections authenticated as the deleted user to be disconnected.
+* `on`: Set the user as active, it will be possible to authenticate as this user using [`AUTH`](auth.md) `<username> <password>`.
+* `off`: Set user as not active, it will be impossible to log as this user. Please note that if a user gets disabled (set to off) after there are connections already authenticated with such a user, the connections will continue to work as expected. To also kill the old connections you can use [`CLIENT KILL`](client-kill.md) with the user option. An alternative is to delete the user with [`ACL DELUSER`](acl-deluser.md), that will result in all the connections authenticated as the deleted user to be disconnected.
 * `nopass`: The user is set as a _no password_ user. It means that it will be possible to authenticate as such user with any password. By default, the `default` special user is set as "nopass". The `nopass` rule will also reset all the configured passwords for the user.
 * `>password`: Adds the specified clear text password as a hashed password in the list of the users passwords. Every user can have many active passwords, so that password rotation will be simpler. The specified password is not stored as clear text inside the server. Example: `>mypassword`.
 * `#<hashedpassword>`: Adds the specified hashed password to the list of user passwords. A hashed password is hashed with SHA256 and translated into a hexadecimal string. Example: `#c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2`.

diff --git a/commands/acl-whoami.md b/commands/acl-whoami.md
@@ -1,6 +1,6 @@
 Return the username the current connection is authenticated with.
 New connections are authenticated with the "default" user. They
-can change user using `AUTH`.
+can change user using [`AUTH`](auth.md).
 
 ## Examples
 

diff --git a/commands/acl.md b/commands/acl.md
@@ -1,3 +1,3 @@
 This is a container command for [Access Control List](../topics/acl.md) commands.
 
-To see the list of available commands you can call `ACL HELP`.
+To see the list of available commands you can call [`ACL HELP`](acl-help.md).
diff --git a/commands/bgrewriteaof.md b/commands/bgrewriteaof.md
@@ -11,7 +11,7 @@ process doing persistence.
 
 Specifically:
 
-* If a Valkey child is creating a snapshot on disk, the AOF rewrite is _scheduled_ but not started until the saving child producing the RDB file terminates. In this case the `BGREWRITEAOF` will still return a positive status reply, but with an appropriate message.  You can check if an AOF rewrite is scheduled looking at the `INFO` command.
+* If a Valkey child is creating a snapshot on disk, the AOF rewrite is _scheduled_ but not started until the saving child producing the RDB file terminates. In this case the `BGREWRITEAOF` will still return a positive status reply, but with an appropriate message.  You can check if an AOF rewrite is scheduled looking at the [`INFO`](info.md) command.
 * If an AOF rewrite is already in progress the command returns an error and no
   AOF rewrite will be scheduled for a later time.
 * If the AOF rewrite could start, but the attempt at starting it fails (for instance because of an error in creating the child process), an error is returned to the caller.

diff --git a/commands/bgsave.md b/commands/bgsave.md
@@ -16,7 +16,7 @@ If `BGSAVE CANCEL` is used, it will immediately terminate any in-progress RDB sa
 In case a background save is scheduled to run (e.g. using `BGSAVE SCHEDULE` command) the scheduled execution will be 
 cancelled as well.
 
-A client may be able to check if the operation succeeded using the `LASTSAVE`
+A client may be able to check if the operation succeeded using the [`LASTSAVE`](lastsave.md)
 command.
 
 Please refer to the [persistence documentation][tp] for detailed information.

diff --git a/commands/command-getkeys.md b/commands/command-getkeys.md
@@ -5,7 +5,7 @@ from a full Valkey command.
 
 `COMMAND` provides information on how to find the key names of each command (see `firstkey`, [key specifications](../topics/key-specs.md#logical-operation-flags), and `movablekeys`),
 but in some cases it's not possible to find keys of certain commands and then the entire command must be parsed to discover some / all key names.
-You can use `COMMAND GETKEYS` or `COMMAND GETKEYSANDFLAGS` to discover key names directly from how Valkey parses the commands.
+You can use `COMMAND GETKEYS` or [`COMMAND GETKEYSANDFLAGS`](command-getkeysandflags.md) to discover key names directly from how Valkey parses the commands.
 
 ## Examples
 

diff --git a/commands/command-getkeysandflags.md b/commands/command-getkeysandflags.md
@@ -2,9 +2,9 @@ Returns @array-reply of keys from a full Valkey command and their usage flags.
 
 `COMMAND GETKEYSANDFLAGS` is a helper command to let you find the keys from a full Valkey command together with flags indicating what each key is used for.
 
-`COMMAND` provides information on how to find the key names of each command (see `firstkey`, [key specifications](../topics/key-specs.md#logical-operation-flags), and `movablekeys`),
+[`COMMAND`](command.md) provides information on how to find the key names of each command (see `firstkey`, [key specifications](../topics/key-specs.md#logical-operation-flags), and `movablekeys`),
 but in some cases it's not possible to find keys of certain commands and then the entire command must be parsed to discover some / all key names.
-You can use `COMMAND GETKEYS` or `COMMAND GETKEYSANDFLAGS` to discover key names directly from how Valkey parses the commands.
+You can use [`COMMAND GETKEYS`](command-getkeys.md) or `COMMAND GETKEYSANDFLAGS` to discover key names directly from how Valkey parses the commands.
 
 Refer to [key specifications](../topics/key-specs.md#logical-operation-flags) for information about the meaning of the key flags.
 

diff --git a/commands/command-info.md b/commands/command-info.md
@@ -1,6 +1,6 @@
 Returns @array-reply of details about multiple Valkey commands.
 
-Same result format as `COMMAND` except you can specify which commands
+Same result format as [`COMMAND`](command.md) except you can specify which commands
 get returned.
 
 If you request details about non-existing commands, their return

diff --git a/commands/command.md b/commands/command.md
@@ -49,8 +49,8 @@ Command arity _always includes_ the command's name itself (and the subcommand wh
 
 Examples:
 
-* `GET`'s arity is _2_ since the command only accepts one argument and always has the format `GET _key_`.
-* `MGET`'s arity is _-2_ since the command accepts at least one argument, but possibly multiple ones: `MGET _key1_ [key2] [key3] ...`.
+* The arity of [`GET`](get.md) is _2_ since the command only accepts one argument and always has the format `GET _key_`.
+* The arity of [`MGET`](mget.md) is _-2_ since the command accepts at least one argument, but possibly multiple ones: `MGET _key1_ [key2] [key3] ...`.
 
 ## Flags
 
@@ -62,22 +62,22 @@ Command flags are an array. It can contain the following simple strings (status
 * **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 `LATENCY` command.
+  This flag is used for monitoring latency with the [`LATENCY`](latency.md) 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 `COMMAND GETKEYS` or [key specifications][td] in this case.
+  Clients need to use [`COMMAND GETKEYS`](command-getkeys.md) or [key specifications][td] in this case.
   See below for more details.
 * **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 `SWAPDB SYNC`, and allows access to the old dataset).
+* **no_async_loading:** the command is denied during asynchronous loading (that is when a replica uses disk-less [`SWAPDB`](swapdb.md) [`SYNC`](sync.md), 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 [transaction](../topics/transactions.md).
 * **noscript:** the command can't be called from [scripts](../topics/eval-intro.md) or [functions](../topics/functions-intro.md).
 * **pubsub:** the command is related to [Valkey Pub/Sub](../topics/pubsub.md).
 * **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 `MONITOR`'s output.
-* **skip_slowlog:** the command is not shown in `SLOWLOG`'s output. This flag is a [command tip][tb].
+* **skip_monitor:** the command is not shown in the output of the [`MONITOR`](monitor.md) command.
+* **skip_slowlog:** the command is not shown in the output of the [`SLOWLOG`](slowlog.md) 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.
 
@@ -102,13 +102,13 @@ For those commands, the _movablekeys_ flag indicates that the _first key_, _last
 
 Here are several examples of commands that have the _movablekeys_ flag:
 
-* `SORT`: the optional _STORE_, _BY_, and _GET_ modifiers are followed by names of keys.
-* `ZUNION`: the _numkeys_ argument specifies the number key name arguments.
-* `MIGRATE`: the keys appear _KEYS_ keyword and only when the second argument is the empty string.
+* [`SORT`](sort.md): the optional _STORE_, _BY_, and _GET_ modifiers are followed by names of keys.
+* [`ZUNION`](zunion.md): the _numkeys_ argument specifies the number key name arguments.
+* [`MIGRATE`](migrate.md): the keys appear _KEYS_ keyword and only when the second argument is the empty string.
 
 Valkey Cluster clients need to use other measures, as follows, to locate the keys for such commands.
 
-You can use the `COMMAND GETKEYS` command and have your Valkey server report all keys of a given command's invocation.
+You can use the [`COMMAND GETKEYS`](command-getkeys.md) command and have your Valkey server report all keys of a given command's invocation.
 
 Clients can use the [key specifications](#key-specifications) to identify the positions of key names.
 The only commands that require using `COMMAND GETKEYS` are `SORT` and `MIGRATE` for clients that parse keys' specifications.
@@ -128,9 +128,9 @@ 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. `BRPOPLPUSH`, `SMOVE` and `RENAME`, have this value set to the position of their second key.
+Commands that accept two key name arguments, e.g. [`BRPOPLPUSH`](brpoplpush.md), [`SMOVE`](smove.md) and [`RENAME`](rename.md), have this value set to the position of their second key.
 
-Multi-key commands that accept an arbitrary number of keys, such as `MSET`, use the value -1.
+Multi-key commands that accept an arbitrary number of keys, such as [`MSET`](mset.md), use the value -1.
 
 ## Step
 
@@ -161,8 +161,8 @@ Consider the following two examples:
 ```
 
 The step count allows us to find keys' positions. 
-For example `MSET`: Its syntax is `MSET _key1_ _val1_ [key2] [val2] [key3] [val3]...`, so the keys are at every other position (step value of _2_).
-Unlike `MGET`, which uses a step value of _1_.
+For example [`MSET`](mset.md): Its syntax is `MSET _key1_ _val1_ [key2] [val2] [key3] [val3]...`, so the keys are at every other position (step value of _2_).
+Unlike [`MGET`](mget.md), which uses a step value of _1_.
 
 ## ACL categories
 
@@ -186,7 +186,7 @@ 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 `REWRITE` subcommand of `CONFIG`).
+Some Valkey commands have subcommands (e.g., the [`REWRITE`](config-rewrite.md) subcommand of `CONFIG`).
 Each element in the array represents one subcommand and follows the same specifications as those of `COMMAND`'s reply.
 
 [ta]: ../topics/acl.md
@@ -196,7 +196,7 @@ Each element in the array represents one subcommand and follows the same specifi
 
 ## Examples
 
-The following is `COMMAND`'s output for the `GET` command:
+The following is `COMMAND`'s output for the [`GET`](get.md) command:
 
 ```
 1)  1) "get"