Your bot works great on your laptop. Then you close the lid, or Windows decides it's update time at 3am, and suddenly half your server is asking why the music stopped and the welcome messages went quiet. Keeping a Discord bot online around the clock isn't hard, but there are a few setup details people skip that come back to bite them. Let's go through the real options and the bits that actually matter.
Why running it on your home PC is a bad idea
Almost everyone starts here. You write your bot, run node index.js or python bot.py, and it works. So you just leave the terminal open, right?
It works until it doesn't. Here's what goes wrong, and it always goes wrong at the worst time:
- Your PC reboots for an update overnight and the bot is gone until you notice.
- Your home internet hiccups, and a bot with a flaky connection gets rate limited or just drops offline.
- Closing the terminal window kills the process. So does sleep mode, which most laptops do automatically.
- You're paying for electricity to run a full desktop 24 hours a day so a tiny script can sit there.
And honestly, the bigger problem is that you become the uptime. If you go on holiday, the bot goes on holiday. If your power flickers, your community notices before you do. A bot that's only online when you're at your desk isn't really a 24/7 bot, it's a hobby that turns off when you sleep.
So the goal is simple. Get the bot onto something that stays on, restarts itself when it crashes, and comes back up on its own if the machine reboots. Let's look at where to put it.
Where to actually run it
A VPS
A virtual private server is the option most people land on, and for good reason. You get a small Linux machine that's always on, with its own IP, that you control over SSH. You install Node or Python, copy your files up, and run the bot the same way you would locally, except this box never sleeps.
The nice part is you're not limited to bots. The same VPS can host a small website, a database, a couple of other scripts. For a single Discord bot you don't need much. 1 GB of RAM is plenty for most bots, and even a busy bot rarely climbs past that unless it's caching a lot or running heavy commands. A small VPS plan handles a discord.py or discord.js bot without breaking a sweat.
Dedicated bot hosting
Some hosts give you a panel built specifically for bots instead of a raw Linux box. You upload your files, point it at bot.py or index.js, set your start command, and it handles the rest. No SSH, no systemd, no fiddling with process managers.
This is the easiest path if you don't want to learn server admin. At Bytte.cloud we run this through a Pterodactyl style panel at panel.bytte.cloud, so you get a console, a file manager and restart controls in the browser. It's a good fit if you just want the bot up and don't care how the sausage is made. The trade off is a bit less flexibility than a full VPS, but for most people that's a fair deal.
Free tiers
If you're testing or just running a small bot for a handful of friends, a free plan is a perfectly sensible start. We offer free starter bot plans, and plenty of people run their first bot on one for ages before they ever need to pay. A quick warning though: be careful with "free" hosts that sleep your app after a period of inactivity. A Discord bot needs a constant connection to Discord's gateway, so anything that puts your process to sleep when there's no web traffic will knock your bot offline. Make sure the free tier is actually built for always on processes, not just web apps.
A Raspberry Pi
This is a genuinely fun option if you like tinkering. A Raspberry Pi sitting in a drawer draws almost no power and can run a bot for years. A Pi 4 or 5 with a decent SD card (or better, boot from a USB SSD, SD cards die) will happily host several bots at once.
The catch is the same as your home PC, just smaller. It's still on your home internet, so if your connection drops, so does the bot. And if it's the only copy, an SD card failure means you lose everything. So back up your code and your .env somewhere off the Pi. For a learning project or a personal server bot, though, it's hard to beat.
Keeping it actually running
Picking the machine is half the job. The other half is making sure the process keeps running after you log out, and comes back if it crashes. Just running the script in your SSH session won't cut it, because the moment you disconnect, the process dies with your session.
pm2 for Node bots
If your bot is discord.js, pm2 is the easy answer. It runs your bot in the background, restarts it automatically if it crashes, and can bring it back after a reboot. Install it and start your bot like this:
npm install -g pm2
pm2 start index.js --name mybot
pm2 logs mybot
pm2 save
pm2 startup
That pm2 save plus pm2 startup combo is the part people forget. startup generates a command that registers pm2 with the system so it launches on boot, and save remembers which apps to bring back. Skip those two and your bot survives crashes but not a server reboot.
systemd for anything
On a Linux VPS, systemd is the most reliable way to run a long lived process, and it works for both Python and Node. You write a small service file and the system treats your bot like any other service. Here's a basic one for a Python bot:
[Unit]
Description=My Discord Bot
After=network.target
[Service]
WorkingDirectory=/home/bot/mybot
ExecStart=/home/bot/mybot/venv/bin/python bot.py
Restart=always
RestartSec=5
User=bot
[Install]
WantedBy=multi-user.target
Save that as /etc/systemd/system/mybot.service, then run:
sudo systemctl daemon-reload
sudo systemctl enable mybot
sudo systemctl start mybot
sudo systemctl status mybot
The two lines doing the heavy lifting are Restart=always and RestartSec=5. If the bot crashes, systemd waits five seconds and starts it again. The enable command makes it start on boot. In our experience this is the setup that just keeps working with the least babysitting, which is why it's our default for anything serious.
screen and tmux
You'll see a lot of guides telling you to run your bot inside screen or tmux. These keep a terminal session alive after you disconnect, so you can start the bot, detach, and log out without killing it. Start one with tmux new -s bot, run your bot, then press Ctrl+b then d to detach. Reattach later with tmux attach -t bot.
They're handy, and great for watching live output. But be honest with yourself about what they do and don't do. A tmux session keeps your bot running after you log out, but it does not restart the bot if it crashes, and it does not survive a reboot. So treat screen and tmux as a convenience for live debugging, not as your real uptime plan. For 24/7, use pm2 or systemd. Use tmux when you want to sit and watch the logs scroll.
Auto restart on crash
Every bot crashes eventually. An unhandled error, a bad API response, a memory spike, Discord having a wobble. The difference between a reliable bot and a frustrating one is whether it gets back up on its own.
That's the whole point of pm2 and systemd. Both watch the process and relaunch it when it dies. One thing worth adding: if your bot crashes on a real bug, it'll just crash again instantly, and a tight restart loop can hammer Discord's API and get you rate limited. The RestartSec=5 delay in the systemd file helps, and pm2 has similar backoff built in. Still, set up logging so you can actually see why it crashed. With systemd, journalctl -u mybot -f shows you live logs. Auto restart hides the symptom. Logs let you fix the cause.
The token mistake that catches everyone
This is the one I'd put in bold if I could only give you one piece of advice. Never put your bot token directly in your code, and never commit it to a Git repo.
Your token is the password to your bot. Anyone who gets it can take it over completely. And people leak these constantly by pushing code to a public GitHub repo with the token sitting right there in bot.py. Bots scan GitHub for exactly this, so a leaked token can be abused within minutes. Discord also auto invalidates tokens it spots in public repos, so at best your bot just stops working.
The fix is easy. Put the token in a .env file:
DISCORD_TOKEN=your-token-here
Then load it in your code. In Python with python-dotenv:
import os
from dotenv import load_dotenv
load_dotenv()
token = os.getenv("DISCORD_TOKEN")
And the part people forget: add .env to your .gitignore so it never gets committed in the first place.
.env
node_modules/
__pycache__/
If you ever do leak a token, don't panic and don't try to delete the commit. Just go to the Discord developer portal and regenerate the token right away. The old one dies instantly and the leaked copy is useless. Then update your .env on the server.
Putting it together
A bot that's properly online 24/7 comes down to a few choices, none of them complicated. Run it on something that stays on, whether that's a VPS, a panel built for bots, a free starter plan, or a Raspberry Pi humming away in a drawer. Wrap it in pm2 or systemd so it restarts on crashes and survives reboots. Keep your token in a .env file and out of Git. And check your logs now and then so you catch problems before your members do.
Start small. A free plan or a cheap VPS is more than enough to learn on, and you can always move up when your bot outgrows it. The setup you build today will quietly keep running long after you've forgotten the details, which is exactly what you want.



