Reprepro lets you host a private Debian APT repository on a VPS, keep packages in a managed pool, generate signed repository metadata, and distribute updates through normal apt commands. A secure deployment separates the signing key and internal state from the web server, publishes only the repository tree over HTTPS, and gives clients a narrowly scoped key with signed-by.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What reprepro does and why the layout matters
Reprepro is a repository-management program for Debian packages. It stores package files in a pool hierarchy, maintains the metadata beneath dists/, and signs the generated Release information with OpenPGP. Clients therefore use the normal APT workflow instead of downloading individual files manually. Debian describes it as particularly suitable for individual “PPA” repositories and smaller private archives.
As an Amazon Associate I earn from qualifying purchases.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchA safe VPS design has three logical areas:
| Area | Purpose | Exposure |
|---|---|---|
/srv/repo/pool/ and /srv/repo/dists/ |
Package files and generated indexes served to APT clients | Public, read-only through HTTPS |
/srv/repo/conf/ |
Distribution definitions and repository configuration | Private; never served by nginx |
/srv/repo/db/ |
Reprepro’s internal database and state | Private; never served by nginx |
| OpenPGP secret key | Signs Release metadata | Outside the document root and restricted to the administrative account |
HTTPS and OpenPGP solve different problems. A trusted signature lets APT detect altered metadata or packages, while HTTPS protects the initial delivery of the public key and prevents an attacker from substituting a different key during bootstrap. Use both.
Prerequisites and a sensible VPS boundary
Use a Debian VPS with administrative access, a DNS name for the repository, enough disk space for every package version you retain, and a backup destination separate from the VPS. The examples use /srv/repo, the hostname repo.example.com, and the Debian codenames bookworm and stable; replace them with values appropriate to your release policy.
- Use a dedicated repository account where possible. The account need not be named
reprepro; ownership is a deployment choice, but permissions must prevent the web server from writing to the repository. - Keep package uploads in a controlled staging or CI path. Do not give uploaders shell access to the public document root.
- Keep the signing key on a separate administrative workstation or in a tightly restricted VPS account. The web server needs the public files, not the secret key.
- Decide whether the repository is private to your organization or publicly readable. In either case, clients still need an authenticated signing key.
Install reprepro, GnuPG and nginx
On the VPS, install the repository tool, key-management software and web server:
sudo apt update
sudo apt install reprepro gnupg nginxCreate the repository and configuration directory with restrictive permissions. The following uses a dedicated reprepro account and group; create or substitute that account if your deployment uses another identity.
sudo install -d -m 0750 -o reprepro -g reprepro /srv/repo/confReprepro will create the remaining directories when it exports or imports packages. Verify that conf/ and, after initialization, db/ are not writable by nginx and are not inside a separately exposed web directory.
Create and protect the OpenPGP signing key
Generate the key in a controlled administrative account, not as the nginx user. An interactive creation flow is:
gpg --full-generate-keyChoose an appropriate signing-capable key, protect it with a strong passphrase, and record the complete fingerprint rather than relying on a short key ID.
gpg --list-keys --fingerprintUse that full fingerprint in the repository’s SignWith setting. Keep the secret key outside /srv/repo‘s public tree, restrict its filesystem permissions, and make an encrypted recovery backup. Export only the public key for clients:
Free tools Windows power users keep installed
One-click scans. No signup required.
gpg --armor --export <full-key-fingerprint> > /srv/repo/repository-key.ascFor unattended signing, a GnuPG agent is preferable to placing a passphrase in scripts. Reprepro’s --ask-passphrase option can prompt for a passphrase, but its documentation warns that this is less secure than agent-based handling for unattended operation. If a CI system imports the secret key, isolate that worker, limit who can trigger releases, and retain an audit trail of signing operations.
Define distributions in conf/distributions
Create /srv/repo/conf/distributions. Add one block for each Debian codename you intend to support:
Codename: bookworm
Suite: stable
Architectures: amd64 arm64 source
Components: main
SignWith: <full-key-fingerprint>
Origin: Example Project
Label: Example Project
Description: Example Project Debian packagesThe fields have distinct jobs:
| Field | How clients and reprepro use it |
|---|---|
Codename |
The stable identity of this distribution block and the target name used by import commands. Keep it unchanged for the life of that archive. |
Suite |
A moving label such as stable or testing. Change it only when your release policy intentionally retargets the label. |
Architectures |
The binary and source architectures for which indexes are generated. List only architectures you actually publish. |
Components |
Repository sections such as main; the component must match the client source entry. |
SignWith |
The complete fingerprint of the OpenPGP key that signs generated Release metadata. |
Origin, Label, Description |
Human-readable identity shown by repository tools and APT. |
If APT users need file-to-package lookups with apt-file, configure the optional Contents: generation described in Debian’s reprepro documentation. Contents indexes increase export work and storage, so enable them only when clients require that feature.
After saving the file, create symlinks and export the initial metadata:
Recommended Free Tools
cd /srv/repo
reprepro createsymlinks
reprepro exportRun these commands as the repository owner or with equivalent permissions. Fix ownership rather than repeatedly running the whole repository as root.
Add packages to the repository
Import a build using a .changes file
A normal Debian build produces a .changes file that describes the package set. Import it into the matching codename:
reprepro -b /srv/repo include bookworm path/to/package_1.0-1_amd64.changesReprepro copies the referenced package files into the pool, updates indexes and signs the resulting Release information. The target word bookworm must exactly match a configured Codename.
Import a standalone .deb
For a single Debian package without a changes file, use includedeb:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →reprepro -b /srv/repo includedeb bookworm path/to/package_1.0-1_amd64.debUse a consistent versioning policy. Replacing a package with the same version can create confusing client behavior; publish a higher Debian version when the package contents change, and remove obsolete versions only after checking that no supported client still needs them.
Check the generated tree before publishing
Inspect the output as the client will see it:
dists/<suite>/InReleaseshould exist, or there should be aReleasefile together withRelease.gpg.- Package files should be below
pool/, with paths and checksums referenced by the generated indexes. - The configured architectures and component should appear beneath the selected suite.
- The signing key fingerprint in your administrative records should match the key used to generate the Release signature.
Do not publish a half-exported tree. Finish the import and export, then test from a clean client that has never trusted the repository key.
Serve only the public tree with nginx and HTTPS
Point nginx at /srv/repo as its document root. A minimal HTTPS server block is:
server {
listen 443 ssl;
server_name repo.example.com;
root /srv/repo;
location ^~ /conf/ { deny all; }
location ^~ /db/ { deny all; }
location / { try_files $uri =404; }
}Use your Debian release’s current nginx TLS defaults and certificate automation. Certificate paths, protocol defaults and renewal commands vary by release and VPS provider, so do not copy obsolete TLS settings from an older tutorial without checking them.
Provide a separate port-80 server that redirects requests to the HTTPS hostname, then verify the redirect and the certificate from an external network. The repository must be read-only to the web process. A package upload should change the tree through a controlled administrative command, not through an HTTP request.
Test the internal-directory rules explicitly:
https://repo.example.com/conf/distributionsmust return a denial, not configuration text.https://repo.example.com/db/must return a denial.- A valid path under
dists/orpool/must return the expected static file. - Unknown paths should return a 404 rather than an nginx directory listing.
Bootstrap clients with a scoped keyring
Install the public key through an authenticated channel, such as your configuration-management system or a package that you distribute through an already trusted mechanism. Do not ask users to add the key to APT’s global trust store.
One manual installation pattern converts the armored key to a dedicated keyring:
gpg --dearmor < repository-key.asc | sudo tee /usr/share/keyrings/example-project.pgp >/dev/null
sudo chmod 0644 /usr/share/keyrings/example-project.pgpCreate a source-list file such as /etc/apt/sources.list.d/example-project.list:
deb [signed-by=/usr/share/keyrings/example-project.pgp] https://repo.example.com/ bookworm mainThe suite and component in this line must correspond to Codename and Components in the repository. The signed-by option limits this key’s authority to this source instead of making it trusted for every APT repository on the machine. After installing the keyring and list file, run:
sudo apt updateAPT should verify the signed metadata and offer packages from the configured component. If it reports a missing public key, a bad signature or a missing Release file, stop and correct the trust or path problem rather than bypassing signature checks.
Verify each release from a clean client
Use a disposable or freshly provisioned Debian client for acceptance testing. This catches errors hidden by cached metadata on an administrator’s workstation.
- Install the repository keyring through the approved bootstrap process.
- Install the
.listfile with the intended HTTPS URL, codename and component. - Run
sudo apt updateand confirm that the repository downloads a signedInRelease, or aReleaseplusRelease.gpg. - Install or upgrade a test package and confirm that its architecture and version are the ones you published.
- Repeat the test after every distribution change, signing-key change, nginx change or certificate renewal.
Keep the client output with the release record. It provides evidence that the exact keyring, source entry and metadata format work together.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Security and operations checklist
Protect signing material
- Never place the secret key below the nginx document root or in a world-readable backup.
- Use a dedicated administrative identity and a passphrase-protected key. Prefer a GnuPG agent for unattended workflows.
- Record the full fingerprint in deployment documentation and compare it before every keyring distribution.
Restrict repository state
- Deny
conf/anddb/at nginx and verify the denial from outside the VPS. - Make the web-facing tree readable by nginx but writable only by the repository owner or release automation.
- Separate upload staging from the public tree and validate packages before importing them.
Back up what is needed to rebuild
Back up pool/, the repository database, configuration files and signing-key recovery material separately. A backup containing only package files may not preserve the metadata and state needed for a clean restore; a backup containing only the key cannot recreate packages that have been discarded.
Plan key rotation
Publish the successor public key to clients before changing SignWith. Update client keyring packages or configuration, verify that new clients can run apt update, and only then begin signing with the successor. Retain the old public key for as long as clients may still hold metadata signed by it, following your chosen overlap period.
Best Value
Common failures and precise fixes
“Unknown distribution” or an import target error
The name after include or includedeb is not a configured Codename. Check spelling and capitalization in conf/distributions, then rerun the command with the exact codename.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →APT cannot find InRelease or Release
Verify that reprepro export completed, that the client suite matches the generated directory, and that nginx’s root points to /srv/repo. A 404 caused by a wrong root or suite is different from a signature failure; inspect the requested URL and server logs before changing keys.
APT reports a missing or invalid signature
Confirm that the client keyring contains the public key corresponding to the current SignWith fingerprint, that the source line uses the correct signed-by path, and that the VPS clock is accurate. Do not solve this by disabling signature verification or adding the key globally.
Packages appear in the pool but not in APT
Check that the package architecture is listed, the component matches the source entry, and the package was imported into the intended codename. Re-run the export, then clear only the affected client’s stale lists if necessary and run apt update again.
Clients can download files but internal data is exposed
Test the exact /conf/ and /db/ URLs externally. Add or correct the nginx deny locations, reload nginx, and retest. Do not rely on an unlinked directory being “hidden”; direct URL requests must be denied.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsWhen reprepro is the right size
Reprepro is a practical choice when you need a controlled Debian archive on one VPS or for a small group of distributions and architectures. It supports pools, multiple package versions, signed metadata and straightforward filesystem backups without requiring a separate database server. Its many options can make the initial configuration harder to learn, and a rapidly growing organization may eventually need stronger upload queues, mirroring workflows, delegated roles or centralized automation.
Evaluate the tool against the workload rather than package count alone:
| Decision axis | Questions to answer |
|---|---|
| Repository scale | How many packages, versions, suites and architectures must be retained? |
| Pool and version handling | Do you need shared pool storage and parallel versions across several suites? |
| Signing workflow | Where is the secret key held, who can sign, and how will rotation reach clients? |
| Incoming automation | Will uploads come from a controlled build pipeline, or do you need a formal incoming queue? |
| Mirroring | Must the VPS mirror another archive or serve replicas in multiple locations? |
| Database requirements | Can filesystem state and reprepro’s local database be backed up and restored adequately? |
| Operational complexity | Can your team maintain configuration, permissions, key custody, HTTPS and clean-client tests? |
For a small private archive, the simplest reliable design is usually the best: one controlled signing workflow, one read-only HTTPS endpoint, explicit codenames and components, and a repeatable clean-client test.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
