Documentation

What you need before you start #

You must be the owner of the Discord server or hold the Administrator permission in it. Krios validates this against the Discord API on every dashboard session, so access cannot be spoofed by lower-ranked members. You also need a Discord account in good standing to complete the OAuth sign-in; no separate Krios account or password is created, and revoking access is always available from your Discord Authorized Apps settings.

If your community uses Discord's Community feature with membership screening or rules channels, Krios is fully compatible — the welcome module fires after a member passes screening, not before, so welcome cards are only sent for members who actually complete onboarding.

Recommended first-day checklist #

After the wizard finishes, take five extra minutes to harden your server: confirm the Krios role sits above your moderator roles, enable the Anti-Nuke module from the dashboard and review its default thresholds, publish a ticket panel in your support channel with /ticket-panel, and send a test /warn against an alt or a willing moderator to verify the log channel receives the event. Servers that complete this checklist on day one report dramatically fewer configuration issues later, because every subsystem has been exercised end to end while the setup is still fresh.

How detection works #

Krios continuously watches your server's audit log and correlates every destructive action — bans, kicks, channel deletions, role deletions, and webhook creations — with the account that executed it. Each executor gets a rolling action counter per category, evaluated inside a configurable time window. When any counter crosses its threshold within that window, the engine classifies the behavior as a nuke attempt and triggers the configured response instantly, without waiting for human confirmation.

This windowed-threshold design is what separates legitimate administration from an attack. A moderator deleting one obsolete channel never trips the system; a script deleting fifteen channels in ten seconds does. Every threshold is independently configurable — maximum bans, maximum kicks, maximum channel deletions, maximum role deletions, and maximum webhook creations — so you can tune the sensitivity to match how your staff actually works.

Protection against mass-banning #

Mass-ban attacks are the most common nuke vector because a single compromised moderator account can ban hundreds of members through the API in under a minute. Krios tracks ban velocity per executor: when an account exceeds the configured ban threshold inside the detection window, the engine immediately strips the executor's ability to continue — applying the configured punishment (removing their roles, kicking, or banning the attacker, depending on your settings) — and logs a full forensic record of what happened, including the executor, the targets, and the exact timestamps.

Because detection is velocity-based rather than permission-based, this protection works even when the attacker is a long-trusted moderator whose account was phished. The account's history does not matter; its behavior in the last few seconds does.

Protection against mass channel and role deletion #

Channel and role destruction is the second pillar of a nuke: deleting every channel erases pinned knowledge, webhooks, and permission structures that can take days to rebuild. Krios applies the same windowed counters to channel deletions and role deletions independently, so an attacker cannot stay under the radar by alternating between the two. When either threshold trips, the engine stops the executor and raises a high-priority alert in your security log channel so your team knows exactly which structures were lost before the intervention.

Webhook creation is monitored as its own category because attackers frequently create webhooks in bulk to spam @everyone with malicious links after a takeover. Exceeding the webhook threshold receives the same treatment as any other nuke signal.

Rogue admin protection #

Most security bots silently exempt administrators, which makes them useless against the actual threat model — admins are precisely the accounts with the power to nuke. Krios takes the opposite stance: with the Anti-Nuke module enabled, administrators are subject to the same behavioral thresholds as everyone else. The only hard limit is Discord's own hierarchy — Krios can only act on accounts whose highest role sits below the Krios role, which is why placing the bot's role at the top of your hierarchy during setup is non-negotiable for full coverage.

For this protection to be meaningful, treat your role hierarchy as a security boundary: keep the set of roles above Krios as small as possible (ideally only the server owner), and audit it whenever staff changes. The server owner can never be acted upon by any bot — that is a Discord platform guarantee — so the owner account should be protected with 2FA and used sparingly.

Configuring thresholds and responses #

All anti-nuke settings live in the dashboard under your server's module configuration. You choose the detection interval, the per-category maximums, and the punishment applied to a detected attacker. Stricter thresholds (lower maximums, longer windows) catch attacks earlier at the cost of occasionally challenging unusually fast legitimate cleanup work; looser thresholds give staff more headroom but let an attacker do more damage before tripping the wire. A practical starting point for most communities is the default configuration, tightened after a week of observing your staff's normal activity patterns in the security log.

When the module intervenes, every action is written to the audit log system with full metadata. You can export this evidence at any time with /audit-export in JSON or CSV format, which is invaluable for post-incident review, for appeals, and for deciding whether a tripped threshold was an attack or a false positive that warrants tuning.

Anti-Spam #

The anti-spam system monitors message velocity and repetition per user and per channel. When a member crosses the spam heuristics — rapid-fire identical messages, mass mentions, or sustained message floods — Krios removes the offending messages and applies a graduated response, starting with a timeout via the mute role created during /setup. Because the mute role's channel overrides were provisioned by the wizard, a muted spammer is silenced everywhere at once, including in threads and voice text channels, with no per-channel configuration needed.

Anti-spam runs entirely on behavior, so it catches both human spammers and self-bot scripts. Every removal is logged with the original message content preserved in the log embed, allowing moderators to review exactly what was deleted and reverse the action if a false positive occurs.

