When you add or write a custom indicator the calculations can happen in different places depending on the platform you use. Some platforms run indicator code on your device (using your CPU and memory), some run it on the provider’s servers, and others use a mix of both. Which model a platform uses affects performance, battery life, latency for alerts, privacy of your indicator code or data, and how you should design and test your indicator. This article explains the common architectures, gives practical examples, and helps you decide what matters for your workflow.
Two broad architectures and what they mean
There are two broad ways a platform can compute indicator values: locally on the client, or remotely on a server.
When an indicator runs locally (client-side), the program is executed inside the application on your computer, phone or VPS. That means the device’s CPU, memory and battery are doing the work. Desktop trading terminals that let you install custom scripts or plugins often work this way. The advantage is direct control: you can see CPU use, debug locally, and the indicator can react instantly to incoming ticks. The downside is that heavy or poorly optimized indicators can slow your machine, drain battery on mobile devices, and limit how many symbols you can analyze in parallel.
When an indicator runs remotely (server-side), the platform executes the code on its infrastructure. The charting or app then receives the computed values or rendered results. This model shifts the compute burden off your device and scales better when you want the same indicator across many symbols or users. It also allows providers to enforce execution limits, sandboxing and module whitelists for security. The trade‑offs include possible latency (depends on server–client round trips), less visibility into runtime resource use, and the fact that your indicator code may be visible to the vendor or must abide by their restrictions.
Many modern systems use a hybrid approach: some computations (rendering, simple client-side math) are done in the browser or app while heavier or multi-symbol calculations, backtests and alerting run on servers. The exact split varies by vendor.
Examples to make it concrete
MetaTrader (desktop/mobile/EAs and indicators). In popular retail terminals you install indicators or expert advisors that are executed inside the terminal process running on your PC or VPS. If you attach a custom indicator to many charts, your local CPU and memory use will climb. Traders who run multiple symbols or synthetic feeds often move their EAs to a dedicated VPS to avoid slowing their workstation.
Web charting services and cloud platforms. Some web-first charting platforms and algorithmic providers run custom scripts on their servers. In those systems you often paste code into an online editor, and the platform compiles and executes it inside a sandbox. That sandbox may allow only a limited set of libraries, limit execution time, and restrict I/O for security. When you request an alert or run a backtest, the heavy lift happens in the cloud and the client only shows the results.
Hybrid examples. A browser-based chart can render lines and overlays locally while the platform computes indicator series on the server and streams them to the client. This reduces client CPU load but preserves a responsive UI. Some platforms compute indicator values server-side for live alerts and backtests, but let users preview or tweak visual parameters locally.
Algorithmic research or execution services. Services that let you develop algorithms in languages like Python or C# typically run your code in the provider’s cloud. That design scales to many symbols and supports fast backtesting, but it also means you are limited to the provider’s allowed packages, execution time limits, and sandbox policies.
How to tell where an indicator runs
Documentation is the first place to check. Platform docs usually state whether custom code runs in a sandbox on their servers or inside a client terminal. Look for wording about “sandbox,” “execution limits,” “allowed modules,” or “compile/compile & run” in the UI.
Observe resource behavior. If adding an indicator makes your PC or phone noticeably slower or hotter, the computation is likely local. If your device remains light but the platform shows server-side status messages (compiles, queued runs, “running on server”), the work is probably remote.
Check what happens when you close the app. If alerts and scans continue while you’re offline, they’re almost certainly server-side. If everything stops when you close the desktop app, the client is doing the work.
Ask about limits. Platforms that run code server-side often impose execution timeouts, per-call CPU caps, or limits on imported libraries. If you see explicit limits in the editor (for example “must return within X seconds”), that indicates server-side execution.
Practical implications for traders and developers
If your platform runs indicators client-side, optimizing for speed and memory is important. Use vectorized operations where possible and avoid recalculating entire history on each tick. On desktop terminals, a badly written custom indicator can degrade the performance of other charts and even freeze the terminal.
If the platform runs code server-side, expect sandboxing and security restrictions. You may not be able to use arbitrary system libraries, perform file I/O, or open unrestricted network connections. On the positive side, server-side execution lets you scale screens and alerts across many symbols without loading your local device.
For alerting and monitoring many symbols (hundreds to thousands), server-side solutions are generally easier and cheaper to operate. A service that computes indicator values in the cloud can watch large universes and send webhooks or push alerts without your machine running all the time. If you try to do the same on a phone or desktop, you quickly hit limits of CPU, network and battery.
Backtesting and historical runs often use server resources because they need large data volumes and repeatable environments. If your platform offers cloud backtesting, results are typically produced remotely even if the live charting is local.
Performance and design tips based on where code runs
When indicators run locally you should minimize per-tick work: cache intermediate values, use rolling windows, and avoid expensive loops over the entire dataset for each update. If your platform exposes vectorized libraries, prefer them.
When code runs in a sandbox on servers, expect a time budget and library restrictions. Aim for efficient single-pass algorithms so each call finishes quickly. Avoid excessive network calls or file operations: those are unlikely to be allowed and add latency.
When designing for scalability (large watchlists or many alerts), prefer platforms that support server-side execution of custom logic or provide built-in scanning services. Offloading the daily scanning to cloud jobs keeps your home PC or phone free from long-running tasks.
Privacy, IP and sharing considerations
Where the code runs affects who can see or copy it. Running code client-side keeps your source on your machine, but if you distribute the indicator to others you may still reveal methods. Server-side platforms commonly provide a way to deploy code but may require you to submit it for compilation; they can enforce access control and sometimes hide compiled logic from other users. If your strategy is proprietary, check the platform’s terms about code visibility, ownership and export.
Risks and caveats
Indicator behavior, performance and allowed operations depend heavily on the specific platform and can change over time. Vendors change architectures, update sandboxes, and revise execution limits. Always read and test on the platform you plan to use. Running custom code carries operational risk: resource spikes can slow your system, cloud limits can interrupt live alerts, and logic bugs can create misleading signals. Backtest responsibly to avoid look‑ahead bias, and remember that charts, indicators and alerts do not guarantee profitable trades. Trading involves risk and losses are possible; this article gives general information and not personalized investment advice.
How to decide where to run your custom indicator
Choose a client-side workflow if you need full control over the runtime environment, must access local resources, or require ultra-low-latency visualization tied to your terminal. Choose a server-side workflow if you need scalability across many symbols, continuous alerts while your device is off, or want to avoid local CPU and battery drain. If you need both—fast local visuals and large-scale scanning—look for platforms that offer a hybrid model where you can prototype locally and deploy to the cloud for production monitoring.
Key practical checks before you deploy:
- Read the platform documentation for execution model and limits
- Test CPU and memory impact on a representative machine or VPS
- Verify alert behavior (does it work when the client is closed?)
- Confirm sandbox rules and allowed modules if using server-side code
Key Takeaways
- Platforms differ: some run custom indicators on your device, some on provider servers, and some use a hybrid split.
- Client-side code gives control and low-latency visuals but uses your CPU and battery; server-side scales better and can run 24/7 but has sandbox and latency trade-offs.
- For monitoring hundreds or thousands of symbols, server-side execution or cloud scanning is usually the practical choice.
- Trading carries risk; test thoroughly, understand platform limits and sandbox rules, and do not treat indicator output as trading advice.
References
- https://www.investfly.com/help/customIndicator.html
- https://www.mql5.com/en/articles/35
- https://www.tradovate.com/platform/custom-indicators-api/
- https://help.trendspider.com/kb/indicators/custom-indicators-js-scripting
- https://www.reddit.com/r/TradingView/comments/y86qsb/best_trading_platform_to_program_custom/
- https://www.mql5.com/en/forum/226174
- https://www.quantconnect.com/docs/v2/writing-algorithms/indicators/custom-indicators
- https://learn.microsoft.com/en-us/defender-endpoint/indicator-ip-domain
- https://www.reddit.com/r/TradingView/comments/1nq7zqx/does_tradingview_do_indicators_calculations_on/