Your bot runs beautifully on your laptop. Then you close the lid — and it's gone. Commands time out, the green dot turns grey, and someone in the server asks whether the bot is broken again.
That's why people search for how to host a Discord bot properly instead of just running node index.js and hoping. A bot is a long-lived process. It needs a machine that never sleeps, restarts it after a crash, and survives a 4am reboot without you touching anything.
Quick Answer: Run your bot on a small Linux VPS (1 vCPU and 1GB RAM covers most bots), install Node.js 22 LTS, upload your code, keep your token in a .env file, then start it with PM2 and run pm2 save plus pm2 startup. That combination survives crashes and reboots. As of July 2026, a VPS that does this costs roughly $5–10/month.
Our team resolves 20-30 client issues every day, and "my bot vanished overnight" is a recurring one — on stacks like Hostaccent's, the fix is almost never the bot code. It's the process manager. Here's the whole setup, start to finish.
Free Discord Bot Hosting vs a VPS: What Actually Breaks
Free hosting works right up until your bot matters. That's the honest version of the discord bot hosting free vs VPS debate.
Free tiers do three things that quietly destroy bots:
- They sleep idle processes. A Discord bot holds an open WebSocket gateway connection. When the platform suspends it, the gateway drops, and your bot shows offline until something wakes it.
- They reset the filesystem. If your bot writes to SQLite, a JSON config, or a local cache, a redeploy can wipe it. Levels, warnings, economy balances — gone.
- They cap monthly hours. 550 free hours a month sounds generous until you realise a month has around 730. Your bot dies for the last week of every month.
A VPS is a plain Linux machine that stays powered on. No sleeping, no hour cap, no surprise filesystem reset. You get root, a persistent disk, and a fixed IP.
The trade-off is real, and worth saying out loud: a VPS makes you the sysadmin. Security updates, backups, and the firewall are now your job. If you've never touched SSH, budget an evening — not five minutes.
Pro Tip: Free tiers aren't useless — they're a fine place to test a bot for a weekend. Just never let a community bot with a database live on one. Migrating a broken SQLite file after a reset is much harder than moving a working one.
How to Host a Discord Bot on a VPS: Step by Step
Here's the full path from "works on my laptop" to "runs whether I'm awake or not." Commands below assume Ubuntu 24.04 and a Node.js bot built with discord.js. The concepts are identical for Python bots — swap PM2 for systemd or a Python process manager.
Before you start, have these ready: your bot token from the Discord developer portal, your code in a Git repo (or a zip), and SSH access to a fresh VPS.
Step 1: Secure the server before anything else
Do this first, not later. Create a non-root user, add your SSH key, disable password login, and enable the firewall:
bashadduser botuser usermod -aG sudo botuser ufw allow OpenSSH ufw enable
A bot doesn't need any inbound ports open except SSH — it makes outbound connections to Discord, not the other way round. If your bot has no dashboard, don't open 80 or 443 at all. Full walkthrough here: Linux VPS Security Baseline (Ubuntu 24.04) in 30 Min.
Step 2: Install Node.js 22 LTS
Skip the version in Ubuntu's default repository — it's usually years behind and discord.js will refuse to run. Use the official Node.js LTS release via NodeSource:
bashcurl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt install -y nodejs node -v ## should print v22.x
Step 3: Get your code onto the server
bashcd /home/botuser git clone https://github.com/yourname/yourbot.git cd yourbot npm ci --omit=dev
Use npm ci, not npm install. It installs exactly what's in your lockfile — which means the bot you tested is the bot you're running.
Step 4: Store the token properly
Create a .env file and lock its permissions:
bashnano .env ## add: DISCORD_TOKEN=your_token_here chmod 600 .env
Never commit the token. If it has ever touched a public repo, regenerate it now — credential exposure sits near the top of the OWASP Top Ten for a reason, and Discord's own scanner will invalidate leaked tokens anyway.
Step 5: Test it in the foreground
bashnode index.js
Watch it log in. Fix errors now, while you can see them. Then Ctrl+C — because this is exactly where most guides stop, and exactly where bots start dying.
How much server does a bot actually need?
Less than you think. A typical bot serving a few dozen guilds idles at 80-150MB of RAM and near-zero CPU. Here's the rough sizing we work from:
| Bot type | RAM | Disk | Notes | |---|---|---|---| | Simple command bot, <50 guilds | 1GB | 25GB NVMe | Plenty of headroom | | Music bot with FFmpeg | 2GB | 25GB NVMe | Audio encoding is CPU-hungry | | Bot + database + dashboard | 2-4GB | 50GB NVMe | MariaDB wants its own memory | | 1,000+ guilds, sharded | 4GB+ | 50GB+ NVMe | Each shard is a process |
NVMe SSD storage matters more than raw CPU for anything database-backed — npm ci and MariaDB writes are what you'll actually feel.
Keeping the Bot Alive: PM2, systemd, and Reboots
PM2 is the answer to "how do I keep it running after I close the terminal." It restarts the process when it crashes, and — if you configure it correctly — brings it back after a reboot.
bashsudo npm install -g pm2 pm2 start index.js --name discord-bot --max-memory-restart 300M pm2 save pm2 startup ## then run the command it prints back at you
Those last two lines are the entire difference between a bot that survives a reboot and one that doesn't. pm2 save writes the current process list to disk; pm2 startup registers PM2 as a systemd service so it boots with the machine. A PM2 Discord bot setup missing either of those looks perfect — right up until the kernel updates and the server reboots at 3am.
Useful day-to-day commands:
bashpm2 list ## uptime, restarts, memory pm2 logs discord-bot ## live logs pm2 restart discord-bot ## after a code change pm2 install pm2-logrotate ## stops logs eating the disk
That last one gets skipped constantly. See the PM2 quick start documentation for the full flag list, and our Deploy Node.js App on Linux VPS: PM2 + Nginx Beginner Guide for the version with a web dashboard attached.
Should you use systemd instead? If your bot is a single process with no web front-end, systemd is arguably cleaner — it's already there, it's documented in the Ubuntu Server documentation, and it has no npm dependency of its own. PM2 wins on ergonomics: pm2 logs and pm2 monit beat wrestling with journalctl when you're debugging at midnight. Either is correct. Running neither is not.
Insider Insight: The
--max-memory-restart 300Mflag is the cheapest insurance you'll ever add. Discord bots leak memory slowly — usually via cached message objects that never get evicted. Without a ceiling, the leak runs until the Linux OOM killer terminates the process, and on a box with no swap that can take the whole server down with it.
Why Your Discord Bot Keeps Going Offline
If your Discord bot keeps going offline even after you've set all this up, it's almost always one of five things. In the tickets we handle, they land in roughly this order:
1. An unhandled promise rejection killed the process. Since Node 15, an unhandled rejection terminates the process by default. One bad API call in an event handler, and the bot exits silently. PM2 restarts it — but if the same message triggers it, you get a restart loop. Check pm2 list: a restart count in the hundreds is the tell.
2. The OOM killer. 512MB with no swap is not enough for a bot doing anything real. Add 512MB-1GB of swap and set the PM2 memory ceiling above.
3. pm2 save was never run. The bot was fine for six weeks, then the server rebooted for a kernel patch and never came back. This one is depressingly common.
4. Disk full. Logs, npm cache, and old builds fill a 25GB disk faster than expected, and a full disk breaks writes everywhere. We've handled disk-full and inode-full emergencies where every service on a server stopped at once — logrotate would have prevented most of them.
5. Token or intent problems. A 4004 close code means a bad token. Missing privileged intents in the developer portal means the bot connects but sees nothing, which looks like offline behaviour to your users.
The honest fix for all five is monitoring — you want to hear it from a monitor, not from a 14-year-old in your server. Here's Setup Server Monitoring on VPS: Know Before Your Users Do.
Mistakes We See in the Ticket Queue
From the Ticket Queue: Across a typical month of Hostaccent support tickets, WordPress issues make up 30%, brute-force and malware 25%, Linux server issues 25%, and SSL problems 20% — first-party numbers from our own queue. Bot outages sit inside that Linux slice, and they're almost never a code problem.
The recurring mistakes, in order of how much pain they cause:
- Running the bot as root. If the bot is compromised, so is the whole server. Use a dedicated user. Always.
- Running it inside tmux or screen "temporarily." Temporary lasts until the session dies. Then so does the bot.
- No backups. Your bot's database is real data. We run offsite backups and have done full restores under real pressure, including after hardware failure — the restore you never tested is the one that fails. Start with Linux VPS Backup Automation with Rsync + Cron.
npm installon production. It can quietly bump a dependency and break a working bot.npm cirespects the lockfile.- Editing code directly on the server. It works, until you can't remember what you changed. Push to Git, pull on the server.
Pro Tip: If you're running several bots, containerise them rather than piling them onto one PM2 instance — one bot's dependency upgrade can't then break the others. Install Docker on Ubuntu VPS: Secure Production Setup covers a safe production config.
Quick Recap: The 3-Question Bot Uptime Test
Before you call it done, ask three questions. If you can't answer all three with a confident yes, your bot will go offline — it's just a question of when.
- Does it survive a reboot? Run
sudo reboot, wait two minutes, checkpm2 list. If the bot isn't there, you skippedpm2 save. - Does it survive a crash? Kill the process manually. It should come back in seconds.
- Will you know before your users do? No monitoring means your uptime is whatever your community's patience allows.
The rest of how to host a Discord bot reliably is unglamorous maintenance: keep Node.js on LTS, patch the OS monthly, rotate the logs, and back up the database. That's the whole job.
Where to Run Your Bot
If you'd rather not shop around for a machine, our Linux VPS Hosting Basic plan is $7.99/mo (and renews at $7.99/mo — no first-year pricing games), with NVMe SSD storage, full root access, and a choice of 15 datacenter locations, so you can sit the bot near Discord's gateway region. It comes with a 99.9% uptime guarantee and a 30-day money-back guarantee. Straight limitation: Basic is sized for a standard command bot. If you're running a music bot with FFmpeg encoding or a sharded bot across 1,000+ guilds, start on Standard ($12.00/mo, renews at $12.00/mo) instead — you'll hit the CPU ceiling otherwise.
Frequently Asked Questions About Hosting a Discord Bot
How do I host a Discord bot for free?
You can, using free tiers with hour caps and sleeping processes — fine for testing, unreliable for a live community. Free platforms suspend idle processes, which drops the Discord gateway connection and shows your bot offline. If people depend on the bot, a low-cost VPS is the realistic answer.
How much does it cost to host a Discord bot?
As of July 2026, a VPS capable of running a standard Discord bot 24/7 costs roughly $5-10/month. A Hostaccent Basic VPS is $7.99/mo with NVMe storage and root access. Music bots and sharded bots need more CPU and RAM, typically landing in the $12-25/month range.
How much RAM does a Discord bot need?
Most bots idle at 80-150MB and run comfortably on 1GB. Music bots need 2GB because audio encoding is memory- and CPU-hungry. Below 1GB, add swap — a 512MB box with no swap is the single most common cause of a bot being killed mid-operation.
Can I run a Discord bot on a server without a domain?
Yes. A bot makes outbound connections to Discord's gateway, so it needs no domain, no DNS record, and no inbound ports open beyond SSH. You only need a domain and SSL if you're adding a web dashboard or OAuth login flow.
How do I keep my bot running after I close SSH?
Use a process manager. PM2 is the usual choice: pm2 start index.js --name bot, then pm2 save and pm2 startup so it also survives reboots. Never rely on tmux or screen — when the session ends or the server restarts, the bot ends with it.
Do I need to know Linux to host a Discord bot on a VPS?
Basic comfort helps: SSH, editing a file, running a few commands. Everything in this guide is copy-paste. The learning curve is one evening. What you gain — persistent storage, no sleep, no hour caps, full control — is worth it for any bot a community actually relies on.
Written by The Hostaccent Team — Hostaccent Limited is a UK-registered hosting company (Companies House 11431799, incorporated 2018), trading since 2012, with 10,000+ websites launched and 4,000+ migrations behind it. Reviewed as of July 2026.










Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.