minecraft bot hosting
Minecraft bot hosting without per-bot fees
The worker is a single Node.js process. Run it on a cheap VPS, add its URL and token to the dashboard, and you have your own bot cloud with a proper control panel.
Several nodes, one dashboard
Spread bots across VPS locations and watch CPU and RAM per node.
Survives reboots
The worker restores running bots on start, with staggered joins.
Token-protected
Every request to a node needs your bearer token. Put it behind HTTPS with a reverse proxy.
What you need
Any VPS with Node.js 20 or newer. A small 1 to 2 GB machine is enough for a few dozen idle bots. You run one worker process, pick a secret token and open a port for the dashboard.
Connect it in a minute
Start the worker with a token, then add the node in the dashboard with its URL and token. The dashboard checks the connection, shows CPU and RAM, and lets you choose that node whenever you create a bot.
Keep it secure and running
Put the worker behind HTTPS with a reverse proxy or restrict the port to the dashboard's IP. Run it under systemd or pm2 so it restarts on boot. The worker restores running bots after a restart and staggers the joins.
Cloud node or your own VPS
The cloud node is the fast path: nothing to install, and the bots run on our servers from the moment you press start. It fits most people who run a handful of bots.
A VPS of your own makes sense when you run many bots, want a specific location close to the game server, or prefer to keep control of the machine. You install the worker once, paste its token into the dashboard and manage everything from the same list as before.
How much a VPS needs
Idle bots are light. As a rough guide, a VPS with 2 GB of RAM runs somewhere between 40 and 80 idle bots, and fewer when they pathfind, farm or fight. Measure on your machine: the Nodes page shows CPU, memory and uptime, so you can see when it is getting full.
A small Linux VPS with 1 to 2 GB, Node.js 20 or newer and a reverse proxy for HTTPS is enough to start. Add a second node when CPU stays high.
Install the worker
The worker is a Node.js program using Mineflayer. Install its dependencies, set a long random token and a port, and start it. A systemd unit keeps it running after a reboot or a crash, and it writes its running bots to disk so it can start them again with a delay between each join.
The step-by-step guide on the blog has the exact commands and a ready systemd unit.
Security and uptime
The token travels with every request, so never expose the worker over plain HTTP on the open internet. Put Caddy or nginx in front with a certificate, or allow only the dashboard server in the firewall. Keep the token out of shared scripts and repositories.
For uptime, rely on systemd restarts and watch the node status. If a node goes offline, the dashboard shows it, and its bots restart when it returns.
Proxies and many accounts
Many accounts behind one IP can trigger join throttling. Give each bot a proxy, or let the dashboard assign them from a list. SOCKS5 is the usual choice, and an HTTP proxy works only if it allows CONNECT on the Minecraft port.
A proxy far from the game server adds latency, so choose one close to it.
Cost compared with per-bot hosting
Some hosts charge for every bot. On your own VPS you pay for the machine, not per bot, so the cost per bot drops as you add more. The dashboard plan covers the control panel, so you keep the cheap VPS and the convenience.
Common questions
Do I pay per bot on my own VPS?
No. You pay your hosting provider. The plan only limits how many bots and nodes you can manage from the dashboard.
Can I use several VPS locations?
Yes. Add several nodes and pick the one closest to each Minecraft server for lower latency.
Is the worker open source?
The worker is plain Node.js code using Mineflayer that you can read and change.
Which VPS provider should I use?
Any Linux VPS works. Pick a location close to the game server and a plan with at least 1 to 2 GB of RAM.
Can I move bots between nodes?
Yes. Stop a bot, change its node in the settings and start it again.
Do I need to know Linux?
Basic commands are enough. The guide lists them, and the cloud node needs none.
What happens if my VPS reboots?
With the systemd unit, the worker starts on boot and restores its bots with a delay between each join.
Is my token safe?
Treat it like a password. Use HTTPS or a firewall rule so it never travels in the clear.