Discord Bot Hosting 2026: Production Guide for 24/7 Bots

Running a Discord bot on your laptop works fine for testing. The moment you close the lid, the bot dies. To keep a bot online 24/7 for real users, you need real infrastructure. This is the complete production guide for 2026 — based on running two production bots (narutorealms.com and onepiecerealms.com) on Renzom ourselves.

TL;DR

• Lightweight bots (one server, basic commands): 256–512 MB RAM, ~3 €/month is enough
• Production bots (hundreds of guilds, persistent state): 1–2 GB RAM, dedicated CPU thread
• Use a process manager (PM2 or systemd) — bots crash, you need automatic recovery
• EU hosting matters if your users are in Europe (DSGVO, latency, jurisdiction)
• Free tiers are a trap — Heroku is dead, Replit/Railway sleep your bot, free shared hosts disconnect WebSockets

We Eat Our Own Dog Food

Before this becomes another generic "how to host a Discord bot" article: we run two of our own Discord card-game bots on Renzom infrastructure. Both are production bots with real users, persistent state, and live trading systems:

• narutorealms.com — Naruto-themed card-collection bot with gacha pulls, multi-server XP system, trading marketplace
• onepiecerealms.com — One Piece-themed card game bot with the same engine, separate persistence layer, Top.gg integration

Everything in this article is what we actually do, not what sounds good on paper. The setup is opinionated because it has to survive contact with real users.

Why You Need Dedicated Hosting

Discord bots maintain a persistent WebSocket connection to Discord's gateway. That means:

• The host needs a stable, always-on internet connection
• The Node.js or Python process needs to keep running indefinitely
• When (not if) the bot crashes, it needs automatic restart
• For bots with user state, you need a database that doesn't disappear

Your home internet, laptop, or a free Replit/Glitch sandbox is not reliable enough for a production bot. A real VPS or dedicated Discord bot hosting is the right solution.

Why Free Tiers Are a Dead End

The old advice "use Heroku free tier" stopped working in late 2022. The current landscape:

Platform	Reality in 2026
Heroku	Free tier killed 2022, paid plans expensive for always-on
Replit	Hibernates after inactivity unless you pay for Reserved VM
Railway	Charges by usage, fine until your bot grows, then surprising bills
Render	Free tier sleeps after 15 min inactivity
AWS Lambda	Not suitable for persistent WebSocket connections
Cloudflare Workers	No WebSocket persistence, wrong model entirely
VPS (e.g. Renzom)	Always on, predictable price, full control

A 5 €/month VPS will run circles around any "free tier" for a production Discord bot. The economics shifted years ago.

What Your Discord Bot Actually Needs

Discord bots are extremely lightweight compared to game servers. RAM is almost always the binding constraint:

Bot size	Guilds	RAM	CPU	Storage
Toy / hobby	1–10	256 MB	Negligible	1 GB
Community	10–100	512 MB	Low	5 GB
Mid-size	100–1,000	1 GB	1 shared thread	10 GB
Production	1,000–10,000	2 GB	1 dedicated thread	20 GB + DB
Verified large	10,000+	4 GB+	2+ dedicated threads	50 GB + replicated DB

A simple moderation or music bot for a single community needs almost nothing — 256–512 MB RAM is plenty. The narutorealms.com bot, with hundreds of guilds and persistent player state in PostgreSQL, runs comfortably in 1.5 GB.

Memory usage scales with: cached guild data, message intents, slash command handlers, in-process queues, and any reactive UI patterns. CPU usage scales with: events per second, command throughput, and image generation if you do any (cards, charts, leaderboards).

Production Stack: How We Actually Run It

Both narutorealms.com and onepiecerealms.com share the same core engine and host on Renzom. The actual stack:

• Runtime: Node.js 20 LTS, TypeScript compiled to ES2022
• Discord library: discord.js v14 (sharded once we cross the 2,500 guild limit)
• Database: PostgreSQL 16 (Neon EU for managed Postgres, with read replicas for leaderboards)
• Cache: Redis for hot data (active games, cooldowns, rate limits)
• Process manager: PM2 with --max-memory-restart 1500M
• Logging: structured JSON logs to stdout, shipped to a log aggregator
• Monitoring: Sentry for error tracking, custom Discord-channel for health pings
• Deploy: GitHub Actions builds container, SSH deploy to Renzom VPS, PM2 reload zero-downtime

The whole thing runs on one VPS per bot for separation of concerns. Going multi-VPS only matters once you cross sharding thresholds.

Node.js Discord Bot Setup (discord.js v14)

The dominant stack for new bots in 2026 is Node.js with discord.js v14. Here's the minimal production-ready setup:

# Install Node.js 20 LTS (the recommended version for discord.js v14)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

# Create bot directory
mkdir mybot && cd mybot
npm init -y
npm install discord.js dotenv

Basic index.js:

const { Client, GatewayIntentBits, Partials } = require('discord.js');
require('dotenv').config();

const client = new Client({
  intents: [
    GatewayIntentBits.Guilds,
    GatewayIntentBits.GuildMessages,
    GatewayIntentBits.MessageContent,
  ],
  partials: [Partials.Channel],
});

