Em março de 2013, num lightning talk de cinco minutos no PyCon de Santa Clara, Solomon Hykes mostrou o que a dotCloud usava por baixo do PaaS. O nome era Docker. Em 20 de março o código abriu. Em junho de 2014 saiu a 1.0. Treze anos depois o Docker Engine 29.8.0 (3 de setembro de 2026) ainda é o jeito mais comum de empacotar um processo Linux — mesmo depois de o orquestrador da frota ter virado Kubernetes e o runtime de baixo ter virado containerd.
dotCloud, YC e um motor interno
Kamel Founadi, Solomon Hykes e Sebastien Pahl fundaram a dotCloud no Y Combinator do verão de 2010. O produto, lançado em 2011, era PaaS: você mandava o código, a plataforma empilhava runtime. Por baixo havia um motor de container que ninguém via. Hykes, francês, tinha passado pela Epitech e por um período nos EUA. O insight não era “inventar o container” — LXC, cgroups e namespaces já estavam no kernel. O insight era a experiência: um arquivo de receita, uma imagem empilhável, um comando para rodar igual em qualquer Linux.
A metáfora veio do porto. Container de navio: padrão ISO, empilha, troca de navio sem reempacotar a carga. Software merecia o mesmo. A baleia azul com caixas nas costas — Moby Dock — virou o mascote. Em outubro de 2013 a empresa largou o nome dotCloud e passou a se chamar Docker, Inc. O PaaS foi vendido. O motor virou o produto.
PyCon 2013: cinco minutos que mudaram o deploy
A palestra se chamava “The future of Linux Containers”. Cinco minutos, demo, aplauso. Em 20 de março de 2013 o código abriu. No começo o runtime default era LXC. Em março de 2014, na 0.9, o Docker trocou o LXC pelo libcontainer, escrito em Go, falando direto com cgroup, namespace, capabilities e apparmor/selinux. Menos dependência, mais controle. A API alta — build, run, push, pull — escondeu o kernel. Foi isso, e não a virtualização em si, que explodiu.
Quem já tinha LXC em produção olhou e disse “isso a gente já faz”. Quem nunca tinha olhado para cgroup passou a empacotar a aplicação em 40 minutos. A diferença era o Dockerfile e o Hub. Receita texto, camada cacheada, registry público. O “funciona na minha máquina” perdeu a desculpa — a máquina ia junto, em camadas.
1.0, Hub e a corrida de 2014–2015
A 1.0 saiu em 9 de junho de 2014, no mesmo verão em que o Google anunciou o Kubernetes. Docker Hub virou o GitHub das imagens. Em setembro de 2013 a Red Hat já tinha fechado colaboração (Fedora, RHEL, OpenShift). Em outubro de 2014 a Microsoft anunciou Engine no Windows Server. Em novembro a Amazon lançou o EC2 Container Service. IBM, Oracle, todo mundo queria a baleia no slide.
Em 22 de junho de 2015 Docker, CoreOS, Google, Microsoft, Amazon e outros anunciaram o que virou a Open Container Initiative: um padrão de runtime e de formato de imagem, para o mundo não ficar refém de um daemon só. runc nasceu daí (libcontainer doado). containerd — o runtime que o Engine já usava por baixo — foi doado à CNCF. Em 2017 a Docker criou o projeto Moby: o kit de peças open source, separado da marca comercial.
Swarm, Kubernetes e o que a baleia não orquestra mais
O Docker nunca quis ser “só o runtime”. Swarm mode entrou no Engine 1.12: cluster, serviço, overlay, Raft. Compose (beta em dezembro de 2013, 1.0 em outubro de 2014) já resolvia o laptop com YAML. O problema era a frota de verdade — dezenas de nós, rolling update, CRD, operador. Aí o leme do Google ganhou. Em 2017 a própria Docker anunciou suporte a Kubernetes. Swarm sobreviveu no nicho e no Docker Desktop; o padrão de produção ficou o heptágono. A história completa está em A história do Kubernetes.
O que restou para a baleia é o que ela sempre fez melhor: a imagem, o daemon da estação de trabalho, o Hub, o Compose. Em agosto de 2021 o Docker Desktop deixou de ser grátis para empresa grande — Personal no lugar de Free. O Engine no Linux, Apache 2.0, não mudou de licença. Confundir os dois é o jeito clássico de tomar susto no compliance.
O que o Docker realmente é
Não é máquina virtual. É virtualização no nível do SO: processos isolados por namespace (PID, net, mnt, uts, ipc, user), limitados por cgroup, empilhados num sistema de arquivos union (OverlayFS). Uma imagem é um template só-leitura; um container é a imagem mais uma camada de escrita. O daemon dockerd escuta a API; o CLI docker fala com o daemon. Registry guarda a imagem. Compose descreve um conjunto. Volume segura o dado quando o container morre.
Por baixo da 29.x o stack é OCI: runc executa, containerd gerencia o ciclo de vida, BuildKit constrói. O Engine 29.8.0 já embute containerd se o host não tiver um serviço separado, e fala nftables. Podman, nerdctl, CRI-O fazem o mesmo recorte sem o daemon da Docker, Inc. A receita — Dockerfile, camada, registry — é que pegou. Em março de 2026 a Communications of the ACM pôs Docker na capa, retrospectiva de uma década.
2026: Engine 29.8, Compose 5, Desktop pago
O Docker Engine 29.8.0 saiu em 3 de setembro de 2026. Go 1.26.8, BuildKit 0.33.0, containerd 2.3.4, runc 1.5.1. Flag --umask no run/create, AppArmor default configurável, hardening contra AF_VSOCK via socketcall de 32 bits. O Desktop 4.89.0 (31 de agosto) já empilhava Compose 5.5.0. Rootless ganhou gvisor-tap-vsock como driver de rede default.
No Linux o caminho livre continua o mesmo: pacote da distro ou o repositório oficial, Apache 2.0, sem EULA de Desktop. Para quem está começando, o material antigo deste blog ainda vale como primeiro contato — com a ressalva de 2017 — em Curso de Docker Grátis.
O que ficou
Um PaaS francês que não decolou, um lightning talk de cinco minutos e uma metáfora de porto. O kernel já tinha cgroup; faltava o verbo. docker run virou o verbo. O orquestrador da frota foi embora para o Kubernetes. O formato da caixa ficou.
O leme está em A história do Kubernetes. O hipervisor clássico, em Proxmox e VirtualBox. O kernel, em Linux faz 35 anos.
Da dotCloud ao Engine 29.8.0: a baleia ainda carrega as caixas. Apache 2.0 no Linux, EULA no Desktop, OCI embaixo. O lightning talk de 2013 cabe em cinco minutos. O resto do ecossistema, não.