A trading VPS is an always-on machine in a datacenter that runs your MetaTrader terminal or trading bot independently of your laptop, your home power supply and your home internet. One simple question shows why it matters: what does your Expert Advisor do at 3 a.m., in the middle of an open position, when the power goes out? Nothing. It just stops there, and you wake up to a stop-loss that never executed. This guide lays out the whole path: realistic specs, the documented way to install MetaTrader on Linux, the trap of a server with no monitor, clock synchronization, keeping the service alive, and the things a trading VPS does not do for you.
Why do traders use a VPS?
What you find when you search for "trading VPS" is an ordinary VPS configured for one job: running a trading platform without interruption. There are three reasons for it:
- 24/7 uptime — an Expert Advisor (EA) isn't independent code that lives on the broker's server; it runs inside the MetaTrader terminal itself and only receives ticks while the terminal is open and connected. Closing your laptop lid stops the EA.
- A stable connection — a few seconds of home internet outage, which is irrelevant for browsing, can end in a requote or a stuck pending order when it hits in the middle of sending an order; and a crypto bot has a blind window after every outage in which it doesn't know which positions are open.
- Predictable latency — the network path from a datacenter to the broker's or exchange's server is usually shorter than from a home connection and, more importantly, far less variable. We talk about this more honestly further down.
When it is used for MetaTrader, the same server is also called a "forex VPS": the name is different, the substance is the same. One note before going on: MetaQuotes' documented Linux route is written only for MetaTrader 5; if your broker is on version 4, follow the Windows route.
What specs does a trading VPS need?
The good news: live trading is one of the lighter jobs a server can do; what eats resources is three other things: the Windows operating system, backtesting and dozens of open charts. Also note that the official MetaTrader 5 help has no minimum hardware table, so the figures on broker websites are their own estimates.
| Scenario | RAM | Cores | Operating system | The deciding factor |
|---|---|---|---|---|
| One MT5 terminal with a few EAs | 2 GB | 2 | Ubuntu or Debian + Wine | The lightest route; there is an official MetaQuotes installer |
| MT5 on Windows with Remote Desktop | 4 GB | 2 | Windows Server | Windows Server 2025 alone needs 2 GB of RAM and a 32 GB system partition |
| Backtesting and strategy optimization | 8 GB | 4 or more | Either | One local testing agent is created per logical core |
| Python bot for an exchange | 1–2 GB | 1–2 | Ubuntu 24.04 or later | Check the distribution's Python version; today's frameworks need 3.11 or later |
The third row is the only place where buying more cores visibly pays off. The MetaTrader 5 documentation says local testing agents are installed automatically, one for each logical core of the computer; in other words, optimization runs more in parallel the more cores it sees, while live trading doesn't saturate even a single core. The sensible approach: a small server for permanent running, and extra capacity only temporarily, for backtesting periods.
Two less-discussed hardware points: an NVMe disk makes a noticeable difference over SSD when price history is loading, because that stage is heavy random reading rather than a linear copy; and CPU stability matters more than core count. On KVM infrastructure each server has its own isolated resources, and a resource-hungry neighbor can't steal your processor in the middle of an NFP release (the monthly US Non-Farm Payrolls report). To choose a distribution, see our comparison of Ubuntu, Debian and AlmaLinux.
Windows or Linux? MetaTrader runs on both
Option 1: Linux with the official MetaQuotes installer
MetaQuotes itself documents running MetaTrader 5 under Wine and provides a ready-made script that works on Ubuntu, Debian, Linux Mint and Fedora: it adds the official WineHQ repository, installs the staging version of Wine and then puts MetaTrader into a separate Wine prefix:
wget https://download.mql5.com/cdn/web/metaquotes.software.corp/mt5/mt5linux.sh
chmod +x mt5linux.sh
./mt5linux.shThree things it does behind the scenes that will come in handy later: it enables the 32-bit architecture with dpkg --add-architecture i386 (WineHQ packages won't install without it), it keeps everything in the ~/.mt5 prefix in Windows 11 compatibility mode, and before MetaTrader it also installs the Microsoft Edge WebView2 runtime, a component that gets left out when you install Wine by hand. Then reboot once; the files end up in ~/.mt5/drive_c/Program Files/MetaTrader 5/.
The advantage of this route is cost: a 2 GB server is enough and you don't pay for a Windows license. The drawback is a more technical initial setup. If you aren't comfortable with the Linux terminal, start with our guide to connecting to a server over SSH.
Option 2: Windows and Remote Desktop
The route that feels simplest: you create a Windows Server, connect with Remote Desktop and install MetaTrader just as you would on your own computer. There is nothing new to learn, but it comes with three costs: more RAM, a Windows license and a bigger attack surface. The Remote Desktop service listens on port 3389 by default, and that port is scanned constantly from all over the internet; Microsoft documents how to change it through the registry and reminds you that afterwards you also need to create a new inbound rule in Windows Firewall.
Option 3: a crypto bot, with no graphical environment at all
If your trading bot works through Python and an exchange API (Freqtrade, Hummingbot or your own code), you don't need Windows or a desktop at all: a minimal Linux install, a virtualenv and a systemd service will do. There is a version trap here, though: Freqtrade needs Python 3.11 or later, while the default python3 on Ubuntu 22.04 is still 3.10. Ubuntu 24.04 ships with 3.12 and Ubuntu 26.04 with 3.14, and both are painless. Check once before installing anything:
python3 --version
Python 3.12.3Many people run their bot in a container so that its Python version is decoupled from the host distribution; see our guide to installing and running Docker on a cloud server.
How do you run MetaTrader on a server with no monitor?
This is where most guides go quiet. Your server has no screen, only a text terminal over SSH; yet the official MetaQuotes script ends by launching a graphical Windows installer, and MetaTrader itself is a windowed application. On a server with no graphical environment, the process stops right there. There are two standard fixes:
- A temporary virtual display. The
xvfbpackage creates an in-memory X display server that is never shown anywhere, yet graphical programs see it as a real one. - A lightweight desktop plus visual access. If you want to see the charts with your own eyes, install a lightweight desktop environment and connect to it through the panel's web console (VNC): heavier, but worth it during setup.
sudo apt update && sudo apt install -y xvfb
xvfb-run -a ./mt5linux.shThe complementary point: the terminal has to survive an SSH disconnect, or it is killed when the session closes. The simplest way is tmux; the more correct way, which we build below, is a systemd service that also comes back after a reboot.
Trading VPS latency, honestly: how much does ping really matter?
Let's be clear about this, because advertising in this field is full of exaggeration. Network latency depends on the distance and the transit path to the destination server, not on a "made for trading" label on your server:
- Iranian exchanges and markets: their servers are inside Iran, so a server in an Iranian datacenter, with single-digit ping to them, is unbeatable. A server abroad actually increases latency here, because every packet has to cross Iran's international gateway (the few links that carry the country's traffic to the outside world) twice.
- Foreign brokers and exchanges: their execution servers are usually in Europe or North America, and the right choice is the location nearest to that server. Mehran Host's international servers are delivered in Hetzner datacenters (Falkenstein and Nuremberg in Germany, Helsinki in Finland, Ashburn, Virginia and Hillsboro, Oregon in the US, and Singapore), and the currently active list is shown on the order page itself.
And one non-network fact that is more decisive than ping: many international platforms grant or deny access based on the geolocation of your IP address, and no latency optimization changes that. Check it before you buy a server.
Before choosing your trading VPS, measure for yourself; a brochure number is useless. To see which hop of the path the latency comes from, use mtr (on Ubuntu, sudo apt install mtr-tiny):
mtr --report --report-cycles 20 broker.example.com
HOST: trade-vps Loss% Snt Last Avg Best Wrst StDev
1.|-- gateway.local 0.0% 20 0.4 0.5 0.3 1.1 0.2
2.|-- core1.dc.example 0.0% 20 1.2 1.3 1.1 2.4 0.3
3.|-- ix.transit.example 0.0% 20 31.7 32.1 31.4 38.9 1.4
4.|-- broker.example.com 0.0% 20 32.9 33.4 32.6 41.2 1.7The StDev (latency variation, or jitter) and Loss% columns matter more than Avg: a server with a higher average but negligible variation is better for order execution than one with a lower average and large swings, because what ruins an order is unpredictable latency. Repeat the measurement during busy market hours; there is more in our guide to reducing ping and latency.
The server clock: a trap that silently rejects orders
Almost every exchange API sends each signed request with a timestamp, and the exchange's server compares it with its own clock. In Binance's spot API, recvWindow defaults to 5000 milliseconds when it isn't sent, and a request outside that window is rejected with code -1021 INVALID_TIMESTAMP and the message "Timestamp for this request is outside of the recvWindow." So a clock that drifts by a few seconds is enough for your bot to place no orders at all, without a single network error.
Ubuntu's time sync tooling has changed: from version 25.10 onwards, chrony has replaced systemd-timesyncd as the default, but a server that was upgraded may still be on timesyncd, and there is a practical difference. timesyncd is a simple SNTP client, while chrony is a full NTP client that continuously measures and corrects the clock. Check the status before any troubleshooting:
timedatectl
Local time: Tue 2026-09-08 14:12:03 UTC
Universal time: Tue 2026-09-08 14:12:03 UTC
RTC time: Tue 2026-09-08 14:12:04
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: norecvWindow isn't a fix; it just hides the symptom.Setting up the bot and keeping it alive
The general path for a Python bot on Ubuntu: create a non-root user, lock down the firewall and SSH keys following our Linux server security checklist, move the code over and turn it into a systemd service so that it comes back by itself after a reboot or a crash:
# /etc/systemd/system/tradingbot.service
[Unit]
Description=Crypto trading bot
After=network-online.target
Wants=network-online.target
[Service]
User=trader
WorkingDirectory=/home/trader/bot
ExecStart=/home/trader/bot/venv/bin/python main.py
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.targetsudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
journalctl -u tradingbot -f # log streamWhy RestartSec=10 is not an arbitrary number
This is the one line most guides get wrong. systemd also has a start rate limit: by default, no more than 5 starts are allowed within 10 seconds, and the documentation says units that exceed it "are not permitted to start any more". Meanwhile, the default RestartSec is only 100 milliseconds. So a bot that crashes immediately because of a wrong API key goes up and down five times in under a second, hits the limit, and systemd gives up on it: the classic "I woke up and the bot was off" scenario. RestartSec=10 spreads five attempts over 50 seconds and never hits the limit. This is what hitting the limit looks like in the logs:
systemctl status tradingbot
× tradingbot.service - Crypto trading bot
Loaded: loaded (/etc/systemd/system/tradingbot.service; enabled)
Active: failed (Result: start-limit-hit)
systemd[1]: tradingbot.service: Start request repeated too quickly.
systemd[1]: tradingbot.service: Failed with result 'start-limit-hit'.Once you've fixed the root cause, reset the counter with sudo systemctl reset-failed tradingbot; without it, even a manual start may be refused.
A watchdog and external monitoring
Add a simple cron watchdog as well:
# crontab -e
*/5 * * * * systemctl is-active --quiet tradingbot || systemctl restart tradingbotAnd monitor from the outside: write the bot so that every few minutes it sends an "I'm alive" message to Telegram or to a healthcheck service. The difference between a watchdog and monitoring is that the first fixes the problem itself and the second tells you. You need both, because the worst case is a service that is "up" but doing nothing: the process alive, the websocket disconnected, and systemd none the wiser. On Windows, automatic logon plus putting the terminal in the Startup folder plays the same role.
Trading server security: API keys, a static IP and the firewall
A trading server differs from an ordinary web server in one fundamental way: it holds a key that is directly connected to money. Three minimum layers:
- A key without withdrawal permission. Create the API key with read and trade access only; if the server is compromised, the worst an attacker can do is open bad trades, not withdraw funds.
- Restrict the key to the server's IP. On Binance this is more than a recommendation: an IP restriction is mandatory for enabling withdrawal permission, and since January 30, 2023, a key without an IP restriction only gets "read" permission. So for a bot that places orders, a static public IP is a prerequisite, not a luxury.
- A firewall closed to everything that isn't needed. A Python bot needs no inbound ports; leave only SSH open and restrict it to your own IP. Periodic checks are scheduled with a Linux cron job.
chmod 600 permissions and hand them to the systemd service with EnvironmentFile=. That way the key doesn't show up in your Git history, in ps output or in error logs: the three places keys leak from most often.When the bot stops in the middle of the night, where do you start?
The table below links the most common symptoms to their likely cause and the first thing to do:
| Symptom | Likely cause | Next step |
|---|---|---|
| The service is failed and won't come back up | systemd's start rate limit was hit | If systemctl status shows start-limit-hit, fix the cause and run reset-failed |
| Every order is rejected with a timestamp error | The server clock isn't synchronized | Check timedatectl and enable the time sync service |
| The API only returns permission errors, with no network errors | The key is restricted to a different IP | Compare the server's outbound IP with the allowed IP in the exchange's dashboard |
| The MetaTrader terminal dies after you close SSH | The process is tied to the SSH session | Move it under tmux or into a systemd unit |
| The MetaTrader install on Linux stalls halfway | The server has no graphical environment | Run the installer with xvfb-run |
| The service is "active" but no trades are placed | The process is alive but the data connection is down | Read the log with journalctl -u and add an external heartbeat |
| The server is powered off, yet charges keep coming | Powering off doesn't stop billing | If you no longer need it, delete the server instead of powering it off |
What doesn't a trading VPS solve?
A server doesn't change the broker's execution speed: slippage and requotes happen on the broker's side, and you only control your own share of the network path. It doesn't change the quality of your strategy either; a bot that loses money in a backtest just loses it faster on NVMe. And it doesn't replace risk management: without a daily loss limit, 24-hour uptime only means more opportunity for mistakes.
In fairness, there is an alternative worth mentioning: MetaQuotes itself offers a virtual hosting service that you activate from inside the terminal. It migrates your EA environment and signals in a few clicks and comes with a 24-hour trial. Its strength is simplicity and its limit is the resource cap: up to 3 GB of RAM and 16 GB of disk. If you also want a Python bot or a database next to MetaTrader, you need a full server with root access.
How do you get a server, and how does billing work?
Mehran Host's cloud servers are billed by the hour, which is ideal for trying out a bot: you pick the specs you want (RAM, CPU and disk), a KVM server with an NVMe disk is delivered within a few minutes, and if the bot's logic doesn't work out, you've spent no more than a few hours' worth. But there are three financial points to keep in mind:
- Powering the server off doesn't bring the bill to zero. A stopped machine still reserves RAM and disk on the node, so a percentage of the hourly rate is still charged for it. The only thing that stops charges completely is deleting the server, so take a backup before you delete.
- The service is suspended when your wallet balance reaches zero, not when it goes negative. For a bot that runs nonstop for weeks, top up the wallet with a margin.
- Management happens in the customer panel: creating and deleting servers, reinstalling, the web console and viewing usage. If hourly billing is new to you, read what an hourly cloud server is first.
A trading VPS is neither exotic nor complicated: a small KVM server with an NVMe disk and an hour of your time make the difference between a bot that "usually" works and a bot that is always present in the market. Create an account and move your bot to the datacenter tonight.
Frequently asked questions
What is a trading VPS, and how is it different from a regular VPS?
A trading VPS is a regular VPS configured to run a trading platform without interruption; the difference lies in its configuration and choice of location, not its hardware. Three things make it a "trading" server: network proximity to the target broker's or exchange's server, the datacenter's stable connection and power, and a service that brings the platform back automatically after every crash or reboot.
How much RAM do I need to run MetaTrader 5?
For one terminal with a few EAs, a 2 GB Linux server is enough, while the Windows route needs at least 4 GB, because Windows Server 2025 alone requires a minimum of 2 GB of RAM and a 32 GB system partition. For heavy backtesting and optimization, 8 GB and four cores is more sensible. The official MetaTrader help has no minimum hardware table, so measure your own real usage.
Can MetaTrader run on Linux?
Yes. MetaQuotes officially documents running MetaTrader 5 on Linux through Wine and publishes a ready-made install script for Ubuntu, Debian, Linux Mint and Fedora that installs Wine and the terminal in one go. Its advantages are no Windows license cost and lower RAM use. The important catch is that the installer is graphical, so on a server with no graphical environment it has to run under a virtual display such as Xvfb.
Should I get my trading server in Iran or abroad?
It depends on one thing only: where your destination server is. For Iranian exchanges and markets, a server in an Iranian datacenter gives the shortest path and the most stable latency, while a server abroad just adds an extra crossing of the international gateway. For international platforms, a location close to their execution servers is better; bear in mind, too, that many of them grant access based on IP geolocation, which you must check before buying.
How do I make sure my trading bot comes back by itself after a reboot?
Turn the bot into a systemd service with Restart=always and RestartSec=10, and enable it with systemctl enable so it starts at boot. The default restart delay is only 100 milliseconds, and because systemd allows no more than five starts in ten seconds, a service that crashes quickly hits that limit and never comes back. Then confirm the real behavior by rebooting the server as a test.