Learning Rust - Rust in the Cloud, Containers, and WebAssembly

#Introduction

Rust can be compiled into small, self-contained binaries — an advantage that makes it ideal for the cloud. Episode 16 discusses two worlds where Rust shines: containers and the cloud (Kubernetes, Cloud Run, serverless) as well as WebAssembly (running in the browser and at the edge).

You will build a lean Docker image from a static musl binary, deploy it, then compile Rust into WebAssembly with wasm-pack and wasm-bindgen. By the end of the episode, one language serves both the backend and the frontend.

#Static Binaries with Musl

#Why Static Binaries

A default Rust binary links against glibc dynamically, so it does not run in images that do not have it. With the musl target, Rust produces a fully static binary: no dependency on system libraries. The result is a single file that runs in any minimal container.

#Cross-Building with the Musl Target

rustup target add x86_64-unknown-linux-musl
cargo build --release --target x86_64-unknown-linux-musl

rustup target add x86_64-unknown-linux-musl adds the compilation target. cargo build --release --target x86_64-unknown-linux-musl produces a static binary at target/x86_64-unknown-linux-musl/release. This binary can be copied into a minimal image.

#Docker and Distroless

#A Multi-Stage Dockerfile

Use a Rust builder to compile, then copy the binary into a minimal runtime image:

FROM rust:1.85-alpine AS builder
WORKDIR /app
COPY . .
RUN cargo build --release
 
FROM gcr.io/distroless/cc-debian12
COPY --from=builder /app/target/release/aplikasi /aplikasi
EXPOSE 3000
USER nonroot
ENTRYPOINT ["/aplikasi"]

The first stage compiles with the full toolchain; the second stage contains only the binary, minimal runtime libraries, and a non-root user. gcr.io/distroless/cc-debian12 is a distroless image that has no shell — its attack surface is very small.

#Build and Run

docker build -t aplikasi:latest .
docker run --rm -p 3000:3000 aplikasi:latest

docker build -t aplikasi:latest . builds the image, docker run runs it. docker build uses the current context; make sure .dockerignore excludes target/ so builds stay fast. An optimized Rust image can be just a few tens of megabytes.

#Deploying to Kubernetes and Cloud Run

#A Deployment in Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aplikasi
spec:
  replicas: 3
  selector:
    matchLabels:
      app: aplikasi
  template:
    metadata:
      labels:
        app: aplikasi
    spec:
      containers:
        - name: aplikasi
          image: registry.contoh.com/aplikasi:1.0.0
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: /readyz
              port: 3000

Apply it with kubectl apply -f deployment.yaml. This manifest uses the probes we built in episode 15. kubectl scale deployment aplikasi --replicas=5 adds capacity according to load.

#Cloud Run and Serverless

Cloud Run executes containers without managing Kubernetes: just push the image, deploy, and the platform handles scaling. Small, fast-starting Rust binaries are very well suited to serverless because they minimize cold starts. A similar architecture applies to platforms such as Fly.io and AWS App Runner — all of them execute standard OCI containers.

#WebAssembly with Rust

#Why Rust for WASM

WebAssembly allows code to be compiled into bytecode that runs in browsers and edge runtimes at native speed. Rust is a first-class language for this: the wasm32-unknown-unknown toolchain produces a WASM module without any extra runtime.

#wasm-bindgen and wasm-pack

wasm-bindgen connects Rust and JavaScript types, while wasm-pack handles the build, packaging, and publishing:

cargo new --lib hitung-wasm
cd hitung-wasm
cargo add wasm-bindgen

cat > src/lib.rs <<'EOF'
use wasm_bindgen::prelude::*;
 
#[wasm_bindgen]
pub fn kuadrat(x: u32) -> u32 {
    x * x
}
EOF
cargo build --target wasm32-unknown-unknown

#[wasm_bindgen] exports the function to JavaScript. cargo add wasm-bindgen adds the dependency; the build targets wasm32-unknown-unknown. After cargo build --release, bundle it with wasm-pack:

wasm-pack build --target web

wasm-pack build --target web produces an ES module ready to import:

Usage in JavaScript

import init, { kuadrat } from "./pkg/hitung_wasm.js";
 
await init();
console.log(kuadrat(9));

After init() loads the WASM module, kuadrat(9) calls the Rust function from JavaScript. This example is the foundation for much larger WASM libraries and applications.

#Yew and a Rust Frontend

For full web applications in the browser, yew is a React-like framework written entirely in Rust: components, state, and event handling in one language. It fits when a team wants to share backend and frontend logic, or needs maximum browser performance. For most projects, the combination of a Rust backend plus a WASM module for the critical parts is the most pragmatic choice.

#Closing

Key takeaways:

• Static musl binaries run in any minimal container image.
• A multi-stage Dockerfile produces a lean image without a shell.
• Distroless minimizes the attack surface in production.
• Kubernetes and Cloud Run execute standard OCI images.
• wasm-bindgen connects Rust and JavaScript; wasm-pack packages it.
• Yew enables a pure-Rust frontend in the browser.

In the next episode 17 we will discuss CI/CD, testing, and release workflow — unit, integration, and property-based testing with cargo test and proptest, build and test pipelines with GitHub Actions, GitLab CI, or Tekton, as well as release management, semantic versioning, and binary distribution.