Is Your Free Bot Protected From DDoS Attacks?
Why bots get attacked, what DDoS protection on a free plan actually covers, what it can't do for you, and simple steps to make your bot a harder target.
On this page
It’s easy to assume nobody would bother attacking a small free bot. Unfortunately, attacks aren’t reserved for big targets. Bots in gaming communities, bots involved in server drama, and bots whose owners have annoyed someone all get hit — and attack tools are cheap. This article explains what protects a free bot on Kerit Cloud, what that protection covers, and what’s still up to you.
Why small bots get attacked
- Community conflicts. Rival servers, banned users and grudges are the most common motive.
- Gaming communities. Minecraft servers and gaming bots are frequent targets because attacks are culturally common there.
- Collateral damage. An attack on another service sharing infrastructure can affect everything nearby — unless the network is protected.
- Curiosity. Some attackers just want to see whether they can.
The point is that protection shouldn’t depend on whether you think you’re worth attacking.
What protects a free bot on Kerit Cloud
DDoS protection isn’t a paid add-on here: it’s part of the network every server sits on, free plan included.
- Layer 3/4 volumetric protection. Traffic passes through OVH’s network-level mitigation, with more than 17 Tbps of global scrubbing capacity for floods like UDP, SYN and ICMP.
- Layer 7 filtering. Application-layer filtering inspects traffic, with rules tuned for Discord WebSocket connections, Lavalink streams and Minecraft handshakes.
- Anycast routing. Traffic is routed over AS203446, Kerit Cloud’s own network, to the nearest scrubbing point.
- Automatic mitigation. Filtering rules trigger within about 10 milliseconds of detection — no ticket, no manual step.
It’s always on, needs no configuration and applies to every plan. The full picture is in how Kerit Cloud DDoS protection works.
Why a Discord bot is harder to attack than you’d think
A typical Discord bot has a helpful property: it doesn’t accept inbound connections. It connects out to Discord’s gateway and API. There’s no open port for an attacker to flood with requests to your code. Attacks against a bot therefore tend to target:
- the server’s IP address directly, with raw network floods — which is what network-level protection absorbs;
- anything the bot exposes, such as a web dashboard, webhook endpoint or health check;
- the bot’s logic through Discord itself — spamming commands to exhaust resources or hit rate limits.
The first is handled by the network. The second and third are where your own design matters.
What DDoS protection can’t do for you
Network protection stops floods of junk traffic. It can’t:
- Stop abuse that looks like normal use. A user (or a raid of accounts) spamming your bot’s commands through Discord is legitimate traffic from the network’s point of view. That’s handled with rate limits in your code.
- Protect a token you leaked. If someone has your bot token, they don’t need to attack anything. See keeping your bot token safe.
- Fix an endpoint that’s expensive to call. If one request to your dashboard triggers a heavy database query, even modest traffic can overwhelm it.
- Protect services hosted elsewhere. If your bot’s database or API lives on another provider without protection, that’s the weak point.
Make your bot a harder target
Rate-limit commands
Give each user a cooldown on expensive commands, and a global limit on anything that hits external APIs or the database heavily. discord.py has built-in cooldown decorators; in discord.js, a simple map of user ID to last-use timestamp works. This protects both your resources and your standing with Discord’s own rate limits — see handling Discord API rate limits.
Don’t expose what you don’t need
If your bot doesn’t need a web server, don’t run one. If it does — a dashboard, a webhook for Telegram, a health check — keep it minimal, validate input, and require authentication or a secret token where possible. Telegram webhooks should always check the secret_token header — see setting up a Telegram webhook over HTTPS.
Keep your IP address to yourself
Don’t post screenshots or logs that show your server’s IP, and don’t run other public services on it that reveal it. For bots with web dashboards, putting the dashboard behind a proxy or CDN hides the origin. See hiding your origin IP.
Keep dependencies updated
Some “attacks” are really exploits of known bugs in outdated libraries. Update your dependencies regularly, and read changelogs for security fixes.
Watch for unusual activity
Log command usage per user and per server. A sudden spike from new accounts, or one server generating most of your traffic, is worth investigating — and quick to spot if you’re already logging. Logging and monitoring a Discord bot covers what to track.
What to do if you think you’re under attack
- Check the panel graphs. Network spikes point to a flood (which the network is mitigating); CPU and memory spikes with normal network usually mean command abuse.
- Check your logs for a flood of commands from particular users or servers, and block or rate-limit them.
- Leave abusive servers. A bot can leave a guild that’s being used to spam it.
- Ask for help in the Kerit Cloud Discord if something looks wrong at the network level.
What to do during a DDoS attack has a fuller checklist.
Summary
Small bots do get attacked. On Kerit Cloud, every plan — free included — sits behind always-on protection: OVH’s 17+ Tbps network-level scrubbing, Cloudflare Magic Transit and anycast routing on AS203446, with automatic mitigation in milliseconds. Discord bots are also naturally hard to flood because they don’t accept inbound connections. What remains up to you is command rate limiting, exposing as little as possible, keeping your token and IP private, and watching for abuse in your logs.