Package-Master

Version control for what your machines install

Freeze what your machines install. See what changed.

Signed, frozen Debian and Ubuntu package sets. Every change on the record, including who approved it.

When a customer, an auditor or a contract reviewer asks what your Linux machines install, answer from a record.

Package-Master mirrors the sources you approve and freezes them into snapshots that never change. It signs what it publishes and shows exactly what moved between versions. It runs inside your network, and nothing needs to reach us. Designed for deployment in an afternoon under supported conditions.

  • verified Every machine pointed at a snapshot gets the same packages, every time
  • verified Published sets are signed by default. An unsigned publish is refused
  • verified Scout, our free diagnostic, needs no secrets

Snapshot record · example

prod/noble · #0419

2026-09-14T03:00Z to 2026-09-15T03:00Z

  • removed openssl 3.0.13-0ubuntu3.4
  • added openssl 3.0.13-0ubuntu3.5
  • removed libc6 2.39-0ubuntu8.4
  • added libc6 2.39-0ubuntu8.5
  • removed linux-image-6.8.0-45-generic 6.8.0-45.45
  • unchanged 1,412 unchanged

verified signed · gpg ed25519 · 8F2A…4C1D· approved by release-eng

A product of 1001379963 Ontario Inc. Runs inside your network.

Illustrative record. Not a customer's data.

  • 500

    machines per environment

    Sovereign plan ceiling. Team starts at 50.

  • 1

    binary, 1 database

    PostgreSQL. Nothing else to run.

  • Any

    Debian or Ubuntu suite

    Read from the upstream, so new releases work without a product update.

  • amd64

    supported today

    Seven more architectures can be mirrored on a best-effort basis.

Nothing should change without you seeing it.

Can you say what changed in your machines' package set last month?

Ask that when an audit starts, a customer security review lands or a critical advisory drops. The answer usually lives in several places, and the gaps show up the moment it matters.

A checklist says you have a process. A record shows what your machines were given to install.

Audit prep eats engineering weeks

The record gets rebuilt by hand every cycle.

Security reviews stall deals

Buyers want to know what is on your machines before they sign.

Advisories land without a map

New Debian and Ubuntu security notices arrive faster than your team can match them to fleets.

How it works

Approve. Mirror. Publish.

Three steps, running continuously against the package sets you publish.

  1. Approve

    Write an ingress policy: which sources, vendors and package sets may reach your Debian and Ubuntu fleet.

  2. Mirror

    Package-Master mirrors what the policy approves and filters out the rest. You get a set you control, not whatever upstream holds today.

  3. Publish and watch

    Publish a snapshot to a stable endpoint and point your servers at it. Package-Master signs the published set by default, and shows what moved between one snapshot and the next.

For technical teams: Mirror, Snapshot, Publish Endpoint

Package-Master organizes managed repository operations around three primitives engineering teams already know:

PrimitiveDefinitionWhy it matters
Snapshot An immutable freeze of a mirror. Once created, a snapshot never changes. A stable reference for deployments and audits.
Publish Endpoint A unique URL your fleet installs from. Point your machines at it, and every one gets the same packages every time.

See the architecture one-pager →

Accountability, built in

One control plane for what's allowed in, and proof of what you published

Four capabilities. Each one answers a question a reviewer will ask.

CapabilityThe question it answers
Immutable Snapshots Never changes once created Did the package set change? A snapshot is a frozen copy of a mirror. Every machine pointed at it gets the same packages every time.
Signed Publishing Signed by default Is this set ours? Every published repository is signed, with the key served at a stable address so your machines verify each update. An unsigned publish is refused unless an operator overrides it.
Snapshot Diff Package-level delta What changed, and when? Every time a snapshot changes, Package-Master shows exactly which packages moved.
Ingress Policy Allow-list by source Did anything arrive unapproved? Package-Master mirrors only the sources your policy approves.
Technical capabilities for engineering teams

Package-Master also supports the underlying operations engineering teams expect:

  • Single binary, PostgreSQL only
  • Standalone or HA deployment
  • Controlled outbound sync. No vendor telemetry
  • REST API, CLI, and admin web UI
  • Managed APT repositories with curation policy
  • Cross-repository package search and query

Where are you exposed?

Five questions. If any answer starts with “I'd have to check,” that's the gap.

Scout's web check turns your answers, plus any Debian or Ubuntu package information you choose to paste, into a gap report. It needs no install and no secrets.

  1. 01 Can we prove where the software on our machines came from?
  2. 02 Can we show what our production machines install from?
  3. 03 Do we know who owns package sources and updates?
  4. 04 Would an audit trigger a manual evidence hunt?
  5. 05 Are our update paths trusted and controlled?
Questionnaire response time 50 to 70% target reduction
Audit prep time 50 to 80% target reduction

These are target outcomes based on buyer discovery. They are being tested in paid pilots. They are not measured customer results.

