Measure your bot before choosing a plan
A VPS gives you control over the operating system and running processes. It also makes you responsible for updates, backups, and recovery. If you do not want that work, start with the managed options in our hosting guide.
Measure memory use, CPU, disk growth, and database traffic under a realistic workload. Leave room for restarts and busy periods. Voice, image processing, and large caches can change the requirements far more than the number of commands.
compare the full bill
Server + storage + backups + network costs
Check the recurring price for your chosen region and billing term. Include tax, IPv4 charges, traffic overages, and any snapshot or backup service you need.
A shortlist to compare
These are options to evaluate, not a performance ranking. Test the plan you would actually buy; a provider’s cheapest plan may use different hardware or have different limits from its other tiers.
| Provider | What to look at | Official plans |
|---|---|---|
| Hetzner | Shared or dedicated CPU; regional traffic allowance | Cloud plans |
| DigitalOcean | Droplet type, included transfer, backup charges | Droplet pricing |
| Vultr | Region, CPU type, storage, bandwidth | Cloud pricing |
| OVHcloud | VPS package, backup options, term and renewal price | VPS plans |
| Akamai / Linode | Shared or dedicated compute and transfer costs | Compute pricing |
| Contabo | Provisioning fees, CPU allocation, region and contract term | VPS plans |
For a light bot, compare entry-level shared CPU plans first. If CPU use stays high, test dedicated resources or move expensive jobs to a separate worker. More advertised RAM does not guarantee faster command responses.
Choose a region by testing the whole request
A bot talks to Discord and often to a database or third-party API. Place services close enough to avoid slow cross-region database calls, then measure command latency and connection stability. The nearest city to your members is not automatically the best host location.
Set up a host you can recover
Secure access
Use SSH keys, keep the operating system updated, and expose only required ports. A Gateway-only bot usually needs no public inbound application port.Run the bot as a service
Use a process manager or Docker with a restart policy. Keep tokens outside source control and avoid running the application as root.Save the recovery steps
Back up durable data, record how to deploy, and test a reboot. Rotate logs so a full disk does not take the service down.Add a few useful alerts
Watch repeated crashes, missing Gateway heartbeats, disk space, and command failures. An alert should tell you what needs attention.
For a repeatable setup, follow the Docker guide. Upgrade when measurements show a limit, rather than paying for unused capacity from day one.