Containers & Kubernetes
Package the app with its world, then let an orchestrator keep fleets of them running — the default shape of modern health-IT infrastructure.
In one line
A container freezes an application plus every dependency into one runnable image ("works on my machine" becomes "works everywhere"); Kubernetes runs many containers across many machines, restarting, scaling and routing automatically.
How it works
Containers share the host kernel but live in isolated namespaces — lighter than VMs, started in milliseconds, built from layered images (Docker being the household name). Kubernetes adds the control plane: you declare desired state ("three replicas of the FHIR service, this much memory") and controllers reconcile reality toward it — self-healing, rolling deployments, service discovery, secret management. The cost is real operational complexity; managed offerings (EKS/AKS/GKE) and simpler platforms exist precisely because of it.
Where it shows up in digital health
Hospital integration engines, FHIR servers and AI inference services increasingly ship as containers; national-scale platforms run on orchestrators; and per-user lab sandboxes (this platform's phase 2 question) weigh containers against WASM for isolation. Our own cost rule applies here too: Kubernetes earns its weight at fleet scale — a single Next.js app does not need it.