Canary Deployments in Rust: A Step-by-Step Guide with Code Examples

Canary Deployments with Rust: Without Fear or Reproach

Imagine: you wrote a new feature in Rust, ran the tests (they're green!), deployed to production... and then 500 errors start pouring in, users are writing to support, and you're frantically rolling back the release. Sound familiar? If so, you're not alone. Deployment is always stressful, especially when the code works with hardware or under high loads.

But there is a way to make deployment almost painless: canary deployments. The idea is simple: you don't release the new code to all users at once, but to a small percentage (say, 5–10%). If everything is fine, you gradually increase the share. If not, you roll back, and only a handful of "canaries" know about it.

In this article, we'll look at how to implement canary deployments for a Rust service. You'll see code examples, load balancer configuration, and simple monitoring. Let's go!

Why Rust is Ideal for Canary Deployments?

Rust is not just another language. Its features make canary deployments particularly effective:

\n
• Memory Safety — Rust guarantees that memory leaks and data races won't make it to production. Fewer bugs = less chance the canary will fail.
\n
• Small Binary Size — cargo build --release produces a compact executable. It can be quickly copied to multiple servers or containers.
\n
• High Performance — Rust performs at the level of C/C++. This means your canary server won't "sag" under load, even if 10% of traffic is directed to it.
\n
• Ecosystem — crates like actix-web, tokio, tower provide ready-made tools for HTTP, load balancing, and metrics.
\n

The result: a Rust service is stable, fast, and easily amenable to granular traffic management. Perfect for canary!

Canary Deployment Architecture in Rust

Let's imagine we have a web service on actix-web. A regular REST API: it receives requests, writes to the database, and returns responses. We want to update the version from v1 to v2, but not all at once.

Basic scheme:

\n
1. Load Balancer (e.g., Nginx or HAProxy) distributes traffic between versions.
\n
2. Main Group (stable) — servers with v1, handling 90% of requests.
\n
3. Canary Group — one or two servers with v2, handling 10% of requests.
\n
4. Monitoring — collect metrics from both groups: errors, latency, RPS.
\n

When we confirm that v2 is working stably, we smoothly increase the weight of the canary group to 100%.

Step 1: Writing a Rust Server with Metrics

Our server will serve two versions of the /api/hello endpoint. For simplicity, the versions differ in the response string. In a real project, this could be different business logic.

// Cargo.toml\n[dependencies]\nactix-web = "4"\nactix-rt = "2"\nserde = { version = "1", features = ["derive"] }\nprometheus = { version = "0.13", features = ["process"] }\nlog = "0.4"\nenv_logger = "0.10"

Now the server itself. We'll add Prometheus metrics to monitor the health of the canary:

use actix_web::{web, App, HttpServer, HttpResponse, middleware::Logger};\nuse prometheus::{Counter, HistogramVec, register_counter, register_histogram_vec};\nuse std::sync::OnceLock;\n\n// Global metrics\nstatic REQUEST_COUNT: OnceLock<Counter> = OnceLock::new();\nstatic REQUEST_DURATION: OnceLock<HistogramVec> = OnceLock::new();\n\nfn init_metrics() {\n    REQUEST_COUNT.get_or_init(|| {\n        register_counter!(\n            "http_requests_total",\n            "Total number of HTTP requests"\n        ).unwrap()\n    });\n    REQUEST_DURATION.get_or_init(|| {\n        register_histogram_vec!(\n            "http_reques