Shopify’s Docker Container Strategy and Best Practices

Shopify is an e‑commerce platform serving over 120,000 customers, including GE, Tesla, and GitHub. As the first Canadian internet company valued over $1 billion, its Ruby on Rails application runs on 1,700 processing cores and 6 TB of RAM, handling more than 8,000 requests per second, and now uses Docker to simplify cross‑platform packaging.

About packaging format selection – Docker offers many container formats, from lightweight single‑process containers to heavyweight full‑application containers. Shopify developers chose a “thin” container that isolates external influence to reduce CPU and memory load. The container includes an init process (PID 1) for monitoring, secret management, and services, plus a ppidshim (PID 2) that launches the application process (PID 3) so the app does not inherit directly from PID 1. Health checks are also provided to ensure proper operation.

Container “100 law” – When deciding which services to containerize, Shopify assumes a host might run 100 small containers and evaluates whether a given service should be run 100 times or shared on a single host. This rule helps choose the most efficient deployment model. In some cases only a “glue” component is needed, which can be achieved via configuration. The resulting container should contain everything the application needs and a host environment that provides Docker hosting and shared services.

About Debug – No special considerations are required; applications inside containers behave the same as when not containerized, and standard debugging tools work on Docker hosts, allowing developers to debug as usual.

Naming – Container names should describe their function (e.g., unicorn-1 , resque-2 ) and include the hostname for traceability (e.g., unicorn-1.server2.shopify.com ). Passing Docker host‑name labels into containers further simplifies issue tracking.

Registration and Deployment – GitHub commit hooks trigger container builds for each push, tagging containers with the Git SHA and storing the SHA in /app/REVISION for easier debugging. Successful builds are pushed to a private registry to accelerate deployment and reduce external dependencies. An Nginx reverse proxy caches GET requests to standard Python registry replicas; 10 Gbps network interfaces and the proxy mitigate the “thundering herd” effect and enable multiple registries with automatic failover.

(Source: infoQ)