client.once('ready', () => {
  console.log(`Logged in as ${client.user.tag}`);
  console.log(`Serving ${client.guilds.cache.size} guilds`);
});

client.on('messageCreate', (message) => {
  if (message.author.bot) return;
  if (message.content === '!ping') {
    message.reply(`Pong! Latency: ${client.ws.ping}ms`);
  }
});

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

client.login(process.env.DISCORD_TOKEN);

Store the token in .env (never hardcode):

DISCORD_TOKEN=your_token_here

Slash Commands (the only commands users actually find in 2026)

Old prefix commands (!ping) still work but are not discoverable. Slash commands are the standard:

const { REST, Routes, SlashCommandBuilder } = require('discord.js');

const commands = [
  new SlashCommandBuilder()
    .setName('ping')
    .setDescription('Replies with Pong!')
    .toJSON(),
];

const rest = new REST().setToken(process.env.DISCORD_TOKEN);

(async () => {
  await rest.put(
    Routes.applicationCommands(process.env.APP_ID),
    { body: commands },
  );
  console.log('Registered slash commands.');
})();

Python Discord Bot Setup (discord.py)

If you prefer Python — discord.py is the standard, fully maintained, supports the latest Discord API:

pip install discord.py python-dotenv

Basic bot.py:

import discord
import os
from discord import app_commands
from dotenv import load_dotenv

load_dotenv()

intents = discord.Intents.default()
intents.message_content = True

class MyBot(discord.Client):
    def __init__(self):
        super().__init__(intents=intents)
        self.tree = app_commands.CommandTree(self)

    async def setup_hook(self):
        await self.tree.sync()

client = MyBot()

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

@client.tree.command(name='ping', description='Replies with Pong!')
async def ping(interaction: discord.Interaction):
    await interaction.response.send_message('Pong!')

client.run(os.getenv('DISCORD_TOKEN'))

Keeping Your Bot Online: Process Managers

Production bots crash. They run out of memory, hit rate limits, get disconnected, encounter unhandled rejections. A process manager catches the crash and restarts the bot automatically.

PM2 (Node.js — recommended)

npm install -g pm2

# Start with memory limit + auto-restart
pm2 start index.js --name "my-discord-bot" --max-memory-restart 1500M

# Persist across system reboots
pm2 startup
pm2 save

The --max-memory-restart 1500M flag is the single most important production setting — it kills and restarts the process before it OOMs the whole VPS.

Useful commands:

pm2 list                        # Show all processes
pm2 logs my-discord-bot         # Live logs
pm2 monit                       # Real-time CPU/RAM
pm2 restart my-discord-bot      # Manual restart
pm2 reload my-discord-bot       # Zero-downtime reload

systemd (Linux, language-agnostic)

For Python or for explicit init-system control:

# /etc/systemd/system/discordbot.service
[Unit]
Description=Discord Bot
After=network.target

[Service]
Type=simple
User=bot
WorkingDirectory=/home/bot/mybot
ExecStart=/usr/bin/node index.js
Restart=on-failure
RestartSec=5
EnvironmentFile=/home/bot/mybot/.env
MemoryMax=1500M

[Install]
WantedBy=multi-user.target

Enable and start:

systemctl enable discordbot
systemctl start discordbot
systemctl status discordbot
journalctl -u discordbot -f       # Live logs

MemoryMax=1500M is the systemd equivalent of PM2's memory-restart guard.

Database: Where Your Bot State Lives

Real bots have state — user XP, currency, inventories, settings, leaderboards. Where to put it:

• SQLite — perfect for single-server bots, zero setup, file-based, scales surprisingly well
• PostgreSQL — what we use for narutorealms and onepiecerealms. Handles concurrent guilds, complex queries, JSON columns for flexible data
• MongoDB — fine for document-oriented designs, common in the discord.js ecosystem
• Redis — not your primary DB, but essential for cooldowns, rate limits, and hot data

A common mistake: starting with a JSON file as "database". It works for two guilds and explodes the moment two writes collide. Use SQLite from day one if you don't want a managed DB — it's a single binary, transactions are free.

Security: Protecting Your Bot Token

The bot token is the master key. If it leaks:

• Anyone can impersonate your bot
• Your bot can be used for spam, scams, or abuse — your application gets banned
• You lose control of all guilds and user data

Never:

• Commit the token to Git (add .env to .gitignore)
• Paste it in Discord, screenshots, or screen-shares
• Embed it in client-side code or public Docker images

Always:

• Use environment variables or .env files
• Regenerate immediately if leaked (Discord Developer Portal → Bot → Reset Token)
• Use Discord's "Verified" intent system properly — request only the intents you actually use

Monitoring and Logs

A bot you can't observe is a bot you can't fix. Minimum monitoring stack:

• Structured logs — output JSON to stdout, let PM2/systemd capture it
• Error tracking — Sentry catches unhandled exceptions with stack traces
• Uptime check — a separate service that pings a health endpoint every minute
• Discord-internal health channel — the bot pings a private channel every hour with stats (guilds, latency, memory). When the message stops, you know

For the narutorealms.com bot we log every slash command invocation with: command name, guild ID, user ID, duration, success/failure. That data drives every product decision about which commands to optimize.

