Run containers without managing infrastructure using serverless container platforms. Covers AWS Fargate, Google Cloud Run, Azure Container Apps, cold start optimization, scaling patterns, cost comparison, and when serverless containers beat Kubernetes.
Serverless container architecture is a deployment model where container images serve as the unit of compute, and the underlying infrastructure is managed entirely by the platform. You package an application as a Docker image, push it to a registry, and the platform runs it in response to events—HTTP requests, queue messages, scheduled timers—auto‑scaling instances up and down, including to zero when idle. This matters when you need the encapsulation and reproducibility of containers without the operational burden of managing a cluster, when workloads are intermittent or event‑driven, or when you are spanning edge and cloud boundaries with a consistent artifact. It sits between traditional container orchestration (where you own the control plane and nodes) and function‑as‑a‑service runtimes that only support language‑level runtimes; here, the entire container filesystem, including system packages and binaries, is yours to control.
The first step is producing a Docker image that the platform can retrieve, verify, and execute. The workflow uses standard, real tooling:
docker build -t registry.example.com/my-service:$(git rev-parse --short HEAD) .
docker push registry.example.com/my-service:abc123The Dockerfile should define a single long‑running process (or an init‑managed tree of processes) that listens on the port or signal pattern the platform expects. Most platforms do not override CMD or ENTRYPOINT; they start the container and expect it to stay alive for the duration of the invocation. If the main process exits, the invocation ends. For HTTP‑triggered workloads, a web server listening on $PORT (or port 8080 by convention) is the common pattern.
Common pitfall: building an image with too many layers or large base images (e.g., full‑fat Linux distributions) inflates the artifact size, which directly impacts cold‑start latency and may exceed platform‑imposed size limits. Minimal base images (distroless, alpine, or distroless‑based) are recommended.
Once the image is in a reachable registry, the platform needs a description of how to invoke it. Most providers expose an HTTP API or CLI subcommand that accepts at minimum a container image reference and a trigger configuration. The interaction can be illustrated with a generic curl call that highlights the HTTP mechanic common to the pattern:
curl -X POST https://<platform>.com/v1/functions \
-d '{"image":"registry.example.com/my-service:abc123","trigger":"http","timeoutSeconds":60}' \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json"The request body typically includes:
image: the fully qualified image reference (registry, repository, tag)trigger: a string identifying the event source (http, queue, cron, etc.)timeoutSeconds: maximum wall‑clock time before the platform terminates the invocationmemory, cpu: resource caps (interpreted by the platform as container resource requests)The platform responds with a deployment ID, a URL or queue name, and status flags. If the image reference is malformed, the registry is unreachable, or the tag does not exist, the platform returns an error such as ImageNotFound or AuthorizationFailed before any runtime code executes.
Resource caps are how the platform isolates your container on shared infrastructure. They are usually expressed as key‑value pairs in the deployment manifest or via CLI/API flags. The platform translates these into container requests and limits; the exact mapping varies, but the semantics are consistent:
0.5 for half a vCPU) or a guaranteed share. The platform may throttle CPU usage once the limit is reached, or kill the process if the limit is hard.429 Too Many Requests, which can be misattributed to downstream services.Many platforms ship with sensible defaults (e.g., 128 MiB memory, 0.1 CPU, max concurrency = 1), but production workloads often need adjustment. The only way to know the right values is to observe the platform’s resource‑usage metrics during a load test.
Secrets are typically injected at container start‑up and are not persisted across invocations. The two common patterns are:
KEY=VALUE in the container’s environment before exec‑ing the entrypoint. Sensitive values are masked in logs, but the variable remains visible to the running process./etc/secrets/ or a path specified in the manifest) as a file readable only by the container user. The container reads the file at runtime.Many serverless container platforms do not retain secret values in the container image; they are supplied at deploy time. If your application reads secrets from ~/.aws/credentials or similar paths, you must configure the platform to mount or inject them explicitly.
Filesystem state is ephemeral by default. The container image and any layers are read‑only; the platform provides a temporary working directory that is emptied when the container stops. Some platforms support inline ephemeral volumes for temporary computation (e.g., processing a large file during a single invocation), but data written outside the designated temporary path is lost permanently. Persistent volume claims are rarely available in pure serverless container runtimes; if you need durable state, consider an external store (object storage, database) and treat the container as a stateless processor.
Outbound egress is usually permitted via the platform’s network configuration, often through a managed NAT gateway or proxy. Inbound HTTP triggers receive a public URL or are routed through a platform‑managed load balancer. The URL shape is platform‑specific (e.g., https://abc123.lambda-url.us-east-1.on.aws, https://my-function-xyz.ondigitalocean.app), but the mechanic is always an HTTPS endpoint that forwards the request into the container. Internal service‑to‑service calls, when supported, use private networking with platform‑managed mTLS or service‑mesh sidecars. If your application expects a specific host resolution or DNS configuration, verify that the platform does not override /etc/hosts or intercept outbound DNS queries.
The platform forwards stdout and stderr from the container to a log sink. Most providers offer a command or API to retrieve recent entries, but the exact syntax varies. A portable approach is to emit structured JSON logs, which aggregation tools can parse reliably:
{"level":"info","msg":"request processed","requestId":"xyz789","durationMs":42}If your container writes to a file, be aware that the file system is ephemeral; logs written to disk may not survive past the invocation.
Many platforms propagate a request‑level correlation ID (often as an HTTP header X‑Request‑Id or X‑Trace‑Id) into the container environment. Your container can echo this header in its response or use it to tag log entries and metric points. If your application emits tracing spans (e.g., OpenTelemetry), ensure the correlation ID is included as a tag or attribute so that end‑to‑end traces stitch together platform‑level and application‑level data.
Containers that spawn child processes and exit immediately are often killed by the platform before those children complete their work. If your application forks a subprocess (e.g., a build step, a compiler, a batch job) and expects it to finish after the main process exits, you will likely encounter premature termination. The recommended pattern is to run an init system as PID 1 (e.g., tini, dumb-init) that forwards signals and reaps children, or to structure your container so the main process stays alive until the subprocess finishes.
When the platform decides to shut down an instance (scale‑down, idle timeout, or deployment rollout), it sends SIGTERM. The container has a grace period—commonly 10 seconds—to handle the signal and exit cleanly. If your entrypoint catches SIGTERM but performs asynchronous work (database transactions, file writes) without a shutdown hook, the platform may force‑kill with SIGKILL after the grace period, resulting in incomplete request processing, corrupted temporary files, and ambiguous error reports in the platform dashboard.
A frequent production surprise is configuring a high max concurrency limit while allocating modest memory. The platform does not automatically throttle CPU or I/O to stay within the memory cap; instead, the Linux kernel OOM killer may terminate the container at any moment. The resulting error appears as a sudden 502 Bad Gateway or 503 Service Unavailable with no prior warning in the invocation logs. Conversely, setting concurrency too low for the allocated memory wastes capacity and increases request latency due to queuing.
If your registry is private and the platform’s service account lacks the necessary pull permissions, the first invocation of each scaled‑up instance fails with an ImagePullBackOff‑style error. This error does not surface in stdout/ stderr because it occurs before the container process starts. The deployment status page shows the failure, but operators often assume the code is erroring out, leading to unnecessary debugging cycles. Pre‑creating a platform‑scoped pull secret and binding it to the function or service definition resolves this silently.
Some platforms keep a warm instance running if the container’s main process maintains an open listening socket, charging a minimum billing increment (e.g., 100 ms) even when no requests are in flight. Other platforms scale to zero after a period of inactivity (often 5–15 minutes), and the next request incurs a cold start that includes image pull, filesystem teardown/re‑creation, and runtime initialization. If your workload has strict latency SLAs, you must know which behavior your platform exhibits and configure keep‑alive pings or reserved concurrency accordingly.
When the same Docker image is deployed across different serverless container providers, subtle differences surface: one platform may expose the request IP via X‑Forwarded-For, another via Remote-Addr; one may enforce a hard 50 MB environment‑variable limit, another may accept larger sets but truncate at runtime; one may propagate SIGTERM with a 5‑second grace period, another with 15 seconds. If you need to migrate or run across providers, containerize statically (no host‑dependency binaries, no apt-get‑style runtime setup), pin all dependency versions, and externalize all configuration via environment variables or a platform‑agnostic secret store. Test the identical image on at least two targets before committing to a multi‑cloud strategy.
Serverless container architecture lets you treat a Docker image as the atomic deployment unit while offloading cluster management, node provisioning, and runtime patching to a platform. The pattern is concrete: build a minimal Docker image, push it to a registry, describe the trigger and resource caps via the platform’s API or manifest, and let the control plane handle scaling, health checks, and lifecycle. The sharp edges—cold starts, OOM‑kills, signal handling, secret injection, and image‑pull authentication—are not theoretical; they are the difference between a smoothly running event‑driven system and one that silently fails in production. Write your Dockerfiles and deployment descriptions to be platform‑agnostic where possible, observe your invocation metrics early, and treat the container filesystem as transient.
This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy