NyxSec

My Discord work did not start as one polished security bot. It started with smaller bots and automation experiments, then widened into both destructive and defensive tooling before the current NyxSec codebase.

Those projects gave me a practical reason to learn how Discord events, commands, permissions and server structures fit together. Over time, the focus moved from understanding destructive automation to detecting it and helping a server recover from it.

I built standalone Raid Bot and Nuke Bot projects. They were exactly what the names suggest: experiments with destructive Discord automation, not security tools.

The useful part of revisiting them now is the technical context they created. Their files deal with command and event handling, permissions, roles and channels, asynchronous bot logic, repeated actions, cooldowns, rate limits and changes to server structure. That made the weak points of Discord automation much less abstract.

The operational details are deliberately not published here. This is a record of the projects and how my work developed, not a guide for abusing Discord servers.

The project archive also contains separate anti-raid code, so the shift from experiments to protection is visible in the files even without inventing an exact timeline.

An earlier Anti Raid bot already watched member joins and other server events and could apply or lift a lockdown. The planning notes that followed describe a broader system: bot and channel whitelists, moderator quarantine, alerts, raid-keyword handling and server backups.

Those ideas became concrete parts of NyxSec. The current bot listens to Discord audit-log events for mass changes, watches join patterns and message activity, and can quarantine an actor or switch a server into an emergency mode. Backups and best-effort restoration address what happens after channels or roles are removed.

Protection work in the current code

• Anti-raidJoin velocity, new-account signals, repeated patterns and unrecognized bots.
• Anti-nukeAudit-log monitoring for mass deletions, creations, permission changes, kicks and bans.
• ResponseQuarantine, alerts, emergency lockdown and incident history.
• RecoveryServer-structure backups and restoration of missing channels, categories and roles.

NyxSec is no longer a single bot file. The Python project is split into Discord-facing cogs, reusable services and a data layer. PostgreSQL stores configuration, incidents, quarantine state and backups; Redis handles caching and sliding-window rate limits; Alembic keeps database changes organized.

The surrounding project also has a multi-page website, administration pages and a small Node/SQLite shop. Together, those pieces turned a Discord bot into a larger project involving backend services, web development and the work needed to run them.

• Discord botCommands, event listeners, anti-raid, anti-nuke, moderation and recovery.
• ServicesAlerts, rate limiting, whitelists, quarantine, emergency mode and backup logic.
• DataPostgreSQL, Redis caching and database migrations.
• WebPublic pages, an admin surface and supporting Node/SQLite tooling.

Working on both the destructive experiments and the protection side made Discord permissions, rate limits and event handling concrete. A safeguard has to react quickly, but it also has to avoid punishing normal activity or making a bad situation worse.

As NyxSec grew, the work moved beyond individual commands. I had to separate Discord events from business logic, keep state across restarts, think about migrations and caching, and build web interfaces around the same project. That experience carries into the other security and self-hosted tools I build now.

The current version consists of the protection-focused Discord bot, its PostgreSQL and Redis infrastructure, and the related web and shop code. The README still records some unfinished edges, including automated license handling and scaling work, so I prefer to describe NyxSec as an ongoing personal project rather than a finished platform.

Discord remains an important part of my technical history. At the same time, the ideas behind NyxSec—understanding systems by building them, automating repetitive work and thinking about how things fail—now show up in my web-security, website-auditing and self-hosting projects too.

← Back to selected projects