A Discord bot running 24/7: what it needs and where to run it

The bot you wrote and tested on your computer only works until you close the terminal or shut down the PC. To stay online around the clock it needs a place where its process runs continuously, plus a few things around it: restart on crash, a safely stored token, persistent data and logs. This article covers what a bot technically needs and compares four common ways to run it — a home PC or Raspberry Pi, free hosting, a VPS and bot hosting.

A bot is a long-running process

A typical Discord bot is not a web page that wakes up when someone visits. It is a program that, once started, opens a persistent WebSocket connection to Discord — the gateway — and receives events through it: new messages, members joining, reactions or command usage. As soon as the process exits, the connection is gone and the bot shows as offline in the member list. That's why it isn't enough to "upload" a bot; something has to keep it running. Gateway details are in the Discord developer documentation.

Slash commands (e.g. /ticket) are interactions: Discord delivers them to the bot either over the gateway or — if you set an Interactions Endpoint URL in the Developer Portal — as an HTTP request to your public HTTPS address. The second option doesn't need a persistent connection, but it does need a web server that is always reachable. Most bots built on discord.js or discord.py use the gateway, because besides commands they also react to other events.

What happens when the process crashes

An unhandled exception, a network outage, running out of memory — the bot's process will crash at some point. Libraries handle reconnecting the gateway after a brief outage themselves, but when the whole process exits, something outside has to start it again. On your own server or a VPS this is done by a process manager: pm2 is common for Node.js, and more generally a systemd service with Restart=on-failure. An example with pm2:

npm install -g pm2
pm2 start index.js --name my-bot   # start the bot, restart it on crash
pm2 logs my-bot                    # live log output
pm2 save && pm2 startup            # bring it back after a server reboot

Keep in mind that a restart fixes a one-off crash, not a bug in the code. If the bot crashes right after starting, it will restart in a loop — the log will tell you why.

The token and privileged intents

The token is your bot's password. Anyone who has it can log in as the bot and do anything its permissions allow on every server it's in. Don't hard-code it: read it from an environment variable or a config file (typically .env) that is listed in .gitignore and never ends up in git. A minimal example for discord.js v14 (discord.js.org):

// index.js — discord.js v14
const { Client, Events, GatewayIntentBits } = require("discord.js");

const token = process.env.DISCORD_TOKEN;
if (!token) {
  console.error("DISCORD_TOKEN is not set");
  process.exit(1);
}

const client = new Client({ intents: [GatewayIntentBits.Guilds] });

client.once(Events.ClientReady, (c) => {
  console.log(`Logged in as ${c.user.tag}`);
});

client.login(token);

And the same in discord.py 2.x (discordpy.readthedocs.io):

# bot.py — discord.py 2.x
import os
import discord

intents = discord.Intents.default()
client = discord.Client(intents=intents)

@client.event
async def on_ready():
    print(f"Logged in as {client.user}")

client.run(os.environ["DISCORD_TOKEN"])

The second common trap is privileged intents: Message Content, Server Members and Presence. Your code has to request them, and you also have to enable them in the Developer Portal, otherwise the bot fails to connect or receives empty data. Bots in 100 or more servers must also be verified, and Discord has to approve their access to privileged intents. Request only the intents you actually use — slash commands don't need message content.

Rate limits

Discord limits how many requests a bot can send in a given time. Both discord.js and discord.py track these limits and delay requests for you, so you don't need to handle them by hand — just don't work around them with your own loops that mass-delete messages or edit roles. Repeated invalid requests (for example to channels that no longer exist) can lead to temporarily blocked API access.

Data, logs and updates

• Don't keep data in memory only. Server settings, tickets or activity points stored in a variable vanish on every restart. SQLite (a single file on disk) is enough for a smaller bot; MySQL suits more data or concurrent access from a web dashboard.
• Log things. Print startup, errors and exceptions with timestamps. Without a log you won't find out why the bot crashed at 3 a.m.
• Update dependencies. The Discord API evolves and older library versions eventually stop working. Pin versions (package-lock.json, requirements.txt) and update deliberately, not blindly.

Where to run the bot

For testing and a small bot for friends, a home PC or Raspberry Pi is fine. A VPS makes sense when you run other services alongside the bot and don't mind administering Linux. Bot hosting is the middle ground: you look after the code, not the system.

Bot hosting at BlazeHost

Our Discord bot hosting runs the bot in a container in the Pterodactyl panel with a prepared Node.js or Python runtime. The service includes a MySQL database, a console with live logs, environment variables for the token and automatic process restart after a crash. You upload code via the file manager or SFTP — the panel basics are covered in the Pterodactyl panel guide. It runs on our own hardware in Frankfurt am Main with network-layer (L3/L4) DDoS protection with 7.4 Tbps capacity by Dataforest — mainly useful when the bot also exposes a web dashboard or webhook (more in the article on DDoS attacks). Plans start from 15 CZK per month.

To be fair about the limits: it's a container, not a virtual server, so you don't get root access and the service has no dedicated IPv4 address. You, as the bot's operator, are responsible for the code, the token and compliance with Discord's terms.

Summary

• A bot is a long-running process with a persistent gateway connection — it has to run somewhere non-stop.
• Make sure it restarts on crash (pm2, systemd or hosting that does it for you) and read the logs.
• The token belongs in an environment variable, not in git; reset it immediately if it leaks.
• Enable privileged intents in the Developer Portal and request only the ones you need.
• Store data in SQLite or MySQL, not only in memory, and update dependencies deliberately.

Not sure which plan is enough? Get in touch with what the bot does and how many servers it's in, and we'll suggest a size.