A crypto trading bot VPS is a cloud server that runs your bot, such as Freqtrade or Hummingbot, without depending on your home computer, Wi-Fi or power. Crypto markets never close, so a bot that stops when your laptop sleeps misses everything in between. Many traders in Southeast Asia look at Singapore, Tokyo and Hong Kong for this job, because these cities sit close to the region and to many exchange services. This guide shows how to pick between them by measuring rather than guessing, how to protect the exchange API keys that live on the server, and how to keep the bot running through reboots. It does not promise profits or speed: a server keeps your bot online and close to an API, nothing more.
What a crypto trading bot VPS needs to provide
Trading bots are mostly light on hardware. They poll or stream market data, compute signals, and send orders over HTTPS or WebSocket. What they need is:
- Continuous uptime of the process. The bot should restart by itself after a crash or reboot.
- A stable network path to the exchange API. Fewer hops and a shorter distance help consistency.
- Accurate time. Signed API requests carry a timestamp, and exchanges commonly reject requests when the server clock drifts.
- A fixed outbound IP. Many exchanges let you restrict an API key to specific IPs, which only works if the server keeps the same address.
- Enough RAM for backtesting, if you do it there. Live trading is light; backtests and hyperparameter optimisation are not.
A Cloudj server keeps its IP for as long as the server exists, so it fits the allowlisting step below.
Measure first: which city is closest to your exchange?
Exchange APIs are often served through content delivery networks or load balancers, and the hostname you call may resolve to different places from different cities. The marketing page of an exchange will not tell you where your requests land. Measure instead.
Deploy a small hourly server in each candidate city: Singapore, Tokyo and Hong Kong. Then, on each one, time requests to the exact API host your bot uses:
for i in $(seq 1 20); do
curl -o /dev/null -s -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
https://api.example-exchange.com/
done
The three columns show TCP connect time, TLS handshake time and total time per request. Compare the medians, not the single best result, and repeat at different hours. Add mtr --report api.example-exchange.com to see the route. Our guide on testing VPS latency with ping and mtr explains the output, and the Singapore vs Hong Kong vs Tokyo comparison covers the cities more broadly.
Delete the servers you do not keep. Hourly servers are charged while they exist, even when stopped, because the disk and IP remain reserved.
Reading the results
| If you see | It usually means | What to do |
|---|---|---|
| One city clearly faster across hours | The API endpoint is served near that city | Keep that city |
| All three similar | The API is behind a widely distributed network | Choose on other factors: price, region of your other servers |
| Large swings at certain hours | Congestion on a route or at the exchange | Test longer before deciding; make the bot tolerant of slow responses |
Also check the exchange's terms on which countries may access its API. Some exchanges restrict users or IP ranges from certain regions. Follow each exchange's rules; a server location is not a way around them.
The three cities at a glance
All three Asian locations offer the same server range on Cloudj: from 1 vCPU and 1 GB RAM up to custom sizes, 30 ready-made plans, shared, general purpose or dedicated CPU, and 1 TB of traffic included on monthly plans.
- Singapore is a common hub for Southeast Asia and a natural default if you are in Vietnam, Thailand or Indonesia. See the Singapore VPS overview and the Singapore cloud server page.
- Tokyo suits bots that talk to services hosted in Japan, and it pairs well if you also serve users in Japan. See the Japan VPS overview and the Japan cloud server page.
- Hong Kong is close to Greater China and many regional networks. See the Hong Kong VPS overview and the Hong Kong cloud server page.
The Asia VPS guide compares the Asian locations in more depth if you want the full picture.
Protect the API keys on your server
A bot server holds credentials that can move money. Treat it that way.
- Never enable withdrawals on a bot key. Trading permission is all a bot needs.
- Restrict the key to the server's IP in the exchange's API settings. A leaked key is then useless from anywhere else.
- Log in with SSH keys only and disable password login. Our SSH key setup guide walks through it.
- Close every port you do not use. A bot makes outbound connections; it rarely needs inbound ports except SSH.
- Keep keys out of shell history and git. Store them in the bot's config file with
chmod 600, owned by a dedicated non-root user. - Patch the OS regularly. The new VPS security checklist covers the basics.
If you use the Freqtrade web UI, keep it bound to localhost and reach it through an SSH tunnel from your own computer, then open http://127.0.0.1:8080 in your browser:
ssh -L 8080:127.0.0.1:8080 user@your-server-ip
Keep the bot running
Check that the clock is synchronised:
timedatectl status
Look for "System clock synchronized: yes". Then run the bot so it restarts on its own. Docker with a restart policy is the simplest route for Freqtrade and Hummingbot, both of which publish Docker setups; the Docker install guide gets the engine ready. Freqtrade's own documentation covers configuration and dry-run mode, which you should use before trading real funds.
Watch CPU, RAM and network graphs in the console for the first days. If backtests push memory too hard, resize CPU and RAM or run backtests on a separate hourly server that you delete afterwards.
Sizing and billing
A single live bot usually runs comfortably on a small general purpose plan, such as 1 to 2 vCPU with 2 GB RAM. Several bots, many pairs, or local backtesting call for more memory and possibly dedicated CPU. Start small, watch the graphs, and resize. Once you know the city and size, a 1, 3, 6 or 12 month term with auto-renew fits a server that must not stop. See live prices on the pricing page.
FAQ
Which is better for a crypto bot, Singapore, Tokyo or Hong Kong?
The one with the steadiest measured response times to your exchange's API host. Run the curl test from all three before deciding.
Will a VPS make my trading bot profitable?
No. A VPS keeps the bot online and can shorten the path to the API. Strategy, fees and market conditions decide results.
How much RAM does a trading bot need?
A single live bot is light; 2 GB is a common starting point. Backtesting and optimisation need much more, so size for what you run on the server.
Can I whitelist my VPS IP on the exchange?
Yes, if your exchange supports IP restrictions on API keys. A Cloudj server keeps its IP while it exists, so the allowlist stays valid.
Deploy your bot server
Measure your exchange's API from each city, keep the one your numbers favour, and lock down the keys before going live. You can deploy a server in Singapore, Tokyo or Hong Kong from the Cloudj console, which shows the exact price before you confirm.