My EA for autonomous forex scalping robot

[PTScalper]

Hi scalpers,

In this forum thread i will share my progress of developing my own forex scalping autonomous robot


My starting point is Amazon cloud free instance for 180 days and i will compare that with Google cloud paid instance.

What i like in that Amazon cloud instance is, that they allready have in their pricing like 2TB egress all in 22$ per month. Its called Amazon light sail. Plus there is windows server licence. So the pricing is very very good.

First rule for me is to keep everyrhing as low as possible every dolar, which i will save goes directly in my pocket.

Do you have some experience with that?
Thank you for your feedback,
Good luck and take care

[LondonScalper]

Amazon cloud free instance for 180 days... Amazon light sail... 2TB egress all in 22$ per month.

Lightsail is a reasonable “keep costs boring” starting point for an EA that isn’t moving absurd data volumes. The free-tier / cheap-box phase is fine for build-and-measure; just don’t confuse uptime theatre with edge.

What I’d validate before caring about $22 vs a Google box:

• Order round-trip to your broker gateway (not ICMP to 8.8.8.8)
• Behaviour on reconnect / weekend restart
• Disk and clock stability (stale history → array nonsense / bad signals)
• What happens when Windows Update reboots you mid-London

Autonomous scalp robots die more often from ops than from “the logic was wrong.” Watchdogs, auto-restart, and a flatten-on-disconnect policy matter more than shaving another dollar off the VM.

If you’re comparing Amazon vs Google, run the same EA build on both for two weeks and compare reject rate + slip distribution, not CPU benchmarks. That’s the scoreboard that pays. What’s the broker endpoint region you’re aiming at?

[PropScalpDesk]

Autonomous scalp robots need ops, not just cloud

Building your own EA on cloud instances is a serious project. From a discretionary Frankfurt seat, my caution is simple: hosting is the easy part; surviving live costs, disconnects, and regime shifts is the work. Compare Amazon versus Google on latency and egress if you want — also compare how you kill the robot when the journal fills with errors.

Practical suggestions if you continue: hard daily loss in the EA, news flat filter, and a human approval stage before lot size leaves micro. Log every intervention. Autonomy without a kill-switch is a night-risk fantasy.

I will not pretend cloud choice creates expectancy. Logic and execution path do.

Document your interventions in the same journal you would use for discretionary trades. “The robot did it” is not a post-mortem. You chose the settings and the kill policy.

What is your first live success metric — days without critical errors, or actual cost-adjusted PnL after a month?

[PTScalper]

Amazon cloud free instance for 180 days... Amazon light sail... 2TB egress all in 22$ per month.

Lightsail is a reasonable “keep costs boring” starting point for an EA that isn’t moving absurd data volumes. The free-tier / cheap-box phase is fine for build-and-measure; just don’t confuse uptime theatre with edge.

What I’d validate before caring about $22 vs a Google box:

• Order round-trip to your broker gateway (not ICMP to 8.8.8.8)
• Behaviour on reconnect / weekend restart
• Disk and clock stability (stale history → array nonsense / bad signals)
• What happens when Windows Update reboots you mid-London

Autonomous scalp robots die more often from ops than from “the logic was wrong.” Watchdogs, auto-restart, and a flatten-on-disconnect policy matter more than shaving another dollar off the VM.

If you’re comparing Amazon vs Google, run the same EA build on both for two weeks and compare reject rate + slip distribution, not CPU benchmarks. That’s the scoreboard that pays. What’s the broker endpoint region you’re aiming at?

Hi LondonScalper,

You are 100% correct. In automated scalping, hyper-optimizing for CPU benchmarks or shaving a few dollars off a VM is a classic rookie trap. An autonomous trading robot lives and dies by network edge execution and operational resilience, not raw compute. A premium GCP instance is completely useless if Windows Update nukes your terminal mid-London session, or if a 3-second clock drift corrupts your price arrays and generates bad signals. Operational failures kill EAs significantly faster than flawed strategy logic.

