The Generational Shift in Container Infrastructure — What Eleven Projects Left Behind

• Introduction — infrastructure is replaced by operational burden, not performance
• 1. rkt
• 2. dockershim
• 3. Classic Swarm
• 4. Docker Machine
• 5. Compose V1
• 6. Heapster
• 7. Apache Mesos
• 8. PodSecurityPolicy
• 9. CoreOS Container Linux
• 10. ingress-nginx
• 11. Terraform and Vagrant — the case where the license changed
• Conclusion — what replaces infrastructure is usually headcount
• Related reading
• Series

Introduction — infrastructure is replaced by operational burden, not performance

If frontend tooling is replaced by platform absorption, the infrastructure layer is replaced for different reasons: operational burden, standardisation, and the number of people available to maintain that standard. All eleven below were widely used in their day, and for most of them the successor path is written down in official documentation. Only entries where a dated fact — an official notice, a public maintainer statement, or repository archive status — was confirmed at the source made the list.

1. rkt

• What it was — an alternative container runtime from CoreOS. It ran without a daemon and treated the pod as a first-class unit.
• Why it was right at the time — the concern that container execution was tied to a single vendor's daemon was legitimate. It was a project that demanded a standard of a market that had none.
• What changed — the repository was archived on 24 February 2020, and the README states that the project has ended and all development and maintenance activity has halted.
• What took its place — containerd and CRI-O, while Podman inherited the daemonless execution model.
• What it left behind — the pressure to standardise container images and execution. That pressure led to the OCI standards, and every runtime today sits on top of them.
• When it is still right — never. The repository is archived and the successor path is clear.

2. dockershim

• What it was — adapter code Kubernetes carried itself in order to talk to Docker Engine.
• Why it was right at the time — before CRI existed, Docker was the only runtime Kubernetes could actually use; without this code early adoption would have been impossible.
• What changed — it was removed in Kubernetes v1.24. The official FAQ explains that the code was always intended as a temporary solution, and states that images produced by docker build work with all CRI implementations.
• What took its place — CRI-compatible runtimes such as containerd and CRI-O.
• What it left behind — the CRI interface itself. It is a case study in the correct order of operations: to remove an adapter, first define a contract.
• When it is still right — never. Note, though, that Docker as an image-build tool was entirely unaffected.

3. Classic Swarm

• What it was — the first Docker orchestration project, making many Docker hosts look like one.
• Why it was right at the time — extending to a cluster while keeping the existing Docker API had almost no learning cost.
• What changed — the repository was archived on 1 February 2021, and the README states that it is no longer actively developed, recommending the Swarm mode built into Docker Engine or another orchestration system.
• What took its place — Swarm mode inside Docker Engine, and Kubernetes.
• What it left behind — the idea of scaling out to a distributed system while preserving API compatibility, and the conclusion that orchestration belongs in its own layer.
• When it is still right — not Classic Swarm. Swarm mode is a separate thing and still works.

4. Docker Machine

• What it was — a tool that created and managed Docker hosts on virtual machines and cloud providers.
• Why it was right at the time — using Docker on a non-Linux laptop required a VM, and automating that management was real value.
• What changed — the repository was archived on 18 July 2025, and Docker's official retired list states that it is no longer maintained and directs users to Docker Desktop or Docker Engine directly.
• What took its place — Docker Desktop, and docker context for handling remote endpoints.
• What it left behind — the concept of switching between multiple Docker endpoints by name, which survives as the context feature.
• When it is still right — never. The official documentation designates a replacement path.

5. Compose V1

• What it was — the original docker-compose command, written in Python.
• Why it was right at the time — declaring several containers in a single file changed the local development experience.
• What changed — Docker stated in a blog post on 31 January 2023 that support would not be provided after June 2023 and that it would be removed from future Docker Desktop releases. The retired list likewise says it is no longer maintained and directs users to V2.
• What took its place — Compose V2, rewritten in Go and integrated into the Docker CLI as docker compose.
• What it left behind — the Compose file format. The implementation changed, but the declarative form people write survived intact.
• When it is still right — never. In most cases dropping the hyphen is the whole migration.

6. Heapster

• What it was — the early component that collected metrics for a Kubernetes cluster.
• Why it was right at the time — CPU and memory figures for autoscaling had to be gathered somewhere, and there was no standard API at the time.
• What changed — the repository was archived on 1 December 2018, and the README marks it as retired and states that no changes will be made.
• What took its place — the same README recommends metrics-server for autoscaling and Prometheus-format metric collectors for general monitoring.
• What it left behind — the conclusion that resource metrics for autoscaling and general monitoring should be separated. Today's metrics API structure came out of that.
• When it is still right — never. It has been archived for a long time.

7. Apache Mesos