Optional: directional readiness calculator

Replace with your own numbers. Outputs are directional, not commitments. Scout remains the real diagnostic.

250
2
4
6
24
3
95
Evidence readiness score 31 (Developing)
Estimated manual effort 144 hours/year ($13,680)
Plan that fits these numbers Operations, $10,000/yr
Directional net savings $0 to $944/yr

Manual effort is reviews per year times hours per review, priced at your hourly cost. Savings apply the published 50 to 80% target reduction to that effort, minus the plan cost. Targets, not measured results. Prices are in CAD, tax included. Restricted-network deployments use Sovereign, priced separately.

Prove what you publish

Runs inside your environment, not ours

Sync approved upstream sources from your deployment. Serve packages inside your network.

Application Single binary
Database PostgreSQL only
Topology Standalone or HA
Restricted-network deployment Available today
Outbound connection Outbound access for upstream sync. No phone-home
Signing Signed by default. Keys served at a stable URL for apt signed-by

Full supported matrix →

Available now

  • Mirror Debian and Ubuntu sources, filtered by ingress policy
  • Immutable snapshots and signed publish endpoints
  • Diff packages between snapshot versions
  • Advisory feed tracking (Ubuntu USN, Debian Security Tracker)
  • RPM and npm mirroring (fewer features than the APT path)

Where it stops

  • Advisories are reported against what a snapshot holds. No version-aware affected/not-affected verdict.
  • Upstream sync and advisory updates need outbound access. Physical transfer into fully disconnected networks is in development.
  • No SBOM export.
  • No evidence packs or audit reports.
  • Authentication is role-based bearer tokens. No SAML or SCIM.

FAQ

Common questions

Is Package-Master replacing JFrog, Nexus or Cloudsmith?

No. Those tools store packages across many formats. Package-Master adds APT-native workflow, source control, advisory review and a snapshot record for the software your Linux machines install. Most teams run both.

We use aptly today. Do we need Package-Master?

If aptly covers your mirror workflow and one engineer can run it reliably, you may not need a platform yet. Package-Master is for when mirror operations, snapshot promotion and advisory tracking need a shared control plane instead of one person's scripts.

Is Package-Master replacing Snyk, Wiz, Aqua or Chainguard?

No. Those tools secure the application layer, the cloud layer or the container image. Package-Master covers the OS package layer underneath: the sources your machines install from.

How does the machine band work?

Each plan includes a machine count and a number of connected environments. Team covers up to 50 machines in 1 environment. Operations covers up to 250 machines across 2 environments. If you outgrow a band, upgrade from your account. There are no overage surprises and no per-seat math for headless devices.

Monthly or annual?

Both are available at checkout for Team and Operations. Annual works out about 17% less than paying monthly for a year on both tiers. Switch between them anytime from your account.

What happens if we exceed our machine band?

Nothing shuts off. We'll flag it and point you to the next plan up. Upgrades are self-serve from your account, prorated automatically.

Why isn't Sovereign in the checkout?

Sovereign is an annual contract per environment with offline licensing and controlled upstream sync. Physical transfer into fully disconnected networks is in development. It's invoiced, not subscribed. The price is public: $30,000/yr for the first environment and $24,000/yr (20% off) for each additional one, each covering up to 500 machines. Booking a call is about scoping the deployment, not negotiating the number.

Do you need access to our machines?

No. Scout and most discovery work need no SSH, passwords, private keys, tokens or other secrets. Production deployment uses the access model your team approves.

Is this a security audit?

No. Package-Master is a product, not an audit firm. It does not certify SOC 2, ISO or CPCSC, and it does not produce evidence packs or audit reports. It gives you a record of which packages each snapshot held and what changed between versions.

Can this run in restricted or regulated environments?

Restricted-network deployment is available today. Package-Master initiates sync with approved upstream sources and serves packages inside your network. Physical transfer into fully disconnected networks is in development.

Do you support SSO/SAML?

Not today. Package-Master uses role-based bearer-token authentication and does not ship SAML or SCIM. If your timeline depends on it, raise it on a Sovereign readiness call.

Where is Package-Master built, and does jurisdiction matter?

Package-Master is a product of 1001379963 Ontario Inc., based in Ontario, Canada. The flag matters less than where the product runs: inside your environment. We never receive your package data, so there is no vendor-side copy for any court, in any country, to compel. Canadian ownership can also matter for procurement under Buy Canadian and CPCSC rules. It does not remove every legal or supply-chain risk.

Get started

Know what your machines install. Prove it when you're asked.

Run Scout free. Then deploy Package-Master in an afternoon under supported conditions.

  • verified No secrets required to run Scout
  • verified Single binary, PostgreSQL only
  • verified Controlled upstream sync. Internal package delivery
  • verified Flat pricing, no per-seat math for headless devices

Checking what Package-Master covers? See supported releases and limits. Prefer email? [email protected]