Control where your software comes from

Built for platform owners who fear the answer to 'where did this package come from,' because the honest answer is a repository somebody added during an incident two years ago.

Adding an outside repository takes one line and no approval, so over time machines accumulate sources nobody reviewed. Each one is a supplier with quiet permission to put software on your machines. Most teams cannot list them without going and reading the configuration on every box.

You write down which sources are allowed. Package-Master mirrors only those, filters what comes through, and publishes the result to one address, signed with your own instance key. Your machines pin that key and verify every update against it, so the only way in is through the list you approved, and anything else fails the signature check.

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 the list of approved sources, what was mirrored from each, and what the published set contains. Scout, the free check, reads your current sources and shows what you are pulling from today. That is a starting picture, not a certification of anything.

Does Package-Master sign what it publishes?

Yes, by default. A filtered set is signed with your instance key, because filtering changes the index the upstream signature covered. An unfiltered mirror can instead pass the upstream Debian or Canonical signature through byte for byte. Trying to publish unsigned is refused unless an operator overrides it explicitly. One honest boundary: Package-Master does not verify upstream signatures when it ingests, so the signature proves the set is yours and intact, not that upstream was verified on the way in.

Can we still use a vendor repository we depend on?

Yes, if you put it on the approved list. The point is that it is a decision on a list, not a line somebody added on a machine at 2am.

What stops an engineer adding a source anyway?

Nothing in this product. It controls what your published set contains. Stopping a person editing a file on a machine is a job for your configuration management and access control.

Does filtering break dependencies?

It can, if you approve a package but not something it needs. Mirroring can follow hard dependencies, so the packages you approve arrive with what they require when those dependencies are within your approved sources. If policy excludes something a package needs, apt reports the unmet dependency when a client installs it, and the fix is to approve the missing package or its source.

Do you see our package list?

No. The product runs in your environment and does not phone home. It sends us no inventory, no usage data, and no telemetry.

• Put the same packages on every machine Point every machine at one frozen set. Stop drift before it starts.
• Control how updates enter your network Sync approved sources from your deployment. Serve packages internally.
• Promote an upgrade without surprises See every package change, and the advisories that name those packages, before it reaches production.