A compatible cBot does not automatically need a VPS. cTrader Cloud can run a cBot continuously without the cTrader app remaining open; a VPS becomes relevant when the cBot needs something that cTrader documents as outside the cloud environment.
That distinction is operational, not a verdict on a strategy. Hosting can keep a process available. It cannot prove that the rules have an edge, that an integration is reliable, or that the bot will recover correctly after an interruption.
Start with the execution boundary
cTrader separates cloud execution from local execution. Its Cloud features documentation says cloud execution is available for cBots, while local execution also covers custom indicators and plugins.
A VPS is a remotely administered computer. In this comparison, it matters because it can keep cTrader's local execution running when the trader's own computer is not the machine running the platform. It is not a substitute for checking what the cBot actually depends on.
| If the cBot needs... | The documented starting point | What to verify before it runs unattended |
|---|---|---|
| Continuous execution of a compatible cBot | cTrader Cloud | The cBot starts, stops and reports errors as expected |
| A custom indicator or plugin running with the process | Local execution, which may be hosted on a VPS | The platform, add-on and cBot work together after a restart |
| HTTP calls or a dependency tied to the operating system | A locally managed environment such as a VPS | The dependency, credentials and failure behaviour outside a backtest |
| Files that must survive an instance stop or deletion | A design that does not rely on cloud-instance files | What state is rebuilt from the account and what is stored durably |
The table is a compatibility screen, not a performance ranking. cTrader documents low-latency cloud connectivity, but it does not turn a cloud instance into proof of fill quality, broker conditions or profitability.
The cloud constraints that decide the question
The practical question is not whether a VPS sounds more professional. It is whether the cBot crosses a documented cloud boundary.
cTrader says its cloud environment is Linux-based. Its Cloud requirements also state that HTTP requests are not sent in the cloud, certain Windows-specific dependencies do not work there, and instance resources are freed when an instance is stopped or deleted.
That matters for three common designs:
- A cBot that sends data to an external web service cannot assume its HTTP path will work in cloud execution.
- A cBot built around Windows-specific user-interface components is not a cloud-compatible design merely because it compiled on a desktop.
- A cBot that treats files created by a cloud instance as permanent memory has a restart problem waiting in the wings.
None of these facts means a VPS is inherently better. They mean the execution environment must match the code and the operating process. If the cBot is simple, compatible and self-contained, adding another machine can add administration without solving a real problem.
Check dependencies before choosing a host
A cloud-or-VPS decision is easiest before deployment, when it is still a checklist rather than an incident.
Map the cBot's outside world
List every thing the cBot touches beyond cTrader's account and market data: external libraries, web services, files, local storage, notifications and other algorithms. Then mark which items are required for a trade decision and which are only conveniences.
cTrader's Cloud requirements distinguish compile-time references from standalone DLL loading. The documentation says a cloud instance runs the .algo executable without managing separate external DLL files. A library that works locally can therefore be the exact reason cloud execution is not appropriate.
Define the restart contract
Do not let storage become an undocumented dependency. The cloud documentation says resources allocated to an instance are freed after it is stopped or deleted, so the cBot needs an explicit answer to a plain question: after it starts again, what account truth can it rebuild and what state must it retain elsewhere?
The relevant test is not a smooth restart on a flat account. Run the same cBot restart test with a managed position, a pending order and a just-processed signal. The first decision after recovery should be explainable from the current account and the written rules, not from a missing local file.
Separate hosting from validation
Cloud execution and a VPS solve availability problems. They do not validate a strategy. A historical backtest remains evidence about a specified historical test, while deployment testing asks whether the live process handles restarts, missing services and state changes as designed.
That separation is central to a verifiable trading methodology. Keep the strategy rules, execution assumptions and operational tests visible enough that another trader can inspect them separately.
A practical deployment drill
Before leaving a cBot unattended, run a small drill in the exact environment chosen. This is not a recommendation to trade; it is a way to check a software process.
- Start the cBot with the intended parameters and record the platform, symbol, account type and instance settings.
- Confirm that the expected logs and error path are visible without relying on the trader's desktop remaining open.
- Stop and restart it in a state with an open managed position or pending order, then inspect whether it duplicates, loses or misidentifies that state.
- If the cBot depends on an external service or stored data, simulate that dependency being unavailable and record the defined outcome.
- Keep the result with the deployment record; a successful start is not the same thing as a tested recovery.
A VPS can be the right home for a cBot with local-only dependencies. cTrader Cloud can be the simpler home for a compatible, self-contained cBot. In both cases, the useful evidence is the same: a documented dependency map and a recovery test that someone else can review.
realbacktesting is a trading-software studio for cTrader that treats operational checks as part of verifiable software. Our proof page explains why a result should be inspectable rather than accepted on presentation alone. Hosting does not remove uncertainty; it makes a particular set of assumptions testable.
Frequently asked
Can cTrader Cloud run an indicator or plugin?
No. cTrader's Cloud features documentation identifies cloud execution for cBots only; local execution supports cBots, custom indicators and plugins.
Does a cTrader cBot always need a VPS to run continuously?
No. cTrader documents cloud execution that runs a cBot continuously without the cTrader app staying open. The deciding issue is compatibility with the documented cloud environment, not an assumption that continuous operation always requires a VPS.
Can a cloud cBot rely on HTTP requests?
No. cTrader's Cloud requirements state that no HTTP requests are sent in cloud execution. A cBot that requires that path needs a different design or a locally managed execution environment.
Does choosing a VPS make a cBot safer?
Not by itself. A VPS changes where local execution runs; it does not prove the cBot's strategy, dependencies, restart handling or broker-side conditions. Those need separate tests.
The stubborn takeaway
A VPS is not a badge of seriousness. It is a response to a documented requirement that cloud execution does not meet.