dotCloud Renames Itself Docker, Inc.
On October 29, 2013, dotCloud announced it was scaling back its original PaaS business and renaming the company entirely around its container tooling.
On October 29, 2013, roughly seven months after Docker’s public debut at PyCon, dotCloud announced it was scaling back its original Platform-as-a-Service business and renaming the company entirely to Docker, Inc. — a full pivot from PaaS provider to container technology company.
A company betting on its own side project
This kind of pivot — a company abandoning its original core business to focus entirely on internal tooling that turned out to resonate more with the market — is a genuinely uncommon move, and it reflected just how strong the response to Docker’s public introduction had been earlier that year. Just over a month before the rename, dotCloud and Red Hat had already announced an alliance integrating Docker with Red Hat’s OpenShift PaaS offering, on September 19, 2013 — an early sign that Docker was gaining real enterprise credibility independent of dotCloud’s own original platform.
Why the timing mattered
Committing fully to Docker in October 2013, rather than continuing to run it as a side project alongside the original PaaS business, positioned the newly-renamed company to capture the container ecosystem’s growth directly rather than as one PaaS vendor among many using containers internally. This decision preceded the explosive growth of the broader container ecosystem — Kubernetes’ 1.0 release and CNCF formation were still almost two years away at this point.
The pivot also reduced an identity conflict. dotCloud was both a hosted platform and steward of tooling that other platforms might adopt. Centering the company on Docker made the tool itself the product strategy, while open source let competing infrastructure providers integrate it. That combination expanded reach but created a lasting challenge: converting broad open-source influence into a sustainable commercial business.
Ecosystem growth exceeded one company’s boundaries
Docker’s image and developer workflow became common even as runtime, orchestration, registry, build, and networking responsibilities separated into projects and standards. The OCI standardized image and runtime contracts. containerd moved to CNCF governance. Kubernetes adopted CRI and eventually removed its internal Docker Engine shim. None of those changes erased Docker’s impact; they show how a successful interface can become an ecosystem whose components outgrow the original product.
This distinction prevents a common historical mistake: “Docker” can refer to the company, the Docker Engine and CLI, a build workflow, a container image ecosystem, or containers generally. Those are related but not identical. The 2013 rename aligned company and project names at precisely the moment the technology began expanding beyond both.
The strategic lesson from the rename
An internal capability can deserve a company-level pivot when external demand, contributor energy, and platform leverage exceed the original product. But the more foundational the technology becomes, the more users demand neutral standards, interoperability, predictable governance, and portability away from a single vendor.
Docker, Inc.’s later history included product and business changes, while Docker-compatible workflows remained deeply embedded in software delivery. That divergence is not a contradiction. It is evidence that the October 2013 bet helped establish a durable developer abstraction whose value spread across many vendors and open-source projects.
The longer-term outcome
Docker, Inc. went on to popularize container technology industry-wide over the following years, though the company’s own commercial trajectory later diverged somewhat from the open-source Docker Engine’s continued widespread adoption — a common pattern where the technology’s influence outlasted and outgrew the fortunes of the specific company that introduced it.
Related:
- Solomon Hykes Demos Docker Publicly for the First Time
- Fixing ‘No Space Left on Device’ from Docker Image and Container Buildup
Sources: