How to Host a Discord Bot 24/7: The Complete Guide

Your bot works perfectly on your laptop. Then you close the lid, and it goes offline. Every Discord bot eventually hits this wall: a bot is only online while the process running it is alive, and a personal computer is a poor place to keep a process alive for months.

This guide covers what “24/7” actually requires, the hosting options available, a complete deployment walkthrough, and the checklist we use to keep production bots stable.

What keeping a bot online actually requires

A Discord bot is not a website. A website answers requests and can sleep between them. A bot holds an open WebSocket connection to Discord’s gateway and receives events — messages, interactions, member joins — over that connection for as long as it’s running. If the process stops, the connection closes and the bot shows as offline.

So “24/7 hosting” really means four things:

1. A persistent process. No idle timeouts, no sleeping after 30 minutes without traffic, no daily restarts you didn’t ask for.
2. Supervision. Something that notices when the process crashes and starts it again within seconds.
3. Safe secrets. Your bot token has to be available to the process without living in your source code.
4. Durable storage. Config files, SQLite databases and logs must survive restarts and redeploys.

Anything that misses one of these will eventually take your bot offline.

Your hosting options

Running a bot from home works for testing, but power cuts, Windows updates and your ISP all become your uptime problem. Many free platforms were designed for web apps and suspend processes that don’t receive HTTP traffic — fatal for a gateway bot. We cover that trap in free PaaS platforms vs dedicated bot hosting.

A VPS gives you full control, but you’re responsible for the OS, security updates and process supervision. Managed bot hosting handles all of that and gives you a panel with a console, file manager and restart button. If you’re unsure which fits, read managed bot hosting vs a VPS.

Step 1: Prepare your project

Before uploading anything, make your project deployable.

Declare dependencies. Node.js bots need a package.json with every package listed. Python bots need a requirements.txt. The host installs from these files — anything you installed globally on your laptop won’t exist on the server.

Add a start command. For Node.js, add a start script:

{
  "name": "my-bot",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "discord.js": "^14.16.0"
  }
}

Read the token from the environment. Never hard-code it:

const { Client, Events, GatewayIntentBits } = require('discord.js');

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

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

client.login(process.env.DISCORD_TOKEN);

If a token has ever been committed to git, reset it in the Discord Developer Portal — deleting the line doesn’t remove it from history. Our guide to keeping your bot token safe goes deeper.

Step 2: Create a server

On Kerit Cloud you can start on the free tier — 256 MB RAM, 30% of an AMD EPYC core and 2 GB of NVMe storage — or pick a paid Discord bot plan if your bot is already in many servers. Plans run in Virginia by default, the same region as Discord’s primary gateway, which keeps WebSocket latency under 18 ms.

When you create the server, choose the runtime your bot uses: Node.js (16–22), Python (3.9–3.12) or Java (11, 17 or 21).

Step 3: Upload your code

You have two routes:

• Git deploy. Link your GitHub repository in the panel. Every push pulls the latest commit, installs dependencies and restarts the bot — usually live again in under 60 seconds. See the push-to-deploy workflow.
• File upload. Use the panel’s file manager or SFTP. Upload your source and dependency file, but not node_modules or a virtual environment — let the server install those.

Step 4: Set your environment variables

Add DISCORD_TOKEN (and any API keys) as environment variables in the panel. On Kerit Cloud these are stored encrypted and never written to your logs. Your code reads them exactly as it did locally with a .env file.

Step 5: Start and watch the console

Press start and watch the live console. You should see your dependency install, then your “Logged in as…” line. If the bot crashes, the error appears here — and the watchdog restarts the process within seconds, so a single bad event won’t keep you offline.

Tip: Invite the bot to a private test server first. Confirm commands work in production before announcing anything.

A production checklist

Once the bot is live, work through this list:

• Handle errors. An unhandled promise rejection can kill a Node.js process. Log it instead:

process.on('unhandledRejection', (err) => {
  console.error('Unhandled rejection:', err);
});

• Request only the intents you need. Privileged intents (message content, members, presences) must be enabled in the Developer Portal and cost memory. See gateway intents explained.
• Shut down cleanly. Close database connections on SIGTERM so restarts don’t corrupt data — covered in graceful shutdowns.
• Log usefully. Timestamps and command names make debugging far easier than bare stack traces.
• Back up data. Paid plans include automatic backups; export anything critical regularly anyway.
• Monitor uptime. External checks tell you about problems before your users do.

How many resources does a bot need?

Less than most people think. A small moderation or utility bot idles around 100–150 MB of RAM, which fits the free tier. Bots in 50+ servers with a database usually want 512 MB to 1 GB. Music bots and sharded bots should start around 3 GB. Our RAM guide has measured numbers by bot type.

Troubleshooting common problems

The bot starts, then goes offline. Check the console for the crash. The most common causes are a missing environment variable, a dependency that wasn’t installed, or running out of memory.

“Used disallowed intents”. You requested a privileged intent that isn’t enabled in the Developer Portal. Enable it there or remove it from your code.

Slash commands don’t appear. Commands must be registered with Discord’s API, and global commands can take time to propagate. See slash commands not showing up.

It works locally but not on the server. Compare runtime versions. A bot written for Node.js 20 may fail on 16, and a Python 3.12 feature won’t exist on 3.9.

Summary

Hosting a bot 24/7 comes down to a persistent process, automatic restarts, safe secrets and durable storage. Prepare your project with a dependency file and a start command, keep the token in an environment variable, deploy with git or file upload, and watch the console on first start. Begin on a free plan, measure your real usage, and upgrade only when the numbers tell you to.