When a cloud relay fits
You want a managed service that is optimized and maintained for you, you value reach across signals or accounts, and you are comfortable with a scoped, revocable token held vendor-side and one more party in the order path.
Local-first vs cloud relay
This is an architecture choice, not a scoreboard. It decides where your order path runs, where your keys live, and where risk checks happen. Both designs are legitimate. Here is what each one actually trades away.
A cloud relay means your order instruction transits a vendor-hosted server before it reaches your platform. A chart alert or an AI request hits the vendor cloud, which validates it and forwards it to a local component that submits the order. CrossTrade is the well-known example in the NinjaTrader 8 lane: an add-on runs inside NinjaTrader on your machine, and order instructions route through CrossTrade's servers to reach it. Execution lands locally, while the control path passes through the cloud.
Local-first inverts that. The bridge runs on your own machine, binds to localhost by default, holds your keys, and runs its risk checks before any order is submitted. No order is relayed through a vendor server. PitBridge is designed this way on purpose. It is a real tradeoff, not a free win, and the honest cost is that your machine is your uptime.
The tradeoff, dimension by dimension
Read this as a set of tradeoffs. A cloud relay adds a managed service and reach at the cost of one more party in the order path. Local-first removes that party at the cost of running the thing yourself.
| Property | Cloud relay | Local-first |
|---|---|---|
| Order and control path | The instruction transits a vendor server, then a local component submits the order. | Agent to a local daemon to the platform. No vendor server sits in the path. |
| AI and MCP endpoint | A hosted endpoint, reached with a vendor-side token. | A local endpoint, bound to localhost by default. |
| Credential custody | Permissions brokered vendor-side, often a scoped, revocable token. | Platform credentials stay on your machine. |
| Risk enforcement | Scope, permission, and recommended confirmation at the API surface. | A deterministic engine that checks each order before it is submitted. |
| Dependency surface | Vendor uptime is part of the order path. | The vendor is out of the path. Your machine and platform are not. |
| Tradeoff to weigh | A managed service, wider reach, one more party in the path. | Full control, and your machine is your uptime. |
Cloud relay
- Order and control path
- The instruction transits a vendor server, then a local component submits the order.
- AI and MCP endpoint
- A hosted endpoint, reached with a vendor-side token.
- Credential custody
- Permissions brokered vendor-side, often a scoped, revocable token.
- Risk enforcement
- Scope, permission, and recommended confirmation at the API surface.
- Dependency surface
- Vendor uptime is part of the order path.
- Tradeoff to weigh
- A managed service, wider reach, one more party in the path.
Local-first
- Order and control path
- Agent to a local daemon to the platform. No vendor server sits in the path.
- AI and MCP endpoint
- A local endpoint, bound to localhost by default.
- Credential custody
- Platform credentials stay on your machine.
- Risk enforcement
- A deterministic engine that checks each order before it is submitted.
- Dependency surface
- The vendor is out of the path. Your machine and platform are not.
- Tradeoff to weigh
- Full control, and your machine is your uptime.
When local-first fits
You want the order path and your keys on hardware you control, you want risk checks enforced on your own machine before an order is submitted, and you accept that running the bridge, and its uptime, is on you.
Choose based on your workflow
The honest way to choose is to decide where you want the order path and the risk checks to live, then accept the cost that comes with it. A cloud relay hands you a managed path and adds a dependency. Local-first hands you control and hands you the maintenance. Neither is safer in the abstract, and neither promises anything about your results. Pick the tradeoff you would rather live with on a bad day.
Questions
What is a cloud relay in trading automation?
A design where your order instruction transits a vendor-hosted server before it reaches your trading platform. The signal, or the AI request, hits the vendor's cloud, which then delivers it to a local component that submits the order.
Does CrossTrade route orders through its own servers?
Order instructions pass through CrossTrade's cloud servers on the way to the add-on inside NinjaTrader 8, where the order is submitted. Execution lands locally, while the control path passes through their cloud. That is a cloud-relay architecture, stated neutrally.
Is local-first faster than a cloud relay?
Not necessarily, and we do not claim it. Latency depends on many things, and cloud relays can be well optimized. Local-first removes an extra network hop and a vendor dependency from the order path. That is an architecture difference, not a promise of faster fills.
Where are my credentials stored with each design?
With a cloud relay, permissions are usually brokered vendor-side, often through a scoped, revocable OAuth token. With a local-first design like PitBridge, platform credentials stay on your own machine and no order is relayed through a vendor server.
What happens if the vendor's server goes down?
With a cloud relay, the vendor's uptime is part of your order path, so a relay outage can affect your route. A local-first bridge removes the vendor from the path, but it still depends on your own machine, your platform, and your broker connection being up.
PitBridge is in development. NinjaTrader 8 is first.
Tell us your platform and we email you when your setup is supported. Nothing else.