Command Reference

Add the bot to your server. No setup required to get started.

A quick status check with links straight to the dashboard page for whatever you want to configure.

Fine-tune leveling, logs, tickets, roles, and more visually — no command syntax to remember.

Browse every command by category, or look up any command's exact options with /help command:<name>.

Members pick their own roles from a panel you build. No third party bot, and nothing held back behind a paywall.

Panels come in three styles. Buttons suit up to about ten roles, a dropdown scales to twenty five and gives every role a description, and reactions work the classic way for servers that prefer them.

Each panel also has a behaviour:

On top of that: a role someone must already have to use the panel, a role that bars them from it, and a cap on how many roles one member may hold from a single panel.

Build panels from the dashboard with a live preview showing what Discord will actually render, or from Discord with /rolepanel. Either way the same panel comes out.

Two things worth calling out. Role position is checked again at the moment someone clicks, not only when you build the panel, so a role that later drifts above Vela gives a real reason instead of doing nothing. And a member's roles are written in a single operation, so there is never an instant where somebody holds a contradictory set.

AI Moderation. Confidence thresholds for the severe and toxic tiers, whether severe messages are deleted, what each result from the model counts as, and a list of words the check should skip when a server in joke keeps tripping it. The page names the model in use, and says plainly when no API key is configured, because the check never runs without one.

Economy. Shards in circulation, split between carried and banked, how many members hold a balance, transfer volume over the last week, and a balance table ranked by total wealth. Gambling commands can be switched off. Balances can be adjusted for fixing mistakes and running events, and every adjustment is written to the server log.

Analytics. Moderation actions and new members as daily charts across seven or thirty days, what kind of action was taken, which moderators are busiest, the most active posters, ticket load with an average time to close, and recent changes made from the dashboard. All of it comes from activity Vela already records, so there is nothing to switch on.

Two of those settings had been readable by the bot but impossible to change without editing the database by hand: whether severe messages are deleted, and whether gambling is allowed.

{expr:} executed its contents as real JavaScript. Writing a tag needs Manage Guild, but that permission is per server, so an admin in any one server could read Vela's environment, reach the file system, and run commands on the host. That is control of the bot in every server it is in, reached from a single one.

The check that looked like a guard was not one. Results that were not numbers got discarded, but the code ran either way, and a secret could be read one character at a time through the part that did return numbers.

Expressions are now handled by a purpose built parser that understands numbers, your variables, arithmetic, comparisons, logic, brackets and the Math helpers, and nothing else. There is no route back into JavaScript. Every attack that used to work is now a test.

{if:condition|then|else} picked the right branch to show, then ran both of them. Any role change, message or moderation action sitting in the branch that was not chosen still happened.

For a verification tag this meant the gate never gated. The role went out on every single use, whether or not the member already had it. {and:}, {or:}, {default:} and {fallback:} leaked the same way and now stop early, as they always should have.

{has_role:} and {has_permission:} returned false for every kind of failure: a missing argument, an unknown member, a misspelled permission name. Gates are written as "if they have it say so, otherwise grant it", so false sends execution down the granting branch. A typo quietly turned a closed gate into an open one.

They now give the reason instead of passing it off as an answer, and the member running the tag is read directly rather than from a cache that can forget them. Being forgotten used to read as "does not have the role", which meant handing it over again.

Any command marked owner only or developer only rejected everybody, the owner included. The slash command router tested a value that is never set. The prefix path had always been right, which is why this went unnoticed.

A misspelled function used to show up in your message as plain text. A misspelled variable simply vanished. Neither counted as an error, so a broken tag produced less than intended with nothing anywhere to say why.

Problems now appear underneath the output in the tag tester, and reach the logs when a tag runs for real. Whoever triggered the tag still sees only the result.

{user.mention} also works now. It was documented and in use, but no such value existed, so it rendered as nothing at all.

{loop:}, {repeat:} and {range:} had no ceiling at all. One tag could build a twenty megabyte message instantly. Loops now stop after a thousand rounds, and output is trimmed to Discord's two thousand character limit with a note saying so, which beats the message silently failing to send.

None of this is visible in Discord, but it is why the rest of the list exists.

