For one product with a handful of packages, a flat repository is simpler to publish and document. If you need several suites, such as stable and a preview channel, or several components, use the standard dists layout. Both formats support signed InRelease files, so choose on structure, not on security.
Definitions
In the standard layout, a source list line names the archive root, a distribution that maps to a directory under dists, and one or more components. Index files sit in per architecture directories, and packages are kept in a pool directory. The format page suggests keeping packages in a subdirectory other than dists rather than directly in the archive root.
A flat repository does not use the dists hierarchy. The meta index and indices sit directly in the archive root or a directory below it, and the source list line names the URI and a directory path. It supports Packages and Sources, plus InRelease, Release and Release.gpg. Translations and Contents indices are not defined for flat repositories.
Comparison
| Question | Flat | Standard dists |
|---|---|---|
| Source list line | URI plus directory path | URI, distribution, components |
| Multiple channels | Use separate directories or hosts | Use separate suites |
| Contents and Translations indices | Not defined | Supported |
| Signing | InRelease, Release, Release.gpg | Same |
| Setup effort | Lower | Higher |
Decision guide
- One product, one channel, few architectures: flat.
- Stable and preview channels that customers choose between: standard layout with a suite per channel. See update channels.
- Many components, such as server and agent packages that customers install separately: standard layout with components.
- You expect to grow: start with the standard layout, since moving customers later means changing every source list.
Whichever you choose
Sign the metadata, publish the key fingerprint on an HTTPS page, and consider the expiry settings in Valid-Until and Signed-By. Test a clean install on every distribution release you support, and keep the repository URL stable, because changing it breaks automatic updates for every customer.
Document the exact line
Give customers the full source list line in your install guide, including how to reference the keyring. Copying a vague example leads to support tickets, and worse, to customers disabling signature checks to make an install work. Tell them never to do that.
If you want a second look at what you ship, Safeguard can generate and scan an SBOM and run dependency scanning with reachability analysis, and you can try the free scan.
Quick check
Is a flat repository less secure?
No. It supports the same InRelease and Release.gpg signing. The difference is layout.
Can I switch later?
You can, but every customer must change their source list, so choose with growth in mind.
Sources
Last reviewed: 19 October 2026.