EU Hosting and DSGVO Compliance

If your bot has European users, where it runs matters legally:

• Personal data of EU users falls under GDPR (DSGVO in Germany)
• US-hosted bots technically need a data transfer mechanism (SCCs, supplementary measures)
• EU-hosted bots keep the entire stack in EU jurisdiction — simpler legal posture

Renzom hosts in Falkenstein, Germany. That means:

• Data centers operated by Hetzner under German law
• Green energy (Hetzner publishes the energy mix per facility)
• Latency for European users in the 10–30 ms range
• Clear single-jurisdiction handling if a DSGVO request lands

For a hobby bot this is overkill. For a bot with paying users, a marketplace, or any persistent personal data, EU hosting is the lower-friction option.

Pricing: What Discord Bot Hosting Actually Costs

Real numbers in 2026, monthly:

Setup	RAM	Storage	Price	Good for
Shared cheap host	256 MB	5 GB	1–3 €	Toy bots, single server
Entry VPS (Renzom-style)	1 GB	25 GB	4–7 €	Most community bots
Mid VPS	2 GB	50 GB	8–14 €	Production bots with DB
Replit Reserved VM	1 GB	10 GB	~22 €	Convenience, US-based
Railway Hobby	varies	—	~5–30 €	Convenience, usage-based
Heroku Eco	512 MB	—	5 €	Still works, US-only

Renzom Discord bot hosting starts around 3 €/month for small bots, with PostgreSQL or Redis available as add-ons. That's the realistic price floor for production hosting in the EU.

Common Mistakes to Avoid

After running two card-game bots in production, the recurring mistakes we see:

1. No process manager. Bot crashes once at 3 AM, stays down for 18 hours, users leave reviews. Run PM2 from day one.
2. No memory limit. Memory leak goes unnoticed, the VPS OOMs, everything else on the box dies too. Always set --max-memory-restart.
3. Storing state in a JSON file. Concurrent writes corrupt the file. Use SQLite minimum.
4. Hardcoded token in code. Eventually leaked via Git history, GitHub search, or a logged exception. Use .env.
5. No structured logging. When something breaks, you can't reconstruct what happened. JSON logs from day one.
6. Trying to scale with one giant bot process. Once you cross 2,500 guilds, Discord requires sharding. Plan for it.
7. Ignoring rate limits. Bot gets banned because it didn't backoff on 429s. Use the library's built-in queue.

FAQ

How much does it cost to host a Discord bot 24/7 in 2026? A single small-to-mid Discord bot runs comfortably on a 3–7 €/month VPS. Production bots with persistent state and database needs are typically 8–15 €/month. Free tiers (Heroku free, Replit free) no longer provide 24/7 uptime for Discord bots — the platforms either killed those tiers or sleep your process after inactivity.

Can I host my Discord bot on a free service? Reliably for 24/7: no. Replit hibernates free repls after inactivity. Railway charges by usage. Heroku killed its free tier. The "free" options that technically work require workarounds (cron-pinging your own bot every 5 minutes) that violate ToS or barely work. Spending 3 €/month removes a whole class of problems.

What's the difference between VPS and Pterodactyl-style hosting for Discord bots? A standard VPS gives you SSH access, you install Node.js/Python yourself, run PM2 or systemd. Pterodactyl-style panels give you a managed UI where the bot runs as a "server" with start/stop buttons, log viewer, and resource graphs. For Discord bots specifically, both work — most production bots end up on VPS because Pterodactyl is optimized for game servers. Renzom offers both setups depending on the use case.

Do I need PostgreSQL or is SQLite enough for my Discord bot? SQLite handles up to several million reads/writes per day on a single VPS without issues. Switch to PostgreSQL when you need: multiple bot instances connecting to the same data (sharding), replicas for read-heavy leaderboard queries, or specific Postgres features (JSON queries, full-text search, partitioning). For 90% of bots, SQLite is the right answer for years.

What region should I host my Discord bot in? For European users: Frankfurt, Falkenstein, or Amsterdam — the major European Discord gateway endpoints are in these regions, latency to Discord's gateway is sub-20 ms. For North American users: US East (Virginia) or US West (Oregon). Discord routes WebSocket connections based on the gateway closest to your bot, but the round-trip to your database matters more in practice.

Is discord.js or discord.py better in 2026? Both are actively maintained, both support every modern Discord API feature (slash commands, application commands, threads, voice). The choice comes down to which language your team prefers. discord.js has the larger ecosystem (more libraries, more StackOverflow answers). discord.py has slightly cleaner syntax for async code. For new projects in 2026, discord.js v14 is the most common starting point.

Start Hosting Your Discord Bot

Renzom offers production-ready Discord bot hosting in EU data centers (Hetzner Falkenstein), with full SSH access, your choice of Node.js or Python runtime, and managed databases on request. Starting plans are designed for the lightweight nature of bots — entry tier handles multiple bots, mid tier supports production card-game bots like the ones we run ourselves on narutorealms.com and onepiecerealms.com.

See Renzom Discord bot hosting plans →

Discord Bot Hosting (DE) →