With Amazon’s current Free Tier structure—which offers either $200 in onboarding credits or standard 3-month free trials on select Lightsail Windows and Linux instances—running a 90-day dual-cloud burn-in test to empirically compare AWS against GCP is functionally free.

[PTScalper]

Here is the infrastructure testing suite to validate your scoreboard:

1. Network Edge & Clock Validator (PowerShell)

ICMP packets (standard ping) are often deprioritized or routed differently by broker firewalls. You must measure the true TCP handshake latency to the broker's actual trading gateway. Furthermore, stale history from clock drift will ruin array indexing; NTP must be aggressively and continuously synced.

Code: Select all

<#
.SYNOPSIS
Validates TCP handshake latency to the Broker Gateway and checks NTP clock drift.
#>
$BrokerGateway = "192.168.1.100" # Replace with your broker's specific access server IP
$Port = 443 # Default MT5/cTrader encrypted port

Write-Host "--- TCP Handshake Latency (True Round-Trip) ---" -ForegroundColor Cyan
$tcpMeasure = Measure-Command {
    $socket = New-Object System.Net.Sockets.TcpClient
    $task = $socket.ConnectAsync($BrokerGateway, $Port)
    $task.Wait(2000) | Out-Null
    $socket.Close()
}
Write-Host "Broker TCP Roundtrip: $($tcpMeasure.TotalMilliseconds.ToString('F2')) ms"

Write-Host "`n--- Clock Drift Check ---" -ForegroundColor Cyan
# Force time resync to prevent stale history
w32tm /resync /force | Out-Null
# Measure offset against reliable time server
w32tm /stripchart /computer:time.windows.com /dataonly /samples:1

[PTScalper]

2. Ops Resilience: Windows Hardening & Watchdog (PowerShell)

This script castrates Windows Update's ability to auto-reboot while a user is logged on and establishes a basic process watchdog. If the terminal crashes, updates secretly push, or the VM restarts over the weekend, this ensures the EA gets back online immediately.

Code: Select all

<#
.SYNOPSIS
Disables Windows Update auto-reboots and maintains terminal uptime.
#>
Write-Host "Disabling Windows Update Auto-Reboot..." -ForegroundColor Yellow
$RegPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"
if (-not (Test-Path $RegPath)) { New-Item -Path $RegPath -Force | Out-Null }
Set-ItemProperty -Path $RegPath -Name "NoAutoRebootWithLoggedOnUsers" -Value 1 -Type DWord

$ProcessName = "terminal64" # Use "cTrader" if running cAlgo
$AppPath = "C:\Program Files\MetaTrader 5\terminal64.exe"

Write-Host "Starting Terminal Watchdog..." -ForegroundColor Green
while ($true) {
    if (-not (Get-Process $ProcessName -ErrorAction SilentlyContinue)) {
        Write-Host "[$(Get-Date -Format 'HH:mm:ss')] Terminal missing. Restarting..." -ForegroundColor Red
        Start-Process -FilePath $AppPath
    }
    Start-Sleep -Seconds 15
}

[PTScalper]

3. The EA Scoreboard: Slip & Reject Logger (MQL5)

You don't compare AWS vs GCP by looking at Task Manager. You run the exact same EA build on both for two weeks and compare this output. This snippet logs the exact microsecond delay of OrderSend, the resulting slippage, and tracks connection state for a strict flatten-on-disconnect policy.

Code: Select all

