# Vetox Command Management — capability reference

> Vetox Command Management — 30 system toggles plus per-command role, channel and alias scoping, with schema, defaults and enforcement order.

- Canonical: https://discordtools.blog/blog/vetox-command-management-reference
- Published: 2026-09-17
- Author: The Index desk
- Facts checked: 2026-08-31
- Sources:
  - Vetox documentation — Command Management (https://docs.vetox.io/en/server-management/command-management) — checked 2026-08-31
  - Vetox documentation — Server Setup (https://docs.vetox.io/en/server-management/setup) — checked 2026-08-31
  - Vetox documentation — Commands overview (https://docs.vetox.io/en/commands/overview) — checked 2026-08-31
- Publication: The Index, an independent site not affiliated with Discord Inc.

---
## What it is

Command Management is two distinct per-server control surfaces kept in two separate stored
documents. **The system switchboard** is 30 boolean toggles deciding which Vetox subsystems run in
a server at all. **Command Config** is the per-command surface: for each individual slash command
and subcommand, whether it is enabled, which roles may or may not use it, which channels it works
in, prefix-free aliases, auto-delete behaviour and preset moderation reasons. A system toggle
governs a whole feature's runtime; a command config governs one invocable command. Turning
Leveling off stops the XP engine entirely; disabling `/rank` only removes that one command.

## The problem it solves

A bot that ships every feature switched on floods a server with behaviour nobody asked for — XP
messages, welcome embeds, starboard reposts, log spam. The switchboard makes every subsystem
opt-in, so an operator adds exactly the features they want. The per-command layer solves the
second-order problem: once a feature is on, its commands still need scoping — a trial moderator
who should run `/warn-add` but not `/ban`, a fun command that must not fire in the announcements
channel, a ticket subcommand restricted to seniors while the rest stays open to the team.

## How it works

**System toggles.** One document per server, three groups — `system` (20 booleans), `ai` (2),
`notifications` (8) — every one of the 30 declared `false` by default at three independent layers:
the storage schema, the API's normalization step (so a server with no document still receives a
complete 30-key object of `false`), and the Bot's own fallback if Kafka does not answer. A fresh
server therefore has every optional subsystem off, confirmed at all three layers independently.

**Command Config.** One document per server holding an array of command entries, each carrying
`enabled` (defaults `true` — the opposite polarity of a system toggle), `category`, and an
`options` object: `enabledRoles`, `disabledRoles`, `enabledChannels`, `disabledChannels` (each
default empty), `autoDeleteCommand`, `deleteWithCommand`, `autoDeleteReply` (each default `false`),
`aliases`, `reasons`, and `subcommandSettings` for per-subcommand overrides.

**Where the command list comes from.** The Bot's leader cluster broadcasts its live command
registry to the API, which merges it with a deploy-time fallback file and the server's own stored
settings — so the dashboard's command list can never drift from what the Bot actually has
registered, and it never lists a command the Bot has not confirmed it runs.

**Runtime enforcement**, checked in order on the slash path: is the command disabled; is the
server or the invoking user blacklisted; does an `enabledChannels` list exist and exclude this
channel; is this channel in `disabledChannels`; do the invoker's roles pass `enabledRoles` /
`disabledRoles`; then — for a subcommand, applied only after every command-level check passes — the
same channel and role checks again at the subcommand level; then the per-command cooldown.

**The prefix-free text path** runs a parallel check. A message starting with the server's
configured prefix character is ignored outright — shortcuts are plain messages. The first word of
a plain message is matched, lowercased, against the server's own stored aliases first, and only
then against the command's built-in default alias, before the same enable/role/channel/blacklist/
cooldown gates apply. See the [Commands reference](/blog/vetox-commands-reference) for exactly
which 68 of 71 command files support this path.

**Preset reasons.** A dropdown of canned justifications exists on exactly five commands — `ban`,
`mute-text`, `mute-voice`, `warn-add`, `timeout` — of which four also accept a duration value.

## What is configurable

### The 30 system toggles — all default `false`

| Group               | Keys                                                                                                                                                                                                                                    |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `system` (20)       | autoRoles, protection, selfAssignableRoles, welcomer, leveling, autoresponder, logs, antiRaid, serverStats, suggestions, colors, reminders, autoInteraction, tempVoice, tickets, starboard, counting, applications, battlePass, streaks |
| `ai` (2)            | aiAutoMod, aiServerControl                                                                                                                                                                                                              |
| `notifications` (8) | twitch, youTube, kick, reddit, bluesky, steam, rssFeeds, podcasts                                                                                                                                                                       |

### Per-command settings

| Setting                                                       | Type                  | Default | Bound                                                                                                    |
| ------------------------------------------------------------- | --------------------- | ------- | -------------------------------------------------------------------------------------------------------- |
| `enabled`                                                     | boolean               | `true`  | —                                                                                                        |
| `aliases`                                                     | string[]              | `[]`    | No stated numeric cap                                                                                    |
| `enabledRoles` / `disabledRoles`                              | string[] (role IDs)   | `[]`    | No stated numeric cap                                                                                    |
| `enabledChannels` / `disabledChannels`                        | string[]              | `[]`    | No stated numeric cap                                                                                    |
| `autoDeleteCommand` / `deleteWithCommand` / `autoDeleteReply` | boolean               | `false` | —                                                                                                        |
| `reasons[]`                                                   | `{reason, duration?}` | `[]`    | Only on the 5 preset-reason commands; no stated cap on count                                             |
| `subcommandSettings[key]`                                     | object                | unset   | Accepts `enabled` plus the four role/channel arrays; a subcommand row does not accept aliases or reasons |

## Tier availability

| Capability                                        | Starter | Basic | Max | Black |
| ------------------------------------------------- | ------- | ----- | --- | ----- |
| All 30 system toggles                             | Yes     | Yes   | Yes | Yes   |
| Full per-command role/channel/alias configuration | Yes     | Yes   | Yes | Yes   |
| Preset reasons on the 5 eligible commands         | Yes     | Yes   | Yes | Yes   |

Neither surface carries a tier gate — every server can toggle all 30 systems and configure every
command from Starter. What is gated separately are the _features_ certain toggles switch on: the
two AI toggles require Black, Anti-Raid requires Basic, and the eight notification toggles require
Basic — gates on the destination feature, never on the toggle mechanism itself.

## Commands

Neither surface has a slash command of its own — both are dashboard-only. What they govern is the
full command set documented on the [Commands reference](/blog/vetox-commands-reference): 70
top-level slash commands plus one context-menu command, three of them carrying 22 subcommands
between them.

## Dashboard surface

| Surface                          | Route                                               |
| -------------------------------- | --------------------------------------------------- |
| System toggles (the switchboard) | `/server/[serverId]/setup`                          |
| Command list                     | `/server/[serverId]/commands`                       |
| One command's settings           | `/server/[serverId]/commands/[commandName]`         |
| A subcommand's settings          | `/server/[serverId]/commands/[parent]-[subcommand]` |

Setup renders 41 module cards across 11 categories. Thirty are the persisted toggles above; the
other 11 are always-on cards with no stored state at all — Overview, Setup, Commands, AI Usage,
Auto-Mod, Moderation Tools, Giveaways, Embed Messages, Backup, Access Control and Dashboard
Watcher. See the [Server Setup reference](/blog/vetox-server-setup-reference) for the full 41-card
breakdown.

## Permissions required

Reaching either surface requires an authenticated session plus Discord Administrator or guild
ownership — the same baseline covered in full on the
[Permissions reference](/blog/vetox-permissions-reference). No Discord permission is required by
Vetox itself to store the configuration; `enabledRoles` grants the _command_, it does not grant
Vetox the Discord permission the command's action requires.

## What it connects to

- **Governs every system feature** — each toggle name maps directly to that feature's own runtime:
  `leveling` to the Leveling engine, `tickets` to Tickets, `serverStats` to
  [Server Insights](/blog/vetox-server-stats-reference), and so on for all 20.
- **Depends on the Bot's live command registry**, so the per-command surface cannot list a command
  the Bot has not itself confirmed it runs.
- **Feeds [Dashboard Watcher](/blog/vetox-dashboard-watcher-reference)** — every toggle flip and
  every command change is recorded in the server's audit trail, with subcommand changes attributed
  to the parent command's name.
- **Gates the notification pollers and the reminder poller** on the API side, since those run on a
  schedule with no per-event Bot gate to protect them otherwise.

## Who it is for

Every server that installs Vetox passes through the switchboard, because the bot ships inert. It
matters most to large servers that want a handful of features and none of the rest, and to any
server with a delegated moderation team, where per-command role scoping is the difference between
handing out Administrator and handing out one command.

## Practical use cases

1. **A fresh install.** Vetox joins and does nothing until the owner switches on Welcomer,
   Leveling and Logging and saves once.
2. **Trial moderators without Discord permissions.** Add a Trial Moderator role to `enabledRoles`
   on `/warn-add` and `/timeout` only — they can run those two commands without holding Manage
   Messages or Moderate Members anywhere in the server.
3. **Splitting a ticket team.** Keep `/ticket close` open to all support staff while restricting
   `/ticket merge` to seniors via its own subcommand settings.
4. **Keeping fun commands out of serious channels.** Add the announcements channel ID to
   `disabledChannels` on a game command.
5. **A prefix-free shortcut.** Set `b` as a stored alias for `/ban`; a moderator then types
   `b @user spam` as a plain message and the ban runs under the exact same gates.

## How it compares

Every general-purpose bot needs some form of module toggling; the depth of per-command scoping on
top of it is where the category diverges sharply.

| Product      | Module toggle model                                                                | Per-command role/channel scoping                               | Free tier                   |
| ------------ | ---------------------------------------------------------------------------------- | -------------------------------------------------------------- | --------------------------- |
| **Vetox**    | 30 system toggles, all default off                                                 | Full: roles, channels, aliases, preset reasons, per-subcommand | Everything, no numeric cap  |
| **Dyno**     | ~13 features free with checkmarks; most caps become "Unlimited" only on paid plans | Not documented at this granularity                             | Modules are free but capped |
| **Carl-bot** | `!disable <command>` per command                                                   | Documented as a toggle, not a full role/channel matrix         | Broad — most modules free   |
| **ProBot**   | Per-module enable, mostly Administrator-gated                                      | Not documented as a distinct system                            | Broad on the module level   |

Dyno's closest equivalent bundles module access with numeric limits that mostly require payment to
remove, and Carl-bot's per-command control is a simple enable/disable rather than a role-and-channel
matrix. Vetox's per-command layer — role, channel, alias and preset-reason control together, with
no numeric ceiling on any of them and no tier requirement — is a materially deeper scoping model
than either, available in full from the free Starter tier.