Vela fails loudly now. Missing configuration is named and stops startup rather than surfacing later as something unrelated. A crash exits so the process manager can restart it, instead of staying up in an unknown state. Errors are written to the database, so a problem can be looked into after a restart rather than vanishing with it.

dashboard.js went from 4,971 lines to 879, its routes split across 27 modules. Tests went from 81 checks to 166, including the first the tag engine has ever had. ARCHITECTURE.md now records how the pieces fit together, which was written down nowhere.

[EventLogs] Webhook failed ... Unknown Webhook repeating forever. When a server's log webhook was deleted on Discord's side — someone removing it from Integrations, or deleting and recreating the log channel — the bot logged an error on every single event in that guild, indefinitely.

The old handler cleared webhookCache on error code 10015, which fixed nothing: the dead URL stayed in the database, so the next event rebuilt a fresh WebhookClient against the same deleted webhook and failed again. The only things that stopped it were a bot restart or the guild going quiet.

Vela now repairs itself:

1. Recreates the webhook in the log channel it already has on record (channels.logs_channel_id), writes the new URL back, and delivers the event that triggered the repair so nothing is lost. 2. If it can't — channel deleted, Manage Webhooks revoked, creation refused, or no log channel ever recorded — it switches event logs off for that guild and says so once, instead of retrying forever. Re-enable with /channel set option:logs.

No action needed from the affected server's staff, which matters because there's no way to reach them.

Guards worth naming, since each one is a way this could have gone wrong:

Roughly two thirds of every release note was missing from the website. The /docs changelog parser kept only lines beginning with - , and discarded everything else:

Measured against the current file: 16,381 of 46,065 characters reached the page — 64% dropped.

CHANGELOG.md is now parsed properly by Features/Data/changelogParser.js: arbitrary section headings with colour derived from the heading, paragraphs, one level of bullet nesting, tables, blockquotes, links, and inline code/bold/italic. HTML is escaped before formatting is applied. Tables scroll inside their own container so a wide row can't push the page sideways on mobile.

108 of the 129 commands listed on /docs were named in a form nobody can type. The generator flattened every subcommand into its own top-level entry called parent.sub, so the page advertised /bot.nickname and /case.view. Discord separates a subcommand with a space — /bot nickname — so anyone copying a command straight off the docs page got nothing.

The same flattening meant cmd.options was never populated, which quietly disabled a large amount of markup that already existed in docs.ejs: the subcommand rows, the per-option chips with types and required markers, and the direct-option grid. None of it had ever rendered.

Now each command file produces one card carrying its real Discord option JSON:

/admin/changelog and the changelogs table are gone. The editor wrote three fixed buckets into a table that had drifted to 2 rows stuck on v2.1.0, and since the page now parses CHANGELOG.md directly, nothing read it any more — leaving a working editor whose output was invisible would have been a trap.

Groq shuts off llama-3.3-70b-versatile on 2026-08-16. Both call sites that used it — the AI moderation gate and /roast — would have started failing outright. Migrated ahead of the deadline.

The two replacements are not interchangeable here. Groq recommends either model for both use cases, but both are reasoning models and reasoning tokens are billed against the output budget. The moderation gate deliberately caps output low (it only ever emits a two-field JSON verdict). Dropping in a model that can't disable reasoning would let it spend that entire cap thinking and return truncated JSON — moderation would fail open silently, with nothing in the logs to show it. qwen/qwen3.6-27b is the only one of the two that supports reasoning_effort: "none", so it takes the hot path.

The audit listed this as "the handler is missing." It was worse than that; there were three independent failures, each verified by reproducing it:

The repost handler briefly cached cooldown expiry in memory to avoid a query per message. It duplicated state the row already holds in lastPost and nothing invalidated it, so deleting a sticky and creating a replacement with a shorter cooldown left the old window silently suppressing reposts. The cache is gone — the row lookup is a single indexed read, which was always cheap enough that the optimisation wasn't worth a stale-state bug. Four of the sticky tests exist specifically because they caught it.

Cosmetics are not just inventory entries — they change how your rank card renders.

Gambling is opt-out per server — admins can disable it with the gamblingEnabled setting, and every gambling command respects it.