Skip to content

CONCEPT Cited by 1 source

Runtime environment detection

Runtime environment detection is the technique of having a single container image inspect its own runtime context at startup and adapt its behaviour — env vars, user/group ID, permissions, framework configuration — to the specific execution substrate it finds itself on. It is the mechanism that makes one cross-platform base image work across multiple execution contexts without per-context variants.

Detection signals

Common signals a container can inspect at entrypoint:

  • Environment variables injected by the substrate — SageMaker Jobs, SageMaker Studio, Kubernetes, and Fargate each inject characteristic env vars (e.g. SAGEMAKER_REGION, KUBERNETES_SERVICE_HOST, ECS_CONTAINER_METADATA_URI_V4). Their presence / absence is diagnostic.
  • Filesystem paths — e.g. /opt/ml/ for SageMaker, /var/run/secrets/kubernetes.io/ for K8s-injected service account tokens.
  • Metadata endpoints — EC2 IMDS, ECS metadata endpoint, etc., with different response shapes per substrate.
  • Process tree — parent process name / command line can hint at orchestrator.

What adapts

Once the substrate is identified, the entrypoint adjusts:

  • User / permissions — SageMaker Jobs run as root by default; K8s Pods may run as a non-root UID; notebooks in SageMaker Studio run as a specific Studio user. Each needs a different chown / useradd path.
  • Environment variables — source-specific env shape (e.g. translating K8s-style secret mounts to SageMaker-style env).
  • Framework configuration — Spark driver/executor mode, cluster endpoint, log4j config.
  • Metrics / logging / tracing transport — e.g. StatsD sidecar URL vs. aggregation gateway URL, depending on whether sidecars are supported.

Lyft / LyftLearn 2.0 instance

Lyft's LyftLearn cross-platform base images detect their execution environment at runtime and adapt to run correctly across three distinct contexts: SageMaker Jobs, SageMaker Studio notebooks, and Kubernetes model-serving pods. "These images detect their execution environment at runtime and adapt. They automatically configure different environment variables, use different users and permissions, and set up Spark appropriately for each context, all while preserving an identical core runtime." (Source: sources/2025-11-18-lyft-lyftlearn-evolution-rethinking-ml-platform-architecture)

The same image trains a model on SageMaker and serves it on K8s, which guarantees model-dependency parity between training and serving — a win for reproducibility independent of the migration.

Seen in

Last updated · 517 distilled / 1,221 read