//+------------------------------------------------------------------+
//| Execution Scoreboard Snippet (MQL5)                              |
//| Logs true round-trip, slippage, and connection rejects           |
//+------------------------------------------------------------------+
void ExecuteTrade(MqlTradeRequest &request, MqlTradeResult &result)
  {
   double price_before = SymbolInfoDouble(request.symbol, SYMBOL_ASK);
   ulong start_micro = GetMicrosecondCount();
   
   // Check connection before sending (Flatten/Pause logic prerequisite)
   if(!TerminalInfoInteger(TERMINAL_CONNECTED))
     {
      Print("[EMERGENCY] Broker disconnected. Aborting trade / Triggering flatten.");
      return;
     }
   
   if(OrderSend(request, result))
     {
      ulong exec_micro = GetMicrosecondCount() - start_micro;
      double exec_ms = exec_micro / 1000.0;
      double slippage_points = MathAbs(result.price - price_before) / _Point;
      
      PrintFormat("[SCOREBOARD] SUCCESS | Exec: %.2f ms | Slip: %.1f pts", exec_ms, slippage_points);
     }
   else
     {
      ulong reject_micro = GetMicrosecondCount() - start_micro;
      PrintFormat("[SCOREBOARD] REJECT | Code: %d | Time: %.2f ms", result.retcode, reject_micro / 1000.0);
     }
  }

[PTScalper]

Ultimately, your closing question hits the only metric that actually dictates cloud choice: What’s the broker endpoint region you’re aiming at?

If your broker's matching engine is sitting in Equinix LD4 (London), NY4 (New York), or TY3 (Tokyo), you provision the VM in that exact data center region. Physical proximity to the FIX gateway dictates the provider; everything else is just uptime theatre.

[PTScalper]

Autonomous scalp robots need ops, not just cloud

Building your own EA on cloud instances is a serious project. From a discretionary Frankfurt seat, my caution is simple: hosting is the easy part; surviving live costs, disconnects, and regime shifts is the work. Compare Amazon versus Google on latency and egress if you want — also compare how you kill the robot when the journal fills with errors.

Practical suggestions if you continue: hard daily loss in the EA, news flat filter, and a human approval stage before lot size leaves micro. Log every intervention. Autonomy without a kill-switch is a night-risk fantasy.

I will not pretend cloud choice creates expectancy. Logic and execution path do.

Document your interventions in the same journal you would use for discretionary trades. “The robot did it” is not a post-mortem. You chose the settings and the kill policy.

What is your first live success metric — days without critical errors, or actual cost-adjusted PnL after a month?

Hi PropScalpDesk,

The first live success metric is unequivocally days without an unhandled critical error (or emergency manual intervention). Month 1 cost-adjusted PnL is statistical noise. Surviving 30 days of rollover spread spikes, broker gateway disconnects, CPI news turbulence, and weekend gaps without a margin spiral or a watchdog failure is structural alpha. You can optimize logic for PnL later; you cannot optimize a burned account.

Your caution from a discretionary seat is entirely accurate: autonomy without a hard kill-switch is a night-risk fantasy. An EA is not just a logic loop; it is a software system operating in an inherently hostile environment. Cloud choice just gives it a place to execute. The real engineering goes into the operational lifecycle, the failure states, and the risk gates.

[PTScalper]

The Risk Gate Hierarchy
To survive live execution, a robust architecture strictly separates trade logic from risk management. The strategy layer proposes the trade, but an independent risk manager disposes of it. This is typically structured in escalating layers:

Market Quality Gates: Your suggested news flat filter lives here. If the bid-ask spread exceeds a baseline, volume drops, or a high-impact news event is within 30 minutes, the gate rejects the signal. The EA stays online, but it refuses to participate in garbage liquidity.

Portfolio Circuit Breakers: This enforces your hard daily loss limit. If daily P&L drops below a specific threshold (e.g., -3%), or if the system registers a set number of consecutive losses, the circuit breaker fires. The EA does not just pause—it sends a flatten command to the broker, closes all open exposure, and locks itself out of the market.

System Watchdogs: This monitors the infrastructure. If the EA registers three broker API disconnects in five minutes, or if order execution latency suddenly spikes, the system-level kill switch triggers. The bot goes quiet until a human manually clears the fault.