Containerisation is now the baseline expectation across Australian software teams, from early-stage startups to large enterprise shops running dozens of microservices. But shipping a working Docker image and operating containers reliably in production are two very different things. Teams that skip foundational practices tend to hit the same problems repeatedly: bloated images, inconsistent environments, poor secrets management, and security vulnerabilities that were entirely preventable. Here is a practical look at what the best Australian dev teams actually do.
Start with lean, purposeful images
The single most consequential containerisation habit is keeping images small and intentional. Large base images carry unnecessary packages, which increases the attack surface and slows down build pipelines. Most teams start with a distribution like Ubuntu or Debian out of familiarity, then never question it. A better approach is to evaluate minimal base images such as Alpine or Distroless for services that do not need a full operating system environment. For compiled languages like Go or Rust, multi-stage builds let you compile in a full environment and copy only the final binary into a minimal runtime image. The resulting image can be ten times smaller, which also speeds up pulls in deployment pipelines.
Layer caching is the other discipline that pays off quickly. Structuring your Dockerfile so that rarely changing instructions appear early, and frequently changing ones like copying application code appear late, means Docker can reuse cached layers more often. This can turn a three-minute build into a thirty-second one on most pipelines. The discipline is simple, but many teams only adopt it after feeling enough pain from slow feedback loops.
Treat image security as a build-time concern, not an afterthought
Security scanning should run as part of the CI/CD pipeline, not as an occasional manual check. Tools like Trivy, Snyk, and Docker Scout integrate directly into CI/CD pipelines and can fail builds when critical vulnerabilities are detected in base images or dependencies. The goal is to make a vulnerable image impossible to deploy rather than catching problems after the fact.
Running containers as a non-root user is another baseline control that many teams still miss. The default container execution model runs as root inside the container, which is fine for local development but deeply undesirable in production. A Dockerfile should include a USER instruction that switches to a lower-privileged account before the application process starts. Combined with read-only root filesystems and dropping unnecessary Linux capabilities, this significantly reduces the blast radius if a container is compromised.
Secrets management is where Australian teams consistently stumble. Hardcoding credentials into environment variables baked into images is a pattern that turns up in source control leaks and container registry exposures far more often than it should. The correct approach is to inject secrets at runtime using a dedicated secrets manager, whether that is AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault, so that no sensitive value ever lands in a container image layer.
Understand the boundary between Docker and Kubernetes
One of the most common points of confusion for teams scaling up is knowing when to introduce an orchestrator. Docker Compose is a perfectly appropriate tool for local development and simple single-host deployments. Once you need horizontal scaling, rolling updates, health-based restarts, or service discovery across multiple hosts, Kubernetes becomes the right layer to operate at. The distinction is worth being deliberate about, and our guide to Docker vs Kubernetes covers that boundary in detail for teams at the decision point.
When Kubernetes is the right fit, the quality of your resource requests and limits matters a great deal. Containers without resource limits will happily consume all available CPU and memory on a node, starving neighbouring workloads. Setting requests (the amount reserved) and limits (the maximum allowed) for every container is table stakes for stable cluster operation. Australian teams using managed Kubernetes services on AWS EKS, Azure AKS, or GCP GKE should also familiarise themselves with node autoscaling behaviour, because misconfigured resource requests are the most common reason autoscaling underperforms expectations.
Build for observability from the start
Containers are ephemeral by design, which makes traditional approaches to logging and monitoring a poor fit. Writing logs to files inside a container means losing them when the container restarts. The correct model is to write structured logs to stdout and stderr, letting the orchestrator and a log aggregation layer capture them. JSON-formatted logs with consistent field names make it far easier to query and correlate events across many containers in a fleet.
Health checks are another basic that gets skipped more often than it should. Kubernetes liveness and readiness probes tell the scheduler whether a container is running and ready to receive traffic. Without them, a container that has started but is deadlocked will continue receiving requests it cannot serve. A readiness probe that actually exercises the application path, rather than simply checking that the process is alive, gives a much more meaningful signal.
The broader conversation around observability signals, including metrics, traces, and logs, is one that dev teams often defer until incidents force the issue. Getting those foundations in place before production traffic arrives is consistently less painful than instrumenting a system under pressure. The principles that apply to containerised workloads mirror those covered in a deeper look at observability vs monitoring for modern dev teams.
Standardise environments across the delivery lifecycle
One of containerisation's core promises is environment consistency: the container that runs in CI should behave the same way in staging and production. That promise only holds if teams are disciplined about it. Using a different base image in development than in production, or installing additional tools in CI that are absent at runtime, are common ways to introduce drift. Pinning base image versions using digests rather than floating tags like latest is the most reliable way to ensure reproducibility over time.
Infrastructure-as-code practices should extend to container configuration. Kubernetes manifests, Helm charts, or Kustomize overlays should live in the same repository as application code and be subject to the same code review discipline. Configuration changes that bypass review are a leading cause of production incidents in containerised environments. Teams that establish this practice early avoid a great deal of operational pain as their container footprint grows.
Australian teams also need to factor in local compliance considerations when deciding where container images are stored and where workloads run. Using a container registry in an Australian region or a sovereign-aligned provider is increasingly expected for workloads handling sensitive data, particularly in healthcare, finance, and government adjacent contexts. That is a layer of planning that purely technical containerisation guidance often overlooks, but it shapes real procurement and architecture decisions.