• What it was — a cluster manager handling resource isolation and sharing at datacentre scale.
• Why it was right at the time — it was one of very few systems that actually ran clusters of tens of thousands of machines before Kubernetes, and offer-based two-level scheduling is still an elegant design.
• What changed — per the Apache Attic page, it became a Top Level Project in June 2013, retired in August 2025, and the move to the Attic completed in October 2025. The Attic is a read-only custodian with no authority to develop or release.
• What took its place — Kubernetes. The same page also points to a community fork called Clusterd.
• What it left behind — two-level scheduling and the framework concept, plus the proof that a datacentre can be treated as a single resource pool.
• When it is still right — maintaining a cluster you already run. It is hard to find grounds for adopting it fresh.

8. PodSecurityPolicy

• What it was — a built-in Kubernetes API that constrained the privileges a pod could request, cluster-wide.
• Why it was right at the time — there had to be a standard way to block privileged containers and host mounts, and expressing policy as an API object was the right direction.
• What changed — the official blog states it was deprecated in v1.21 and removed in v1.25. The same post said an easier and more sustainable replacement was in development.
• What took its place — Pod Security Admission and the Pod Security Standards, plus policy-engine tooling.
• What it left behind — the concept of enforcing pod security baselines at the admission stage. The replacements do the same job in the same position.
• When it is still right — never. The API itself no longer exists.

9. CoreOS Container Linux

• What it was — a minimal Linux distribution aimed solely at running containers, characterised by automatic updates and an immutable root filesystem.
• Why it was right at the time — it comes close to being the first case of enforcing "replace the server, don't repair it" at the OS level.
• What changed — Red Hat's official page states that the final updates were rolled out on 26 May 2020 and that bugs or security vulnerabilities discovered after that date will not be fixed.
• What took its place — the same page names Fedora CoreOS as the official successor.
• What it left behind — the combination of an immutable OS, automatic updates and declarative provisioning at boot. Most container-optimised distributions today follow that shape.
• When it is still right — never. No security fixes are produced.

10. ingress-nginx

• What it was — the most widely used controller implementing Kubernetes Ingress.
• Why it was right at the time — you could attach Kubernetes routing while writing familiar nginx configuration, and annotations absorbed almost any requirement.
• What changed — SIG Network and the Security Response Committee announced retirement for March 2026 in a notice dated 11 November 2025 and reconfirmed it in a statement on 29 January 2026. The repository was archived on 24 March 2026. The notices cite that one or two people maintained it in their spare time for years, and that the flexibility of allowing arbitrary configuration became insurmountable technical debt.
• What took its place — Gateway API implementations, and the other Ingress controllers listed in the documentation.
• What it left behind — a de facto standard for what an Ingress controller should do, and the lesson that opening extension points without limit makes the security surface unlimited too.
• When it is still right — never. The statement warns that staying on it after retirement leaves you and your users vulnerable to attack. Existing deployments do keep working and installation artifacts remain available.

11. Terraform and Vagrant — the case where the license changed

• What it was — the de facto standard tools for infrastructure definition and development-environment provisioning.
• Why it was right at the time — they still are. This entry is about distribution terms changing, not code quality.
• What changed — HashiCorp moved subsequent product releases from MPL 2.0 to BUSL 1.1 in an announcement on 10 August 2023. The same post states that commercial use remains possible except where providing a competitive offering, and that APIs, SDKs and most other libraries stay MPL 2.0.
• What took its place — for Terraform, OpenTofu reached general availability as 1.6.0 on 10 January 2024. It is a Linux Foundation project and describes itself as a community-driven fork.
• What it left behind — the tools themselves are unchanged. What remains is the practical instinct that license terms, and the possibility of them changing, belong in the dependency evaluation.
• When it is still right — for most users. Unless you are in the business of providing a competitive offering, the announcement imposes no constraint. A fork is worth considering only when organisational policy requires an OSI-approved license.

Conclusion — what replaces infrastructure is usually headcount

Performance was almost never the reason on this list. Standardisation drove dockershim and PodSecurityPolicy; ecosystem consolidation drove Classic Swarm and Mesos; maintainer headcount drove ingress-nginx.

That last case is the instructive one. According to the notice, a component used by roughly half of cloud native environments was being maintained by one or two people in their spare time. The risk in a dependency lies not in code quality but in the number of people who can maintain that code. Star counts do not show this.

Status information was verified directly on 2026-08-12. Projects sometimes become active again, so check the current state yourself.

Related reading

• Migrating from Docker to Podman
• What actually differs between containers and VMs
• Bus factor is the number of people who can decide
• Open source license shifts 2026
• Tools: Kubernetes Playground · SW Maintenance Checklist

Series

1. Build and frontend tooling
2. Infrastructure and containers (this post)
3. Data stores and queues
4. Languages, frameworks and runtimes
5. What replaces technology