The Cheapest Way to Host a Discord Bot, Honestly Compared

A Discord bot holds a persistent WebSocket connection to Discord’s gateway. That single requirement — a process running continuously, not one that wakes on an incoming request — is what eliminates most free hosting, because free tiers are usually built around sleeping when idle and a sleeping bot is an offline bot.

The gateway connection is not optional for a bot that responds to messages or events. Discord pushes events to you over that socket, and if the process is not there to receive them, they are simply missed. Understanding that constraint first makes the hosting comparison much shorter, because it rules out about half the options people suggest.

Table of contents

• What the bot actually needs
• The options, and what each really costs
• The keep-alive hack, and why to skip it
• Keeping the bot alive in practice
• Costs people forget
• A recommendation by situation
• How this fits the rest of the stack
• FAQ

What the bot actually needs

• A process running continuously. Not on-demand, not scheduled, not sleeping after fifteen minutes of inactivity.
• Outbound network access. Discord’s gateway and API. No inbound ports required, which is genuinely helpful — nothing to expose or firewall.
• Modest CPU and memory. A bot handling a few servers idles at well under a hundred megabytes and near-zero CPU. Most of its life is waiting on a socket.
• Automatic restart on crash. Every bot crashes eventually — an unhandled rejection, a gateway disconnection handled badly, a memory leak.
• Somewhere for state, if it remembers anything. A file works for one instance; a database is needed as soon as you have more than one.
• Secrets held somewhere other than the source. The bot token is a full credential for the bot account.

The one exception to the always-on rule is a bot built entirely on Discord’s HTTP interactions endpoint. Discord posts slash commands to a URL you provide, which means a request-driven deployment works and can genuinely sleep between invocations. If your bot only responds to slash commands and never needs to observe events, that changes the hosting question completely and is worth knowing before you pick anything.

The options, and what each really costs

A spare computer at home. A Raspberry Pi, an old laptop, a machine already running. Hardware cost is a one-off in the tens of dollars, electricity is negligible for a small board.

Genuinely the cheapest in cash terms, and the honest caveats are: your home internet uptime becomes your bot’s uptime, a power cut takes it down until you are back, and you own the operating system updates. For a bot serving your own friends, entirely reasonable. For anything other people rely on, the availability is what you are paying for and you are not paying for it.

A small VPS. A few dollars a month for the smallest instance, which is far more than a bot needs.

Full control, predictable cost, and the flip side: you own the operating system, the security updates, the process supervision, and the restarts. The bot is five minutes of work; the server is a standing commitment. Perfectly fine if you already run one for something else, since the marginal cost of adding a bot to an existing VPS is essentially zero.

A platform that runs a process from a repository. You push code, it builds and runs the process, it restarts on crash, secrets live in environment variables, and logs are available without SSH.

Costs more per month than the raw compute would, and removes the operating system entirely. For a bot, this is usually the right trade, because bots are small and the operational overhead is the actual expense.

Free tiers. Real, and usually constrained in exactly the way that breaks a gateway bot: sleeping after idle, monthly hour caps that do not cover a full month, or cold starts. Read the always-on terms specifically rather than the headline. Some free tiers do allow a continuously running process within a monthly allowance, and those work.

The keep-alive hack, and why to skip it

A widely shared trick: run the bot somewhere that sleeps, add a tiny web server, and point an external uptime monitor at it every few minutes so the platform sees traffic and does not idle the process.

It works, sometimes, and it is a bad idea for three reasons.

• It usually violates the platform’s terms, which describe the free tier as being for request-driven workloads. Getting the account suspended costs more than the few dollars you saved.
• It is unreliable in a specific unhelpful way: the bot goes down at unpredictable intervals when the ping is late or the platform idles it anyway, so you get an intermittent failure that is tedious to diagnose.
• It adds an HTTP server, an external monitor, and a dependency between them — three moving parts to avoid paying a small monthly amount.

If the budget is genuinely zero, the spare-computer route is more honest and more reliable than the keep-alive route. If a few dollars a month is available, pay it and delete the ping.

Keeping the bot alive in practice

Whatever you choose, two things separate a bot that stays up from one that needs babysitting.

A supervisor that restarts on exit. On a VPS that is systemd; on a platform it is built in.

[Unit]
Description=Discord bot
After=network-online.target

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/mybot
EnvironmentFile=/opt/mybot/.env
ExecStart=/usr/bin/node index.js
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Restart=always with a delay is the whole feature. EnvironmentFile keeps the token out of the unit file and out of your repository.

