Why We Ship Single Binaries

The container revolution was a genuine step forward for software deployment, but for latency-sensitive trading tools it introduced a layer of abstraction that costs more than it gives. Container runtimes add startup overhead, filesystem overlays slow down I/O, and orchestration platforms introduce failure modes that have nothing to do with your trading logic.

At Cox, we took a different route. Every tool we ship is a statically linked binary with zero runtime dependencies. You download it, set the executable bit, and run it. There is no Docker image to pull, no Kubernetes manifest to apply, no dependency tree to audit. Upgrades are a file copy. Rollbacks are renaming a file.

This approach pays dividends beyond simplicity. Static linking lets us control every byte of the binary, which means we can profile and optimize the entire call stack without hitting opaque shared-library boundaries. It also makes reproducibility trivial: the binary a client tests in staging is bit-for-bit identical to the one running in production.

The trade-off is real engineering effort. We maintain our own allocator, our own TLS implementation, and a custom build system that cross-compiles for Linux, macOS, and FreeBSD. But that cost is ours to bear, and the payoff is a deployment experience that our clients describe in one word: boring. And boring, in production, is the highest compliment.