Promote an upgrade without surprises

Built for platform leads who fear the Monday morning upgrade that pulled in packages nobody reviewed, and the afternoon spent working out which one broke the service.

Most teams point their machines straight at an upstream repository, so the package set moves whenever upstream moves. Nobody decides when that happens and nobody sees the list. When something breaks after an update, the first hour goes on working out what actually changed, usually by comparing one machine against another by hand.

You mirror the sources you approve, then freeze that mirror into a snapshot. The snapshot never changes, so it is safe to test against. When you build the next snapshot, Package-Master lists exactly which packages moved and which advisories name those packages. You read that list before you point production at the new one, not after.

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 hand a colleague the package list for any snapshot, the difference between two snapshots, and the record of which snapshot was published to which endpoint and when. Package-Master does not certify anything and does not produce audit reports. These are operational records, useful to whoever asks what changed.

How is this different from just pinning versions?

Pinning fixes named packages. A snapshot freezes the whole set, including the things you did not think to pin. You also get the list of what moved between one set and the next, which pinning does not give you.

Can I roll back if the new snapshot is bad?

Point the endpoint at the previous snapshot. The old one still exists and is unchanged, because snapshots are never edited or deleted by an update.

Does this slow down getting security updates out?

It adds a review step you control. You choose when to build the next snapshot. If you want the newest packages immediately, build and publish immediately.

What if our machines are not all Debian or Ubuntu?

Package-Master is Debian/Ubuntu-first. RPM and npm mirroring are shipped with fewer features than the APT path, and neither has advisory feeds today. Treat the APT side as the flagship and check the supported page for the current matrix.

Do you need SSH access to our machines?

No. Your machines pull from a web address. Scout, the free check, needs no keys, passwords, or tokens either.

• Check which snapshots carry a flawed package A flaw is published. See which of your sets hold the package, from the snapshot record.
• Put the same packages on every machine Point every machine at one frozen set. Stop drift before it starts.
• Control where your software comes from One allow-list. No machine quietly pulling from a stranger's repository.