How to Make `unattended-upgrades` Update Packages From Third-Party APT Repositories

On Ubuntu and Debian, adding a third-party APT repository makes its packages available to the package manager, but it does not automatically let unattended-upgrades install updates from that source. The administrator must add a matching repository rule to the automatic-upgrade configuration.

Each repository publishes release metadata, which describes its publisher, distribution, and other details. APT uses these fields to identify the repository. Find the values your repository publishes and use them to add a matching rule. Then check which package version APT would choose and simulate the upgrade before enabling automatic installation.

Find the repository’s metadata values

First confirm that APT can read the repository and its package lists:

sudo apt update
apt-cache policy package-name

Replace package-name with a package from the repository. The apt-cache policy output shows the available versions and the candidate version APT would choose. It also lists release fields that upgrade rules can match, including o= for origin and a= for archive or suite.

Use the repository’s published metadata values to identify it; do not infer them from its vendor name or web address. The Origin field gives the publisher’s name as the repository reports it. That name is different from the repository’s hostname. After apt update, check the InRelease file, or the older Release file, under /var/lib/apt/lists/. Ubuntu’s automatic-updates instructions explain how to find the Origin value there and compare it with the value shown by apt-cache policy.

Add a rule for the repository

Put your change in a separate file under /etc/apt/apt.conf.d/ instead of editing the package-managed 50unattended-upgrades file. Give the new file a name that sorts after the default file. This keeps your rule separate from the defaults and makes it easier to maintain. Ubuntu’s security-update guidance uses this approach.

For an Ubuntu Personal Package Archive (PPA), Allowed-Origins can match the PPA’s origin and the machine’s Ubuntu release codename. This example uses the documented sample PPA name; replace it with the origin for your own PPA:

sudo tee /etc/apt/apt.conf.d/90-unattended-third-party.conf >/dev/null <<'EOF'
Unattended-Upgrade::Allowed-Origins {
    "LP-PPA-ubuntu-security-demo:${distro_codename}";
};
EOF

For a repository that is not a PPA, use the origin and suite values you confirmed. Use Unattended-Upgrade::Origins-Pattern to match other release metadata. It supports origin and suite, as well as codename, site, and component. For example, replace the placeholders in this pattern with the repository’s actual publisher and distribution:

Unattended-Upgrade::Origins-Pattern {
    "origin=Vendor Name,codename=your-release";
};

A hostname-and-component pattern is another option when those fields best identify the source:

Unattended-Upgrade::Origins-Pattern {
    "site=repository-host,component=main";
};

These are matching rules, not instructions to install a particular version. The unattended-upgrades project documentation describes the available pattern fields and notes that custom patterns are added to the defaults unless you explicitly clear the existing list. To enable one repository and keep the defaults, add a targeted rule and leave the full list intact.

Check APT’s choice and simulate the upgrade

After saving the configuration, check the package’s candidate version again:

apt-cache policy package-name

Then run a simulation:

sudo unattended-upgrade --dry-run --debug

The dry run does not install updates. Its debug output shows which repository origins the tool checks and which packages it would upgrade. If the package does not appear, check whether the rule matches the repository metadata and whether APT selects the expected candidate. Pinning and held packages can block an update. Dependencies or other package-manager constraints can also prevent it. The Debian unattended-upgrades manual documents the dry-run option and the usual log directory, /var/log/unattended-upgrades/.

Keep repository trust separate from upgrade eligibility

An allow rule makes matching updates eligible for unattended installation; it does not make APT choose that repository’s version over every other candidate. APT preferences, also called pinning, set version priorities and influence which candidate APT selects. Ubuntu’s third-party repository guidance discusses pinning as a way to limit conflicts and control upgrades from external sources.

APT’s signature checks verify the repository metadata, but they do not certify that the publisher’s packages are safe or compatible. The Debian apt-secure manual explains that trusting an archive means trusting its maintainer. Before enabling unattended installation, assess the publisher and test updates for your software and distribution. A repository-level rule applies to every package that matches that source. To restrict upgrades to one named package, you need another mechanism.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com