“Bot hosting” is a category, not a single product. It covers Discord bots, Telegram bots, Slack apps, WhatsApp integrations, custom chatbots, automation workers, and any other long-lived process that needs to be always-on, responds to events, and does not serve HTTP. The hosting decision is different from a website: the bot needs uptime, not bandwidth; memory, not CPU; a long-lived process, not a request-response loop. The free tiers that work for websites usually do not work for bots, and the cost of always-on is the cost the marketing pages hide. This post is the unblocker.
The interesting thing about “bot hosting net” is that the searcher usually wants to know one of three things: “where can I host my Discord bot for free?”, “what does it cost to host a bot on a real platform?”, or “should I just run it on my laptop?” The answer to all three is the same shape, and the shape is what this post covers.
The most common trap: the team picks a “free” bot hosting service, the bot works for 7-14 days, the trial ends, the service starts billing, the team forgets, the bill arrives. The pattern is well-documented in the r/Discord_Bots threads, and the fix is to understand the cost model before the trial starts. The cost of always-on is the cost. The free tier is a trial. The platform that hides this is a platform the team should not use.
Table of contents
- The direct answer
- What “bot hosting” actually means
- The three layers of bot hosting
- Layer 1: the free bot-hosting services
- Layer 2: small VPSs and the real cost of always-on
- Layer 3: a modern PaaS with always-on support
- The “free” trap: the trial that becomes a bill
- The self-host question: should I just run it on my laptop?
- The opinion this post is built on
- FAQ
The direct answer
For a Discord bot or a Telegram bot:
- Free, with a trial: A free bot-hosting service like Replit, Bot-Hosting.net, or a community Discord’s free hosting. The free tier is a trial. The bot works for 7-14 days, then the service asks for a credit card or kills the bot. Read the trial terms.
- Cheap, ongoing: A small VPS from Hetzner, OVH, or DigitalOcean for $3-5/month. The team operates the server. The bot is always-on. The cost is the team’s time.
- Managed, ongoing: A modern PaaS with always-on support (the RunxBuild platform, Railway, Render). The bot is a long-lived process. The platform handles the server. The cost is $5-10/month plus usage.
The right answer depends on the team’s operational capacity, the bot’s traffic, and how long the team is willing to commit. The trap is the “free” tier that bills after the trial. The fix is to read the terms.
What “bot hosting” actually means
A bot is a long-lived process. It connects to an external service (Discord, Telegram, Slack), listens for events, and reacts. The bot does not serve HTTP, but it consumes memory and CPU. The bot is always-on, which means the server is always-on, which means the cost is monthly, not per-request.
The differences from a website:
- A website serves HTTP requests. It is request-response. A website can scale to zero when there are no requests, then scale up when traffic returns. The cost is per-request, mostly.
- A bot is a long-lived process. It maintains a connection to the external service. It listens for events. It is always running. The cost is per-hour, regardless of activity.
- A website is bursty. Traffic comes in waves. The server handles the wave, then idles. The cloud bill reflects the burstiness.
- A bot is steady. The bot is running whether there is activity or not. The cloud bill is the same at 3am as it is at 3pm.
The hosting decision follows from the difference. A bot needs always-on infrastructure, not bursty infrastructure. A bot needs memory and CPU, not bandwidth. A bot needs process supervision, not request handling. The platform that is good for a website is not automatically good for a bot.
The trap: the platform that offers a “free tier” for websites (Vercel, Netlify) often does not support always-on processes. The free tier is for static sites and serverless functions, which scale to zero. A bot cannot run on a platform that scales to zero, because the bot is the thing that is always on. The team that deploys a bot to a serverless platform spends a week debugging why the bot disconnects every 15 minutes.
The three layers of bot hosting
The three layers of bot hosting, from cheapest to most managed:
Layer 1: free bot-hosting services. A handful of services (Replit, Bot-Hosting.net, a community Discord’s free tier) provide always-on processes for free, usually with a 7-14 day trial. The free tier is a trial. The team that needs the bot to keep running past the trial pays.
Layer 2: small VPSs. A Hetzner or OVH VPS for $3-5/month. The team operates the server, installs the bot, sets up process supervision (PM2, systemd), and configures the firewall. The cost is the team’s time.
Layer 3: a modern PaaS with always-on support. The RunxBuild platform, Railway, Render, Fly.io. The bot is a long-lived process. The platform handles the server, the build, the deploy, the SSL, the monitoring. The cost is $5-10/month plus usage.
The right answer depends on the team. Layer 1 is right for a prototype. Layer 2 is right for a team with operations experience. Layer 3 is right for a team that wants to focus on the bot, not the infrastructure.
Layer 1: the free bot-hosting services
The free services are real, and they work for prototyping. The trial terms vary:
- Replit. Free tier supports always-on processes for a limited time. The team can deploy a Node or Python bot and run it for free. The catch: the free tier sleeps the bot after inactivity, and the always-on feature requires Replit Core ($7/month).
- Bot-Hosting.net and similar services. Free tier with 7-14 day trial, then paid. The terms are usually “free for X days, then $X/month.”
- Community Discord servers. Some bot communities offer free hosting for verified bots. The terms vary.
The trap: the free tier is a trial, not a free tier. The team that deploys a bot to a free service, gets the bot working, and forgets about the trial receives a bill a month later. The bill is small ($5-20), but the team that did not budget for it is surprised.
The fix: read the trial terms before the deploy. The platform’s docs are explicit about the trial length, the post-trial cost, and the cancellation process. The team that reads the terms is the team that does not get surprised. The team that does not read the terms is the team that learns the hard way.
The deeper trap: the free service may not be reliable. The team that runs a production bot on a free service is at the mercy of the service’s uptime, the service’s terms, and the service’s customer support. A paid service has a contract; a free service has a “best effort” promise. The team that needs a reliable bot for a community of 1000+ users should not run it on a free service.
Layer 2: small VPSs and the real cost of always-on
A small VPS is the right answer for a team that wants always-on infrastructure and is willing to operate the server. The cost is the team’s time, not the platform’s.
The setup:
- Provision a VPS (Hetzner, OVH, DigitalOcean, Vultr) for $3-5/month. 1GB of RAM is enough for most bots.
- SSH in. Install the runtime (Node, Python, etc.) and the bot’s dependencies.
- Set up process supervision (
pm2,systemd, or a Docker container). - Configure the firewall (allow only the ports the bot needs).
- Set up auto-updates (
unattended-upgradesfor security patches).
The cost is $3-5/month. The operational work is a few hours per month for security patches, log rotation, and the occasional debug.
The trap: the bot’s resource use. A bot that connects to Discord, listens for events, and stores data in memory is small. A bot that runs machine learning, processes images, or maintains a large cache is not. The team that underestimates the bot’s resource use buys a 1GB VPS, hits the memory limit, upgrades to 2GB, hits again, and ends up with a 4GB VPS that costs $20/month. The resource estimation is the part most teams get wrong.
The fix: monitor the bot’s memory and CPU. Most VPSs come with monitoring. The team that watches the metrics catches the resource creep before it costs money. The team that does not watch the metrics is surprised when the bot OOMs.
Layer 3: a modern PaaS with always-on support
A modern PaaS that supports always-on processes is the right answer for a team that wants to focus on the bot, not the infrastructure. The platform handles the server, the build, the deploy, the SSL, the monitoring, and the scaling. The cost is the platform’s fee, not the team’s time.
The options:
- The RunxBuild platform. Always-on processes are first-class. The bot is a long-lived service. The platform handles the build, the deploy, the SSL, the monitoring, and the secrets. The cost is $5-10/month plus usage.
- Railway. Always-on processes are supported. The cost is usage-based, around $5/month for a small bot.
- Render. Always-on processes via “background workers.” The cost is $7/month for a small worker, plus the database if the bot needs one.
- Fly.io. Always-on processes are supported. The cost is usage-based, around $5/month for a small bot.
The trade: the cost is higher than a raw VPS, and the operational work is lower. The team that values its time picks the PaaS. The team that values its budget and has the operations capacity picks the VPS.
For a sanity check on the cost, the hosting cost calculator gives a real number to compare against. The cheapest platform is rarely the one that respects the team’s time.
The “free” trap: the trial that becomes a bill
The pattern is well-documented in r/Discord_Bots:
- The team deploys a bot to a free service.
- The bot works. The team is happy. The bot is in production, serving 100+ users.
- The trial ends (7-14 days, sometimes 30).
- The service sends an email: “Your trial has ended. You are now on the $X/month plan. To cancel, visit your dashboard.”
- The team does not check the email. The service starts billing.
- A month later, the service charges the team’s credit card. The charge is $5-20.
- The team is surprised. The team cancels. The bot goes down. The community is unhappy.
The fix is simple: read the trial terms before the deploy. The platform’s docs are explicit. The team that reads the terms is the team that does not get surprised. The team that does not read the terms is the team that learns the hard way.
The deeper fix: budget for the cost. A bot that is in production, serving users, has a cost. The cost is $5-20/month, depending on the platform. The team that budgets for the cost is the team that does not get surprised. The team that does not budget for the cost is the team that is surprised when the bill arrives.
The self-host question: should I just run it on my laptop?
The pattern:
- The team runs the bot on a laptop.
- The laptop is on when the team is awake.
- The bot is offline when the team is asleep.
- The bot is offline when the laptop is in sleep mode.
- The bot is offline when the team travels.
- The community notices the offline time. The community complains.
The fix: a server that is always on. The cheapest always-on server is a $3-5/month VPS. The most convenient always-on server is a modern PaaS. The most expensive always-on server is the team’s laptop power bill.
The trap: the laptop also runs the team’s other work. The bot competes with the team’s IDE, the team’s browser, the team’s video calls. The bot’s memory use is the laptop’s memory use. The bot’s CPU spikes are the team’s slow compile. The team that runs the bot on the laptop is the team that resents the bot.
The fix: the bot runs on a server. The laptop runs the team’s work. The bot is always on. The team is happy.
The opinion this post is built on
“Bot hosting” is a category that the cloud has gotten much better at over the last five years. The free trials are more honest, the small VPSs are cheaper, the PaaS options are more capable. The team that picks a real hosting option is the team that has a bot that is always on, that the community can rely on, and that the team does not resent.
The “free” tier is a trial. The team that understands this is the team that budgets for the cost. The team that does not understand this is the team that learns the hard way. The cost is $5-20/month, depending on the platform. The cost is real, and the cost is worth it for a bot that serves a community.
The platform is the multiplier. A platform that supports always-on processes, that exposes the resource use, and that bills honestly is a platform where the bot is a deployable service. A platform that does not support always-on processes, that hides the resource use, or that surprises the team with a bill is a platform where the bot is a fight.
The RunxBuild platform is built for always-on services. The bot is a service. The platform is the right home. The team that wants a boring answer picks a platform that does always-on well, and the boring answer is the right one for most bots.
FAQ
Where can I host a Discord bot for free?
A handful of services (Replit, Bot-Hosting.net, community Discord servers) offer free tiers for prototyping. The free tier is a trial (7-14 days, sometimes 30). The team that needs the bot to keep running past the trial pays. Read the trial terms before the deploy.
What is the cheapest way to host a bot long-term?
A small VPS (Hetzner, OVH, DigitalOcean) for $3-5/month. The team operates the server, installs the bot, sets up process supervision, and configures the firewall. The cost is the team’s time. For a managed option, a modern PaaS with always-on support is $5-10/month plus usage.
Can I host a bot on Vercel or Netlify?
No, not in the way most people mean. Vercel and Netlify are serverless platforms that scale to zero. A bot is a long-lived process that needs to stay connected to an external service. The serverless platform will disconnect the bot, the bot will lose its session, and the bot will not work. Use a platform that supports always-on processes (the RunxBuild platform, Railway, Render, Fly.io, a small VPS).
Should I just run the bot on my laptop?
No. The laptop is off when you sleep, off when you travel, and off when the battery dies. The bot is offline when the laptop is offline. The community notices. The team that wants a bot that is always on runs the bot on a server, not on a laptop.
What is the difference between a bot and a website in hosting terms?
A website serves HTTP requests and can scale to zero. A bot is a long-lived process that maintains a connection to an external service. The hosting cost reflects the difference: a website is paid per-request (mostly), a bot is paid per-hour. The platform that is good for one is not automatically good for the other.
How do I avoid the “free trial that becomes a bill” trap?
Read the trial terms before the deploy. The platform’s docs are explicit about the trial length, the post-trial cost, and the cancellation process. Budget for the post-trial cost. Cancel the trial if the bot is not worth the cost. Do not deploy a bot to a free service and forget about the trial.