Put the same packages on every machine

Built for infrastructure engineers who fear the bug that only appears on one machine, and the day spent finding out that box got a different version of something six weeks ago.

When machines install straight from an upstream repository, the version each one gets depends on the day it was built. A machine built in March and a machine built in June are not running the same thing, even from the same instruction. Rebuilding an old machine to match an existing one becomes guesswork, and the difference usually surfaces as a bug that will not reproduce.

A snapshot is a fixed set. Point every machine at the same snapshot and they install the same versions, whether that is today or in eight months. Rebuild a machine against an old snapshot and you get what that machine originally had. The set only moves when you decide to publish a new one.

If an upstream source is unreachable, the refresh for that source fails and what you serve does not change. Your machines never see a half-updated set: a new set is visible only once it is complete. Snapshots you already made are unaffected, because a snapshot never changes once created. Package-Master depends on PostgreSQL, so run that database with the same care as any other production database; the docs cover deployment topology. If you go past your machine band, nothing shuts off. We flag it and point you at the next plan, prorated.

No measured customer results are published yet.

You can show that two environments point at the same snapshot, and what the difference is when they do not. The publish history records which set was live at any past date. By default this is a record of what you offered your machines. For the ones you enroll with the optional fleet observer, your instance also records what each one reports as installed and how that drifts from the published set.

Do containers make this unnecessary?

Containers freeze the image, but the image is built from a package source that keeps moving. Two builds of the same file weeks apart can differ. This freezes the source the build pulls from.

How long do old snapshots stick around?

Snapshots you create yourself stay until you delete them, and deleting one that a published endpoint still depends on is refused. Automatic snapshots expire after 30 days by default, and you can tune that. Keeping many snapshots does not multiply your disk bill, so retention is a policy decision, not a storage problem.

Does this need an agent on every machine?

No. Machines use the installer already built into Debian and Ubuntu; you change the address they pull from. An optional fleet observer exists for teams that also want per-host install reporting and drift against the published set, but nothing about mirroring, snapshots, or serving depends on it.

How many environments do we get?

Team covers one connected environment. Operations covers two. The exact counts and machine limits are on the pricing page, in public.

What if two teams need different package sets?

Publish more than one snapshot to different addresses. Each team points at the set it needs.

• Promote an upgrade without surprises See every package change, and the advisories that name those packages, before it reaches production.
• Control where your software comes from One allow-list. No machine quietly pulling from a stranger's repository.
• Check which snapshots carry a flawed package A flaw is published. See which of your sets hold the package, from the snapshot record.