Handling gateway disconnections properly. Discord will disconnect you — for maintenance, for rate limits, for network reasons. Library reconnection logic handles most of it, but unhandled errors will still kill the process:

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

client.on('error', (err) => console.error('Client error:', err));
client.on('shardDisconnect', (e, id) =>
  console.warn(`Shard ${id} disconnected: ${e.code}`));
client.on('shardReconnecting', (id) =>
  console.log(`Shard ${id} reconnecting`));

An unhandled promise rejection terminates a Node process by default in current versions. A bot without that handler dies on the first unexpected API error, and the supervisor restarts it in a loop that looks like flapping infrastructure but is really one missing listener.

Costs people forget

• State. The moment the bot remembers anything across restarts, you need storage. A file on a container filesystem disappears on redeploy. A managed database is a separate line item.
• Growth. A bot in five servers and a bot in five thousand are different programs. Past a threshold Discord requires sharding, which means multiple gateway connections and real coordination.
• Your time. The recurring cost on a self-managed box: updates, the evening it stopped and nobody noticed, working out why it is using two gigabytes of memory.
• Monitoring. Knowing the bot is down before your users tell you. External and cheap, but not automatic.
• Bandwidth, if the bot moves media. Text commands are negligible; an audio bot is a different profile entirely.

That third item usually dominates. A VPS at a few dollars a month plus three hours of your attention a year is not cheaper than a managed plan unless your time is free — and it is worth being honest about that rather than comparing only the invoice.

A recommendation by situation

• Learning, or a bot for your own server — a spare computer or a Raspberry Pi. Zero marginal cost and you learn how it runs.
• Slash commands only, no gateway events — a request-driven deployment on a free or near-free tier. This is the genuinely cheap path and most people do not realise they qualify.
• A bot other people depend on — a small managed plan. The few dollars buys restart-on-crash, logs, and secrets management you do not maintain.
• You already run a VPS — put it there. The marginal cost is nothing.
• A bot with a database, growing — a platform where the bot and its database sit together, so the connection is private and both scale.

The general shape: cheapest in cash is a device you own; cheapest overall, once your time counts, is a small managed plan; and cheapest of all is discovering that your bot only needs slash commands and never needed an always-on process.

How this fits the rest of the stack

A Discord bot is a long-running process from a repository with a token in an environment variable and a database beside it if it remembers anything — which is exactly the shape RunxBuild services take. Node and Python services deploy from GitHub with build logs, environment variables for the bot token, runtime logs, and rollback to the previous deploy, with a managed MySQL or Postgres alongside on private networking rather than a separate account. The general plan ladder starts at $1.80 after the free days each month and reaches $6 for a Basic plan, which is more than a small bot needs. Node services on RunxBuild covers the runtime, and the RunxBuild hosting calculator shows the service, the database, storage, and bandwidth separately so you can see what the bot plus its state actually costs.

Useful related references:

• Can You Make a Discord Bot with Next.js? Yes, With One Important Caveat
• Discord Webhook Not Working With GitHub: The Missing /github Suffix
• Self-Hosted Discord: The Four Real Alternatives, the Federation Story, the Cost Calculation, and the One Reason Teams Switch
• Services on RunxBuild

FAQ

What is the cheapest way to host a Discord bot?

In pure cash terms, a device you already own — a Raspberry Pi or an old laptop. You pay in availability, since your home internet and power become the bot’s uptime. Once your own time counts, a small managed plan that restarts on crash and handles secrets is usually cheaper overall.

Can I host a Discord bot for free?

Sometimes. Most free tiers sleep idle processes, which breaks a bot that holds a gateway connection. Read the always-on terms specifically. If your bot uses only slash commands via Discord’s HTTP interactions endpoint, it is request-driven and a free tier genuinely works.

Why does my Discord bot keep going offline?

Either the host is idling the process, or the bot is crashing and not restarting. Add an unhandledRejection handler — an unhandled promise rejection terminates a Node process by default — and make sure a supervisor restarts it, with Restart=always under systemd or the platform’s built-in restart.

Is the keep-alive ping trick a good idea?

No. It usually violates the platform’s terms for a free tier, it fails intermittently when the ping is late or the platform idles the process anyway, and it adds an HTTP server plus an external monitor to avoid paying a few dollars. A spare computer is a more honest zero-budget option.

How much CPU and memory does a Discord bot need?

Very little. A bot serving a few servers idles at well under a hundred megabytes with near-zero CPU, because it spends most of its life waiting on a socket. The requirement that costs money is continuous uptime, not capacity — which is why sizing is rarely the constraint.