ROS 1 is EOL and deployed robots still need its packages
ROS 1 Noetic reached end of life on May 31, 2025.
That means no more security updates, bug fixes or updated binaries from the ROS team. It doesn't mean all the robots running ROS 1 disappeared with it.
Migrating an existing robotics stack can be a substantial project. Moving from ROS 1 to ROS 2 can involve changes to build tooling, parameters, nodelets and communication between nodes.
This has been a problem for years. In a 2022 ROS community discussion, a robotics company described trying to migrate a system with more than 100 interconnected ROS nodes without stopping normal product development.
And the problem hasn't gone away. In August 2026, a developer shared a Dockerized ROS 1 Noetic to ROS 2 Jazzy bridge built specifically to migrate a large legacy ROS 1 stack gradually rather than rewrite it all at once.
We saw the same thing shortly after Noetic reached EOL, when a robotics team reached out to us because they were still using ROS 1 on Ubuntu Focal and needed continued access to the ROS repositories.
For systems like these, being able to rebuild the old environment still matters.
And that depends on more than keeping the source code.
ROS packages depend on APT repositories
ROS packages on Ubuntu are commonly installed through APT.
ROS 1 Noetic packages were published from:
ROS 2 uses:
The official ROS 2 installation documentation configures packages.ros.org/ros2/ubuntu as an APT source before installing ROS packages.
When ROS 1 Noetic reached EOL, Open Robotics explicitly said that existing ROS 1 binaries would continue to be hosted on packages.ros.org.
That's useful, but repositories aren't static.
New package versions are published and the set of packages available from a repository changes over time.
That matters even when you've pinned a package to an exact version.
An exact ROS package version can still become unavailable
The Autoware project ran into this while working on reproducible builds in 2026.
Autoware already pinned several parts of its development environment, but ROS and system packages were still being resolved dynamically. That meant builds from the same commit could produce different environments depending on when they were run.
During the discussion, a contributor pointed out that the ROS build farm generally retains only the latest version of each package in its repository.
A version such as:
can be perfectly specific.
But if that build is no longer available from the repository, APT can't install it.
The version is pinned. The artifact it refers to isn't necessarily preserved.
Autoware's implementation plan for reproducible builds includes support for snapshots.ros.org for ROS packages.
Repository state matters too
A recent issue filed against the official ROS Docker images shows another version of the same problem.
In August 2026, a reporter found that the ros:lyrical-* images pinned ROS package versions but still pointed APT at the live ROS repository.
Installing an additional ROS package later could therefore bring newer binaries into the existing image.
In the reporter's reproduction, that produced an ABI mismatch and eventually:
They rebuilt the image against a dated ROS snapshot and verified that the same reproduction completed successfully.
The problem wasn't simply which package version had been requested. The repository state had changed underneath the image.
Pinning a package tells APT which version you want. It doesn't guarantee that version will still be available, or that the rest of the dependency graph will still look the same later.
ROS already provides snapshots
ROS has its own snapshot infrastructure at snapshots.ros.org, which keeps historical states of ROS package repositories.
For a build that only needs to preserve the ROS repository, that's a useful solution.
But a ROS build usually depends on more than ROS.
There are the Ubuntu packages underneath it, and potentially other APT repositories, Python packages, containers, CUDA packages or files downloaded directly during the build.
Each of those upstreams has its own lifecycle.
For a reproducible build, preserving the ROS repository is only part of preserving the environment.
StableBuild supports ROS 1 and ROS 2
StableBuild keeps dated copies of Ubuntu and third-party APT repositories and supports both ROS 1 and ROS 2.
For ROS 1 on Ubuntu 20.04:
ROS 1 support is tied to Ubuntu 20.04 Focal. StableBuild's Ubuntu 20.04 snapshots are available up until July 23, 2026 (see our official doc), so ROS 1 builds need a pin date on or before that date.
ROS 2 works in the same way. For example:
The important part is the pin date.
Come back to the build later and APT can resolve against the repository state from that date rather than whatever the upstream repositories contain now.
Old robots still need old software
ROS 2 has been around for years. Ardent Apalone, the first non-beta ROS 2 release, was released in December 2017, and migrating away from ROS 1 has been the recommended direction for a long time.
But replacing software inside an existing robot isn't the same thing as choosing ROS 2 for a new project.
A robot may have years of tested code, drivers, hardware integrations and operational assumptions built around ROS 1. Moving that stack can take time, and the old environment may still need to be rebuilt while that migration is happening.
ROS 2 doesn't remove the underlying dependency problem either. Autoware's reproducible-build work and the recent ROS Docker issue both involved ROS 2.
Keeping the source code is only part of keeping an old build reproducible.
You also need the packages it depended on.
We have a free Community tier if you want to try pinning your ROS and Ubuntu repositories to a date.
