Why Your Discord Bot Needs a Real Host (and How to Move It)
Your bot dies every time you close your laptop. Here is what dedicated bot hosting actually gives you, what it costs, and how to move an existing bot in about ten minutes.
Galaxy Nexus Team
Galaxy Nexus Hosting
Every bot developer hits the same wall: the bot works perfectly on your machine, then the laptop sleeps, the internet drops, or Discord kicks the bot offline at 2am because the process died and nobody restarted it. If you have ever told a server member "the bot will be back up when my PC turns on", you already know why hosting matters. This guide covers what bot hosting actually provides, what a bot really needs, and how to move a working bot in about ten minutes.
What a Bot Needs That Your PC Cannot Guarantee
A Discord bot is a long-running process. Its job only exists when it is connected. Three things separate a real host from a laptop:
| Requirement | Your PC | Dedicated hosting | |---|---|---| | Always-on connection | Dies on sleep, lid close, updates | 24/7 monitored uptime | | Stable latency to Discord | Tied to your home connection | Low, consistent, datacentre route | | Crash recovery | Manual reboot, if you notice | Automatic restart on failure | | Security baseline | Bot token sitting in your files | Token kept in the host's environment, never shipped to Discord |
Nothing about this is exotic. It is the same reason servers exist at all: processes that must stay up do not belong on a machine that goes to sleep.
The Real Cost of Self-Hosting
Self-hosting is not free, it is just unpaid. You pay in availability: every power cut, ISP outage, and OS update is downtime your members notice. You also pay in attention: a bot that crashes at 3am stays down until you happen to look at it.
What always-on looks like
Dedicated bot plans run your process on a server with automatic restarts and monitoring. Galaxy Nexus bot plans include Git deployment, auto-restarts, 24/7 monitoring, and a logs panel, with a 99.9% uptime target. Your bot restarts itself after a crash without anyone checking on it.
How Much Bot Do You Actually Need?
Discord bots are lightweight compared to game servers, but sizing still matters. Honest ballpark numbers for a single bot process:
- Simple moderation or utility bot: 256-512 MB RAM. Slash commands, roles, logging. This is most bots.
- Music bot: 512 MB to 1 GB. The queue cache and audio streaming hold more in memory than you expect.
- Bot with a database or Redis cache: add 256-512 MB for the supporting service.
- CPU: one vCPU is plenty for nearly every Discord bot. The bottleneck is almost never compute.
Buy for the peak, not the average. A music bot used hard for two hours a night still allocates for the full queue, and a swap-heavy bot is a laggy bot.
The One Thing That Gets Bots Hacked: The Token
If you have ever committed config.json or a .env file to a git repository, even a private one, treat that token as compromised and rotate it now. The token is the bot's password, and leaked tokens get scraped by bots scanning public repos within minutes.
The correct pattern is the same one used in production app development:
- Keep the token out of your source code entirely.
- Store it as an environment variable in your hosting panel.
- Never print it in logs, and never paste logs into a support channel without checking them for secret values.
# In your repo: .gitignore must include
.env
config.json
*.env# On the host: set the token in the panel's environment variables
DISCORD_TOKEN=your_token_hereRotate leaked tokens
If the token has ever been in a git commit, in a paste, or in a screenshot, generate a new one in the Discord developer portal and update the environment variable. Rotating takes two minutes. Rebuilding a bot whose token was stolen takes longer.
Moving an Existing Bot in Ten Minutes
If you already run a bot with node or python locally, the move is a small, reversible job:
- Push your code to a git repository (GitHub, GitLab, or similar). Remove any secret files first, then force-push over old history if they were ever committed.
- Create the bot hosting service and pick your runtime: Node.js for discord.js or discord.py (via Python) for most bots, matching whatever you run locally.
- Add your environment variables in the hosting panel:
DISCORD_TOKENand anything else your bot reads from.env. - Deploy from Git. Galaxy Nexus bot plans deploy straight from your repository, so a push triggers the build and restart.
- Check the logs panel for a clean startup. You are looking for the framework's "logged in" line, not just a process that is running.
- Invite it to a test server and run one command end to end.
Keep the local copy running until the hosted one passes a full day with no errors. Then shut it down, and you never have to keep your PC on for the bot again.
When Self-Hosting Still Makes Sense
Self-hosting is defensible in exactly two cases: you are prototyping and the bot being down does not matter, or you need hardware Discord bots cannot use (for example, GPU access for a bot that generates images). For anything the community depends on, a monitored host is cheaper than the goodwill you spend explaining the outages.
The test is simple. Ask yourself what happens when the bot goes down at 2am. If the answer is "someone will fix it", you are done here. If the answer is "it will wait until I notice", the bot should not be running on your machine.