Why every bot runs in its own container

On StrategyBox, every strategy you deploy runs inside its own isolated container. Not a shared process, not a thread pool, not a tenant slot in some giant service — one container per running strategy, per account. This is a deliberate engineering choice, and it shapes almost everything else about how the platform behaves under stress.

One failure should stay one failure

Automated trading code fails in unglamorous ways. A parser hits an unexpected message shape, a dependency throws on a null, an infinite loop pins a CPU core. The question is never whether something will misbehave — it's how far the damage spreads when it does.

If many strategies shared one runtime, a single bad actor could:

Exhaust memory and trigger an out-of-memory kill that takes neighbors down with it.
Corrupt shared in-process state that other strategies quietly depend on.
Block an event loop so that unrelated strategies stop reacting to the market.

Container isolation turns those account-wide outages into a local incident. When one strategy crashes, its container crashes. The blast radius is exactly one deployment. Your other strategies keep running, keep managing their positions, and never notice.

Hard resource limits, per container

Each container is given explicit CPU and memory ceilings. This matters for two reasons.

First, predictability: a runaway strategy cannot starve the rest of the platform, because it simply cannot consume more than its allotment. When it hits the ceiling, the kernel constrains it, not everyone else.

Second, honesty about capacity. Because every deployment has a known footprint, we can reason about how many strategies a host can safely carry instead of overcommitting and hoping. Isolation is what makes that arithmetic trustworthy.

Credentials never leak across strategies

StrategyBox is non-custodial — your funds stay on your own MT5, Binance, or Bybit account, and the platform never holds them. What each container needs is a scoped API credential to place and manage orders on your exchange, on your behalf.

We treat those credentials as the most sensitive thing in the system:

Per-container scope. A strategy's credential is injected only into the one container that needs it. Nothing else on the host can read it.
Kept off disk. Credentials are mounted through an in-memory tmpfs bind, not written to a durable volume. When the container stops, the secret is gone with it.
Withdrawal-disabled keys. The API keys are provisioned for trading only. Even in a worst case, a compromised container cannot move money off your exchange — the permission to withdraw was never granted in the first place.

Isolation here is not just about crashes; it's a security boundary. A problem inside one strategy's container cannot reach into another strategy's secrets.

Crash and restart, cleanly

Because a container is a clean, disposable unit, recovery is boring — which is exactly what you want.

The orchestrator watches each container's heartbeat.
If heartbeats go stale, the deployment is marked unhealthy and the container is stopped.
A fresh container is started from a known-good image, with credentials re-injected into a new tmpfs mount.
Repeated failures back off and eventually settle into a Faulted state instead of thrashing forever.

No half-alive process lingering with stale state. Each restart begins from the same clean baseline.

What isolation does not promise

Isolation makes the platform more robust; it does not make trading safe. Container boundaries protect one strategy from another's bugs — they do nothing about market risk. Automated strategies can and do lose money, and no amount of engineering changes that. Isolation is a floor under the infrastructure, not a ceiling over your losses. Treat it as the reason a single failing bot won't cascade — never as a reason to skip your own risk limits.