aptly's goal is to establish repeatability and controlled changes in package environments.

aptly produces a fixed set of packages in the repository, so that package installation and upgrade becomes deterministic. At the same time aptly is able to perform controlled, fine-grained changes to repository content. aptly allows you to transition your package environment to a new version, or rollback to a previous version.

aptly has several core entities:

mirror of remote repository, consists of metadata, list of packages and package files
local repo
local package repository, consists of metadata, packages and files, packages can be easily added and removed
immutable list of packages, basic block to implement repeatability and controlled changes
published representation of aptly generated snapshot or local repository, ready to be consumed by apt tools

The schema of aptly’s commands and transitions between entities:

aptly core schema

We can start with creating mirrors of remote repositories. Also we can create local package repositories and import package files. Local repos could be modified by copying and moving packages between local repositories and importing them from mirrors. Snapshot could be created from remote repository (official Debian repositories, backports, 3rd party repos, etc.) or your local repository (custom built packages, your own software). Snapshots can be used to produce new snapshots by filtering other snapshots, pulling packages with dependencies between snapshots and by merging snapshots. Any snapshot can be published to location (distribution name, prefix) and consumed by apt tools on your Debian systems. Local repositories could be published directly bypassing snapshot step.

aptly can be used as CLI tool and HTTP REST API service, whatever works best in your environment.

Next section, Why aptly? describes why aptly is unique.