1.2.3.3 Cloud Server Portability

Cloud server portability is the ability to take a Docker image built and tested anywhere and run it, unchanged, on a cloud provider's compute infrastructure, whether that is a general-purpose virtual machine, a managed container service, or a serverless container runtime.

Why Cloud Portability Matters

Cloud providers offer many different ways to run a container, and applications often move between them as requirements change — from a single VM early on, to a managed orchestration service as the application scales, to a serverless container platform for workloads with variable traffic. Because all of these accept the same image format, switching between them does not require rebuilding or reworking the application itself.

Running on a General-Purpose Cloud VM

The simplest form of cloud portability is running a container on a cloud VM exactly as it would run on any other host with Docker installed.

docker pull registry.example.com/myapp:1.0
docker run -d -p 80:8080 registry.example.com/myapp:1.0

Running on a Managed Container Service

Cloud providers offer managed services that run a container without the operator managing the underlying VM directly. These services typically require only the image reference and basic runtime configuration.

aws ecs run-task --task-definition myapp --cluster myapp-cluster

The image itself does not need to change to move from a self-managed VM to a managed service — only the deployment mechanism around it changes.

Running on Serverless Container Platforms

Serverless container platforms run a container only while it is handling requests, scaling the number of running instances automatically based on load, while still consuming the same image format as any other container runtime.

gcloud run deploy myapp --image registry.example.com/myapp:1.0

Registry Accessibility Across Clouds

For cloud server portability to work in practice, the cloud platform running the container needs network access to the registry storing the image, which is why teams often use a registry hosted by, or replicated to, the same cloud provider their workloads run on.

docker tag myapp:1.0 us-docker.pkg.dev/my-project/myapp:1.0
docker push us-docker.pkg.dev/my-project/myapp:1.0

Avoiding Cloud-Specific Lock-In at the Image Level

Because the image itself contains no cloud-provider-specific logic, an application packaged this way can generally be moved between cloud providers by changing only the deployment configuration around it, not the image's contents.