Crypto Trading Bot Hosting

A trading bot must be reachable and running while you sleep, because crypto exchanges never close — and a VPS gives the process a datacenter connection, a static IP and automatic restart instead of a laptop that sleeps, updates and loses Wi-Fi. For bot frameworks like Freqtrade and Hummingbot, which poll exchange APIs every few seconds, steady uptime matters more than microsecond latency; the datacenter line just has to never blink.

• 24/7 polling: the bot keeps quoting, cancelling and re-placing orders overnight without you online.
• One static IPv4: the exchange's API key can be allow-listed to exactly that address.
• Root access: you install Python or Docker yourself and run the bot under its own user, not root.
• Survives reboots: systemd or a Docker restart policy brings the bot back after a crash or host restart.

The scope line matters: WebJi®'s crypto trading VPS is the server. You install the bot, pick the strategy and keep your funds on the exchange — WebJi® holds no coins, runs no strategies and sends no orders. If you trade forex or indices on MetaTrader rather than crypto APIs, the setup differs: see installing MT4 and MT5 on a VPS.

Install Ubuntu, run the bot as its own non-root user, and prove it in dry-run or paper mode for days before the first live order — that sequence is the whole method.

1. Order Ubuntu on a Linux VPS, sign in over SSH, and note the public IPv4 — the exchange key will be locked to it. Key setup is covered in generating an SSH key on Ubuntu.
2. Update packages, install Python 3 or Docker, and create a non-root user for the bot; the steps are in adding a sudo user on Ubuntu.
3. Freqtrade: follow the project's install, write the config with the exchange in dry-run, and start it — the log showing the bot loop with no API error is the pass mark.
4. Hummingbot: follow the project's Docker install, connect the exchange with a trade-only key, and start in paper mode until the connector shows online.
5. Add a systemd unit or a Docker restart policy, then reboot the VPS once deliberately: the bot must be running again without anyone logging in.

A minimal systemd unit for Freqtrade looks like this — the point is Restart=on-failure:

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

[Service]
User=freqtrade
ExecStart=/home/freqtrade/freqtrade/.venv/bin/freqtrade trade --config /home/freqtrade/config.json
Restart=on-failure

[Install]
WantedBy=multi-user.target

Container fans can run the same discipline with Docker's --restart unless-stopped flag; the broader container workflow is in Docker hosting.

An order the exchange has already accepted stays open — the bot process merely stops until systemd or Docker starts it again, then reads open orders back from the API. The risk is the gap before that reconnect, which is exactly what the reboot test measures.

Reboot once while still in dry-run and confirm the bot returns on its own before enabling live trading. Take a snapshot before changing the strategy or the operating system, so a bad change costs minutes, not the whole setup. WebJi® publishes a 99.9% uptime target; if a machine stays down, email support@webji.services — replies come 24/7 in Hindi and English, with an average first reply under 60 minutes. The office phone is not a trading hotline.