snapshot.debian.org is an archive that stores past and current Debian packages so you can install them as they existed on a given date. Use it for reproducing an old build or investigating an incident, not as the source for images you ship long term, because a frozen date also freezes security fixes.
What it is
The service describes itself as a wayback machine that allows access to old packages based on dates and version numbers. It holds all past and current packages that the Debian archive provides, and covers archives such as debian, debian-security and debian-backports. A 2024 news item on the site lists about 172TB of data.
How you point apt at it
You use a timestamped archive URL in a sources line. The format from the site looks like this:
deb https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
Timestamps can be written as a date or as a date with time. If no import exists at the exact time, you get the latest earlier one. For HTTPS you need ca-certificates installed. For snapshots older than about 12 days, the signed release file will be treated as expired, so the site tells you to disable the valid until check, either with an apt option or in the sources line.
Why this is useful for supply chain work
| Use | Why a snapshot helps |
|---|---|
| Rebuilding an old release for an audit or bug hunt | You get the same package versions as the original build |
| Reproducible builds | The package source becomes a fixed input, not a moving mirror |
| Incident review | You can inspect the exact version that was available on a date |
| Bisecting a regression | Walk forward or backward by date |
This pairs well with a pinned base image, because pinning a version without fixing the source can still break when the mirror removes the old file. See should you pin apt package versions in a Dockerfile.
Why not to ship from a frozen snapshot
A snapshot never receives new fixes. An image built entirely from one date keeps every vulnerability that was unfixed that day, and none of the later patches arrive. Disabling the valid until check also removes a freshness safeguard on purpose, which is acceptable for a controlled rebuild and risky as a default.
A balanced approach:
- Keep production images on live repositories with a regular rebuild.
- Keep a recorded snapshot date alongside each release for forensics and reproduction.
- When you must reproduce, use the snapshot in a throwaway build and never promote that image.
- Scan any rebuilt image, so the vulnerability picture is current even if the package set is old.
A forensic example
Suppose a customer reports a bug in a release you shipped last spring. Your current build produces a different set of packages, because the archive has moved on. Pointing a throwaway build at a snapshot date from the release gives you the package set that shipped, so you can reproduce the behaviour and check which advisories applied at the time. That is what a snapshot is good at: answering questions about the past.
Quick check
Does snapshot.debian.org include security updates?
The site lists debian-security among the archives it holds, so you can reach security packages as they existed on a given date.
Why do I need to disable the valid until check?
Release files for older snapshots have expired, so apt rejects them unless you turn the check off for that source.
Safeguard produces an SBOM and dependency scan for your images, which lets you compare a rebuilt image against the original package list. Run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