Anti-Link #

The anti-link module blocks unauthorized links to prevent phishing, scam giveaways, and server-advertisement spam — the three most common payloads delivered to Discord communities. When enabled from the dashboard, Krios deletes messages containing links from members who lack an exempt role and notifies the channel briefly so the member understands why their message disappeared. Discord invite links receive special scrutiny since they are the primary vector for raid recruitment and competitor poaching.

Moderators and administrators are exempt by default, and the module is designed to be toggled instantly: many communities enable it permanently in general channels while leaving dedicated media or promo channels free, using Discord's per-command and per-channel integration settings for fine-grained control.

Warnings and escalation thresholds #

The /warn command issues a formal warning to a member with a required reason, stored permanently in the database and visible to your whole staff team. Warnings are the connective tissue of fair moderation: instead of each moderator acting on partial knowledge, every warning is centrally recorded with the issuing moderator, the reason, and the timestamp, so escalation decisions are based on a member's complete history rather than one moderator's memory.

Escalation is automatic and threshold-based: as a member accumulates warnings, Krios applies progressively stronger consequences — a timeout at the first threshold, a kick at the next, and a ban at the final one. This removes the awkwardness of staff having to personally decide when 'enough is enough' and guarantees identical treatment for identical behavior. Members are notified via DM when warned, including the reason, which courts have nothing to do with but community-trust research consistently shows reduces repeat offenses.

Anti-Raid #

Raids — coordinated waves of accounts joining simultaneously to spam, harass, or scout for nuke opportunities — are detected by monitoring join velocity and account characteristics. When a join wave matches raid patterns (many accounts joining within seconds, freshly created accounts, default avatars), Krios can automatically lock down entry by removing the suspicious accounts before they ever post. The module is Premium because it requires sustained, real-time analysis of the member stream, and it pairs naturally with Anti-Nuke: raids are frequently the reconnaissance phase of a later nuke attempt.

All raid interventions appear in the security log with the full list of affected accounts, so legitimate users caught in a wave (it happens — a popular streamer mentioning your server looks a lot like a raid) can be identified and re-invited quickly.

The audit log system #

Every automated and manual action Krios takes — warns, mutes, deletions, anti-nuke interventions, ticket events — flows into a unified audit log stored in the database, independent of Discord's own 45-day audit log retention. The /audit-export command exports this history as a JSON or CSV attachment, filterable by category and capped at the limit you choose, giving you durable, offline evidence for disputes, transparency reports, or staff reviews. Treat the export as your server's black box recorder: when something controversial happens, the answer to 'who did what, when' is always one command away.

Publishing a ticket panel #

Run /ticket-panel in the channel where you want the panel to appear — typically a dedicated #support or #open-a-ticket channel that members can read but not write in. The command accepts options that define the panel completely: a title shown at the top of the embed, a description explaining what the ticket is for and what information members should prepare, the staff role that will be granted access to every ticket opened from this panel, the category under which ticket channels are created, and an accent color to match your server's branding.

Once published, the panel is persistent: it survives bot restarts and requires no maintenance. Members click the button, and Krios instantly creates a private channel visible only to the member, the configured staff role, and the bot itself. If your panels ever end up in a broken state — for example after channel deletions outside the bot — the /reset-panels command rebuilds them cleanly.

Organizing with categories #

Each panel binds to a Discord category, and every ticket opened from that panel is created inside it. This is the key to scaling support: create one panel per concern — general help, member reports, partnership inquiries, billing questions — each pointing at its own category and, if you want, its own staff role. Your moderation team sees report tickets, your admin team sees partnership tickets, and nobody wades through channels irrelevant to them. The /setup wizard provisions a default ticket category for you, but you are free to create additional ones and reference them when publishing specialized panels.

Ticket channels are named predictably after the opening member, so staff can see at a glance who a ticket belongs to. When a ticket is resolved, closing it removes the channel — keeping your category clean — while the record of the conversation lives on in the transcript.

Transcripts and audit trail #

Accountability is what separates a ticket system from a private channel. On Premium servers, every closed ticket generates a full HTML transcript: a styled, self-contained file reproducing the entire conversation — messages, embeds, timestamps, and participants — that can be archived, shared with the affected member, or reviewed during staff audits. Transcripts make 'a moderator was rude to me in a ticket' a verifiable claim instead of a he-said-she-said dispute, protecting both members and staff.

Ticket lifecycle events — opened, claimed, closed, by whom and when — are also written to the unified audit log, so ticket activity appears in /audit-export alongside moderation actions. For communities with formal support SLAs, this is the data source for measuring response times and ticket volume.

Best practices for support teams #

Keep the panel description specific: tell members what to include (their order ID, the user they are reporting, screenshots) so staff do not spend the first three messages extracting basics. Restrict the /ticket-panel command itself to administrators via Discord's integration settings, while granting the day-to-day staff role only the ability to participate in tickets. And establish a closing discipline — tickets that stay open indefinitely clutter the category and bury genuinely active conversations; close resolved tickets promptly and rely on transcripts whenever history is needed.