Why We Chose Rust for a Deployment Platform

Every Rust project eventually publishes a post about memory safety. This isn't going to be that post. Memory safety is real, and it matters, but it's not why we chose Rust for a deployment platform. There are better reasons, and they're more concrete.

TL;DR: Rust lets us ship a single ~30MB binary with no runtime dependencies, idle at 50MB RAM (vs 600MB+ for equivalent Node/Go/Python services), and run a proxy with zero GC pauses under load. Cross-compilation produces 4 target binaries from one source. The tradeoff: longer compile times and a steeper learning curve.

The Single Binary Problem

Deployment tools have a distribution problem. Install a typical self-hosted PaaS and you're pulling Docker images, Node.js runtimes, PHP scripts, and a handful of dependencies that need to stay in sync. Something breaks in an update, and you're debugging which layer of the stack caused it.

Temps ships as one binary. No runtime, no interpreter, no package manager to satisfy. Download a ~30MB file and you're done. That binary contains the proxy, the deployment engine, the analytics pipeline, the error tracking backend, the uptime monitor, and the AI gateway.

Rust makes this possible. The compiler links everything statically. You cross-compile for x86_64-unknown-linux-gnu or aarch64-unknown-linux-gnu on a Mac, upload the artifact, and it runs. No "please install libssl-dev" errors on the target server.

Go can do this too, but Go has a garbage collector.

GC Pauses Are the Wrong Tradeoff for a Proxy

The proxy is the most latency-sensitive piece of the platform. Every HTTP request passes through it. When you're routing hundreds of concurrent connections and doing TLS termination, a pause of even 10ms is visible to users.

Go's garbage collector has gotten excellent. Modern Go applications see GC pauses in the 1-2ms range under normal conditions. But "normal conditions" is the problem. Under memory pressure, during a traffic spike, when large objects are being collected, pauses creep up. And a deployment platform sees traffic spikes by definition, because deployments themselves generate bursty internal traffic.

Rust has no garbage collector. Memory is freed deterministically when the owning variable goes out of scope. The proxy's latency profile under load is the same as its latency profile at idle. That predictability matters when you're routing traffic for a production application.

50MB for an Entire Platform

The full Temps process, handling active deployments, collecting analytics, running the proxy, and polling for uptime, idles at roughly 50MB of RAM.

Compare that to what you'd need to assemble the equivalent toolkit (approximate ranges from our testing):

A Node.js analytics server: 200-400MB resident
A Go-based proxy (Traefik): 50-100MB
A Python error tracking backend: 300-500MB
A monitoring daemon: 50-100MB

Stack them together and you're at 600MB-plus before your first application is even deployed. On a small VPS with 2GB RAM, that's 30% of your available memory gone to tooling.

Rust's compiled code is dense. There's no VM overhead, no JIT warm-up, no per-request interpreter work. The binary does exactly what the source code says, at hardware speed.

Cross-Compilation Without Tears

Temps runs on Hetzner ARM instances, on x86 bare metal, on Raspberry Pi clusters, and on Apple Silicon development machines (for local testing). Supporting that matrix without Rust would mean maintaining separate builds, separate runtimes, or a virtualization layer.

With Rust, cross-compilation is a compile flag. The CI pipeline produces four target binaries from the same source: x86_64-linux-gnu, aarch64-linux-gnu, x86_64-darwin, and aarch64-darwin. The install script picks the right one. No containers, no QEMU, no emulation layer needed on the target.

The Proxy Handles Thousands of Connections Without Struggling

Temps uses Pingora (Cloudflare's proxy engine, also written in Rust) for all traffic routing. Cloudflare open-sourced Pingora because nginx's architecture doesn't handle connection reuse well at scale. Cloudflare processes trillions of requests per day through it.

Pingora uses async Rust (tokio) for its I/O model. Each worker thread handles thousands of concurrent connections through non-blocking I/O, without the per-connection thread overhead of nginx's workers. The result is consistent throughput under load, not throughput that degrades as connection count climbs.

For a platform that's doing zero-downtime deploys (spinning up new containers, running health checks, swapping routes under live traffic), this matters. The proxy doesn't buckle when deployment events create a burst of internal routing work.

A Practical Note

None of this means Rust is the right tool for every problem. The landing page is Next.js. Infrastructure scripts are bash. Rust earns its complexity budget specifically where you need compile-time guarantees, low overhead, and predictable runtime behavior. The key question when evaluating Rust for a project is whether the proxy and concurrency requirements justify the learning curve and compile times. For a deployment platform's core, the answer was yes. For a lot of other projects, it wouldn't be.

If you're curious about the practical implications of these choices, see how git-push deployments work under the hood for the pipeline Rust powers, or how to add zero-downtime deployments to any Docker app for the traffic swap details.