Once you trade more than one MetaTrader 5 account, hosting stops being a single decision. A live account at one broker, a second at another, a funded prop-firm account and a challenge account each need their own running MT5 terminal, and you may want the same TradingView alert to reach several of them. The alert routing is straightforward. The hosting side is where traders end up with a tangle of servers, logins and monthly bills.
This article compares four ways to host several MT5 terminals, using three accounts as the worked example, and shows how to measure a shared VPS before you rely on it. It is about infrastructure only: where the terminals run and what you maintain. It does not cover strategy, risk, or how to trade any particular account. For the single-account version of this question, see Is a VPS still the right way to host MetaTrader 5?
The constraint: one terminal per account
A MetaTrader 5 terminal has one active account login at a time. To execute on three accounts simultaneously, you need three terminals running at once, each with its own login and its own copy of the PineConnector EA. One attached EA per terminal is enough for the symbols available to that account; you do not need a receiver on every chart. A TradingView alert can reach all three only if all three are running and connected. That is the hosting problem in one sentence: keep several terminals running, signed in and reachable whenever your strategy may trade.
Your PineConnector connection allowance applies wherever the terminals run. Adding a terminal or a server does not increase the number of accounts your plan can connect.
Option 1: One big Windows VPS running several terminals
You rent one Windows VPS, install MT5 three times in separate folders, log each one in to a different account, and leave all three running in a single Windows session.
It works, and it means one server to pay for and administer. The trade-offs are structural:
- Resource use adds up. Each terminal, with its charts, indicators and EAs, uses its own memory and CPU. Hosting providers publish rough idle-terminal figures and entry-plan descriptions[1][2], but those reflect their own test conditions, not your setup. Size for the complete set of terminals you will run, measured as described below, and re-measure when you add an account.
- One reboot takes down everything. Windows restarts to finish installing updates unless you set policies or active hours to hold the restart back[3]. When it does, all three terminals stop together, and none relaunch unless a startup method is in place; VPS providers publish guides on starting MT4 and MT5 after a reboot because a fresh reboot can leave the terminals closed[4]. Use the startup and recovery method your provider supports, and confirm it with a controlled restart.
- One RDP surface, three logged-in brokers. A single Remote Desktop login guards three broker sessions. Remote-access vendor TSplus states the 2026 baseline plainly: "do not publish RDP directly to the internet", and recommends a Remote Desktop Gateway or VPN in front of it[5].
Option 2: One VPS per account
Some traders split accounts across separate servers so a problem on one does not touch the others. Separate servers reduce the blast radius of a single machine's reboot: a restart on server A need not stop B and C. A failure at a shared provider can still affect them together, so separation is not an availability guarantee. Everything else multiplies: three Windows installs to patch, three RDP logins to secure, three sets of monitoring, three invoices, and three places to check when something looks wrong. Each machine also needs a provider-supported startup and recovery method, confirmed with a controlled restart.
Option 3: MetaTrader VPS (the built-in hosting)
MetaQuotes sells its own hosting from inside the terminal, usually called MetaTrader VPS or MQL5 VPS. It runs a virtual terminal on MetaQuotes' infrastructure, with no Windows desktop and no RDP; current prices are on the MetaQuotes VPS page[6]. MetaQuotes' rules state that "one rented terminal can work only with one User's trading account"[7], so three accounts means three rentals; independent hosting reviews make the same point, that it "is not a workspace for opening a fleet of terminals side by side"[8]. For traders running compatible MQL5-only Expert Advisors it can be a tidy answer.
It is not an answer for PineConnector. MetaQuotes' hosting rules are explicit that "No DLLs are allowed on a Virtual terminal"[7], and the current self-hosted PineConnector EA requires a DLL[9]. Three MetaTrader VPS subscriptions would give you three hosted terminals that cannot run the PineConnector EA. We include it here because people ask, and because the reason is worth knowing before paying for it.
Example illustration: the service each provider actually includes varies.
Option 4: Hosted MT5 with PineConnector Edge
PineConnector Edge is managed MT5 hosting included in PineConnector plans[10]. PineConnector runs each MT5 terminal and its own EA on its infrastructure and manages that environment, and you control each instance from the web portal. There is no server for you to size or administer, and no RDP, because there is no remote desktop to log into. You manage it from a browser, including on a Mac.
The part that matters for multiple accounts is capacity, and the wording trips people up. Your connection allowance is one number, shared across Edge and self-hosted terminals. A Plus subscriber ordinarily has three connections[10], used by hosted MT5 instances and self-hosted terminals alike. An allowed connection is not necessarily a hosted terminal already running: each hosted instance still has to be set up and logged in to one of your accounts.
| Plan | Connections, shared across Edge and self-hosted terminals (ordinary allowance) |
|---|---|
| Core | 1 |
| Plus | 3 |
| Pro | 5 |
Prices and plan terms change, so check current pricing rather than relying on a copied figure. Check the location shown for each instance and current availability on the Edge page.
Two limits apply, the same ones that apply to a single account: only PineConnector's own EA runs on a hosted instance, so third-party EAs are not supported, and Edge is MetaTrader 5 only. If one of your accounts is MT4, or needs another EA, that one stays self-hosted.
Three accounts, side by side
Take a concrete case: a live account at Broker A, a live account at Broker B, and a funded prop-firm account. Here is what you personally maintain under each option.
- One big VPS: one Windows Server to patch and reboot, three MT5 installs that each need a provider-supported startup method confirmed by a controlled restart, one RDP login to secure, resources measured for three terminals, monitoring that covers three processes, and two bills (your automation plan plus the VPS).
- One VPS each: all of the above, three times over, plus four bills.
- MetaTrader VPS: three subscriptions and nothing to patch, but the PineConnector EA cannot run, so the instructions are never acted on.
- Edge on Plus: your three broker logins, which you enter yourself, your strategy and your alerts, and one bill. PineConnector manages the hosted MT5 environment.
Hosted instances can also restart: for example, applying a change in Portal → Edge → EA Settings restarts that terminal and pauses its signal processing for about a minute.
Shared CPU and dedicated vCPU
Compare the CPU allocation rule, not just the number of vCPUs in the plan name. A shared-CPU VPS and a dedicated-vCPU VPS can display the same processor count while providing different access to the underlying hardware. That difference may matter for sustained or time-sensitive work, but it does not tell you how many MT5 terminals either plan can run.
“Dedicated vCPU” also does not necessarily mean a private physical server. It usually describes processor allocation within a virtualized service. Read the provider's definition before treating it as a guarantee about the whole machine.
A vCPU is a processor resource presented to a virtual machine. Its relationship to physical cores, hardware threads and scheduling depends on the service. Do not assume that four vCPUs from one provider equal four physical cores, or that another provider's four-vCPU plan delivers identical performance.
DigitalOcean's allocation guide gives a clear provider-specific example: its dedicated CPU plans reserve access to an underlying hardware thread, while shared CPU plans can share that resource with other virtual machines. It also identifies Droplets as Linux-based virtual machines. This is an explanation of allocation terminology, not a recommendation to use those products for PineConnector's Windows setup.
The practical distinction is whether the work can rely on the stated processor allocation when other customers are busy. Dedicated allocation reduces that particular uncertainty. It does not make the processor infinitely fast or remove limits in memory, storage and networking.
Ask about sustained use and burst rules
Some plans are designed for occasional bursts; others sell sustained processor access. A plan can perform well during a short setup session and behave differently after a longer workload. Ask the provider to identify the applicable policy rather than assuming that a speed seen during installation will continue indefinitely.
| Question for the exact plan | Why the answer matters |
|---|---|
| What does one vCPU represent here? | Hardware threads, physical cores and allocation labels are not interchangeable. |
| Is processor time shared or reserved? | The advertised count alone does not describe contention. |
| Is there a sustained-use allowance, credit balance or fair-use limit? | Short bursts may differ from continuous operation. |
| What happens after that allowance is exhausted? | Ask about throttling, charges or required upgrades before committing. |
| Which hardware families can this plan use? | Allocation and processor generation answer different questions. |
| Does a resize change other resources or require a restart? | The operational cost of testing an upgrade may matter as much as its price. |
Keep the written answers with the quote. A sales description such as “high performance” is not a substitute for an allocation policy.
Relate allocation to the measured problem
Use the workload test below to assess whether the current environment meets your needs. An allocation upgrade is most persuasive when persistent CPU pressure or a documented burst limit aligns with the problem. It is a weaker answer when the evidence points to memory pressure, storage activity, an unavailable broker connection or an invalid trade request.
Guest measurements have limits: a CPU percentage alone does not prove that neighbouring customers caused a delay. Ask the provider to compare the event with its own host and allocation data. If you test a dedicated-vCPU plan, keep the intended workload comparable and change one material factor at a time. Record what improved and what remained unresolved.
Set the acceptance criterion before paying for a long commitment. Reserved compute should solve a specific requirement, such as sustained processing within the plan's limits. It cannot guarantee that all orders fill or that broker execution takes a particular time.
Buy predictability where it has value
Shared CPU can be a sensible choice when the observed workload fits and occasional variation is acceptable. Dedicated vCPU is worth evaluating when reserved compute access solves a demonstrated requirement at a cost you accept. A private physical host answers a broader isolation question and should be assessed separately.
For PineConnector, the processor label does not replace the compatibility check. Follow the Windows MT5 installation requirements, and keep broker execution evidence separate from server measurements. Choose the allocation that supports your work, not the largest number printed beside “CPU.”
Measure a shared VPS before you rely on it
If you self-host several terminals, choose capacity by measuring the terminals and software you actually intend to run. There is no useful universal rule that one account needs a fixed amount of RAM, or that a particular vCPU count supports a fixed number of terminals. A lightly configured terminal and one running many indicators are different workloads. You do not need a laboratory benchmark: you need a repeatable test, a record of the demanding periods and enough spare capacity to avoid running at the edge of the server's resources.
Define the workload before comparing plans
Write down the concurrent broker accounts, MT5 terminals, open charts, indicators, EAs and other applications the VPS must run, including any copier or monitoring software. Record versions and settings so you can repeat the test after a change. Remove accidental duplication, such as an extra receiver on every chart, before measuring it as though it were a requirement; the multi-terminal guide explains the distinction. Keep backtesting and optimisation in a separate workload unless they genuinely must run beside live automation.
Establish a reproducible baseline
Use a trial or short commitment where the provider offers one, after checking its terms. Confirm that the Windows environment permits your applications and the required DLL before measuring performance. Record the plan's RAM, vCPU allocation, storage and any published resource limits; a vCPU count alone does not describe processor performance or how shared resources are allocated, so ask about sustained CPU limits.
Install the software and configure demo accounts. Let initial setup and history downloads finish, recording them separately. Then observe idle Windows, one terminal, and finally the complete planned set. This shows which additions create the largest change without assuming resource use grows evenly.
Measure the whole server and each terminal
Windows Task Manager gives a starting view of CPU, memory and disk activity. Use the provider's monitoring history as well, particularly if it retains short spikes you would miss while watching the screen. Keep a simple measurement sheet:
| Record | What it helps you decide |
|---|---|
| Date, time, timezone and market session | Whether two observations are comparable |
| Active terminals and configuration | Which workload produced the result |
| Total and per-process CPU use | Whether pressure comes from MT5 or another application |
| Memory use and available memory | Whether the complete setup leaves room for temporary growth |
| Disk activity and remaining space | Whether storage pressure coincides with slow behaviour |
| Alert, connection and broker observations | Whether resource use coincides with an operational problem |
Record typical values, peaks and how long pressure lasts. An isolated spike during startup is different from sustained pressure during routine operation. If monitoring shows paging, record it too: extra disk activity under memory pressure is a reason to investigate, not automatic proof that every delay is caused by RAM.
Cover the demanding conditions
Observe the sessions your strategy will trade, including the busiest periods you expect. Test several demo accounts receiving their configured alerts close together, using the documented test workflow, and verify the resulting orders. Do not generate a stream of trading instructions merely to push CPU usage upward.
Also test recovery in a planned demo-only window. Restart the VPS using the provider's supported controls, then check that every terminal, broker login and PineConnector connection is restored. Record how long recovery takes and which steps still need you. If the startup method needs manual intervention, more RAM will not remove that dependency. Continue until you have covered the conditions you need to handle, rather than treating an arbitrary test duration as certification.
Set acceptance criteria and compare one change
Decide what success means before upgrading: all terminals responsive and connected, no sustained resource exhaustion, sufficient free storage, correct demo outcomes and a recovery procedure you can complete consistently. Choose explicit headroom for your setup and document why; no single percentage makes every strategy safe, and a plan that barely fits today's peak is a poor start if you intend to add accounts.
When a test fails, identify the constrained resource before paying for more of everything. Memory pressure needs a different investigation from persistent CPU pressure. Disconnections with ample resources need connection and log checks. Broker rejection messages need the broker's account and symbol rules, not a larger server. Change one plan dimension or workload component, repeat the same observations, and keep the change only if it solves the actual problem at an acceptable cost.
Save the configuration and results as your capacity record, and recheck after adding terminals, changing EAs or indicators, or moving provider. A successful test supports that measured configuration; it does not establish unlimited capacity or future availability, and a resource chart cannot prove that a trade completed.
Adding an account on Edge
Each hosted instance is set up from the PineConnector portal. Follow the current Edge guide for the steps. Before relying on a new instance, check that it uses the intended licence, is logged in to the intended MT5 account (one you opened at the broker you chose) and connects to that account's exact broker server, and that Portal shows it connected for that account.
Then check how your alerts are addressed. Alerts sent to a shared License ID can reach every account attached to it, so confirm each account should receive them and avoid sending the same instruction to an account twice. Run the documented demo test and compare the instance's Experts and Journal with the broker result; a connected status does not confirm a particular order.
PineConnector does not select trades, manage money or hold funds. Edge is managed infrastructure, not managed execution: PineConnector manages the hosted MT5 environment; what the terminal is told to do is yours.
Common questions
Can one TradingView alert go to all my accounts?
Yes. PineConnector routes alerts by License ID regardless of where the terminals are hosted, and the multi-terminal guide explains the setup. Hosting decides whether each terminal is actually running when the alert arrives.
Do I need a separate Edge instance for each broker account?
Yes. One hosted MT5 instance is logged in to one trading account, exactly like a self-hosted terminal. Three accounts means three instances, which uses all three connections Plus ordinarily includes.
What if I need more than three?
Pro ordinarily includes five connections, shared across hosted instances and self-hosted terminals. Connection allowances apply to self-hosted terminals too, so moving some accounts to your own VPS does not let you connect more accounts than your plan allows. Check current pricing for plans and options.
Can I mix Edge and my own VPS?
Yes, within your plan's connection allowance. An MT4 account, or an account that needs a third-party EA, can keep running on your own machine while MT5 accounts that only need the PineConnector EA use hosted instances.
Which one fits
If you run third-party EAs, trade MT4, or want full control of the machine, a Windows VPS remains the right tool; measure it with your real workload, and consider one server per account if the isolation is worth the extra admin. If that is your route, ForexVPS (affiliate link) offers Windows VPS plans for MetaTrader. MetaTrader VPS can suit compatible MQL5-only automation but cannot run the PineConnector EA. If your accounts are MT5 and you only need the PineConnector EA on each, Edge on Plus moves the server administration for three accounts into the hosted MT5 environment PineConnector manages, while you enter each account's login yourself. See the Edge page for how it works, pricing for the current plans, and What is PineConnector Edge? for the full walkthrough.
Affiliate disclosure: PineConnector may earn recurring commission if you subscribe to ForexVPS through this link.
Sources
- Host-Stage – cTrader vs MT4 vs MT5: Honest 2026 Comparison + Specs, accessed 9 September 2026.
- MyForexVPS – Forex VPS Hosting Guide 2026: Choosing a VPS for MT4 and MT5 Trading, accessed 9 September 2026.
- Microsoft Learn – Manage device restarts after updates, accessed 9 September 2026.
- Hyonix Knowledge Base – How to make your MT4, MT5 automatically start after a VPS reboot, accessed 9 September 2026.
- TSplus – RDP Brute Force Protection: What Works in 2026, accessed 9 September 2026.
- MetaQuotes – MetaTrader VPS: Virtual Private Server for Forex (pricing), accessed 9 September 2026.
- MetaQuotes – Rules of Using the Virtual Hosting Service, accessed 9 September 2026.
- New York City Servers – MQL5 VPS vs Windows VPS: Which Should You Use?, accessed 9 September 2026.
- PineConnector – How to Run MT5 on a Mac for Automated Trading (DLL requirement), accessed 9 September 2026.
- PineConnector – PineConnector Edge: Hosted MT5 Included in Every Plan, accessed 9 September 2026.
- PineConnector – Pricing and Edge portal Add Instance demo, accessed 9 September 2026.
PineConnector executes the instructions you send it. It does not select trades, manage money, or hold funds. Trading carries risk, and past performance of any strategy does not indicate future results.