Discord Bot Server Hosting
A Discord bot stays online only while the machine running it is up. On your own computer or on free hosting it drops regularly, goes to sleep or hits a resource limit. A VDS keeps the bot running continuously and lets you add resources as it grows.
What does a server actually do for Discord Bot?
A Discord bot is an ordinary application that listens for events over a persistent WebSocket connection to Discord's gateway and sends requests to its REST API; libraries such as discord.js, discord.py or JDA simply wrap those two channels. Whether the bot appears online depends directly on that connection staying open — the moment the process stops the bot goes offline in the member list and commands go unanswered even though the invite link still works. Two thresholds shape the hosting decision. First: Discord requires a bot present in more than 2,500 servers to split its connection into shards. Second: a bot that reaches more than 100 servers must go through verification before it can use privileged intents such as message content, the member list and presence. Both thresholds live in your code and application settings; the server's job is to keep the connection, the process and your data up.
Why does Discord Bot need a server?
What drives resource needs in bot hosting is not how many servers the bot is in but what it does. A bot that only answers commands uses very little. A music bot loads the CPU because of audio encoding, while a bot tracking members across many servers loads RAM because of the data it caches. For bots that use a database, storage latency matters too.
Recommended resources
These values match the VDS plan tiers in our catalogue; the exact price is calculated in the configurator.
| Scenario | RAM | vCPU | Storage | Note |
|---|---|---|---|---|
| Single bot | 2 GB | 1 | 40 GB | A command-based bot, a few servers, a small database. |
| Several bots / music | 4 GB | 2 | 60 GB | A music bot, or several bots running in parallel. |
| High volume | 8 GB | 4 | 120 GB | A bot active across many servers, with its own database and web panel. |
What really sets the size: cache, shards and rate limits
The difference between a bot that answers commands and one tracking tens of thousands of members is not code complexity but what it holds in memory. With default settings, libraries cache every server, channel and member they see; across 50 servers that is a few hundred megabytes, across a few thousand it is measured in gigabytes. The fix is not buying more RAM but trimming the cache to what you actually use — most libraries let you configure how much of each collection to keep. The second limit is rate limiting: Discord accepts roughly 50 requests per second globally per bot, plus separate per-channel, per-guild and per-endpoint limits. A bot over the line gets a 429 response, the library queues the request, and from outside the bot simply looks slow. So the source of the delay is usually the quota rather than the server, and adding resources will not fix it. Once you shard, each shard opens its own WebSocket connection and keeps its own cache, so RAM grows with the shard count.
Why a music bot is a different calculation
A bot that plays audio does something entirely different from one handling commands: it decodes the source, encodes the audio to Opus and sends it as an uninterrupted stream of 20-millisecond packets. That stream tolerates no pauses; if the CPU saturates even briefly, users hear it as stuttering. The practical measure is this: count one decoder process and one encoding stream for every server currently playing audio. A single stream uses a small share of a modern core, but ten concurrent streams comfortably fill a vCPU. Bandwidth is light — roughly 64-128 kbit/s per voice stream — the bottleneck is CPU. So unlike a command bot, core count translates directly into capacity for a music bot, while RAM is only needed for the cache and the queue. If you run both a music bot and a busy database on the same machine, account for the fact that one long query can interrupt the audio stream: either separate the resources or split the two jobs across two servers.
Setup steps
- 1Install the server with an Ubuntu 22.04 or Debian 12 template.
- 2Connect over SSH and set up the runtime your bot needs (Node.js, Python or your chosen version).
- 3Copy the bot code to the server and install its dependencies.
- 4Run the bot under `systemd` or `pm2` so it restarts by itself if it crashes.
- 5Keep the token in an environment variable rather than in the code, and do not leave the firewall open.
- 6A bot only makes outbound connections; it needs no inbound port. Keep everything except SSH closed in the firewall.
- 7Rotate your logs (`logrotate` or a `journald` size limit); a log file growing quietly fills the disk and stops the bot.
Common mistakes
- Running the bot straight from a terminal. It stops when the SSH session closes; run it as a service.
- Committing the token to a repository. A leaked token means the bot is fully compromised.
- Underestimating a music bot's CPU needs. Audio encoding is far heavier than handling commands.
- Running the bot as `root`. Create a separate unprivileged user so one compromised dependency does not take the whole server.
- Blaming the server for slowness. A bot receiving 429 responses is hitting Discord's rate limit; adding resources will not fix it.
What is included at Datafex
Fexwall L3/L4 DDoS filtering is included free on every plan. Traffic with forged source addresses is stopped at the network edge while legitimate traffic passes.
Every plan uses NVMe SSD. In most of these scenarios the database runs on the same machine as the application, so storage latency shows up directly in response time.
Servers are in Türkiye, at the DGN data centre in Bursa. Transit is 100 Gbps domestic and 10 Tbps international.
Setup completes automatically within minutes. Extra IPs, rDNS, backups and firewall rules are managed from the customer panel.
Frequently Asked Questions
- Why a VDS instead of free hosting?
- Free services usually put the bot to sleep after a while or cap its resources. On a VDS the bot stays up continuously and you decide the resources.
- Does the bot restart automatically if it crashes?
- Yes, if you run it under `systemd` or `pm2`. Without that, a crashed bot stays down until you start it by hand.
- When do I need to start sharding?
- Discord requires sharding for bots present in more than 2,500 servers. If you are approaching that number, plan the move in advance: each shard opens its own connection and keeps its own cache, so RAM grows with it.
- Do I need to open a port for the bot?
- No. The bot connects out to Discord and never waits for an inbound connection. You only need an open port if you also run a web panel or a webhook receiver alongside it.
- How many vCPUs does a music bot need?
- What decides is the number of concurrent voice streams. Two vCPUs are enough for a bot playing in a handful of servers at once; at ten or more concurrent streams, moving to 4 vCPUs prevents stuttering. RAM is secondary in this scenario.
- When does verification for privileged intents become necessary?
- Once the bot passes 100 servers, the application has to be verified before it can use privileged intents such as message content and the member list. That is done in Discord's developer portal rather than on the server — but applying before you cross the threshold stops the bot from silently breaking one day.
Configure your server
Pick the resources that fit and start the setup within minutes.