Show menu

Under the hood

A technical overview of how APM (AppImage Package Manager) optimizes your applications.

Transparent Ingestion

APM doesn’t require a new file format. It works directly with standard .AppImage files. When you install an app, APM performs Transparent Ingestion:

  1. Extraction: The AppImage’s SquashFS payload is extracted.
  2. Indexing: Every file (binaries, libraries, assets) is hashed using SHA-256.
  3. CAS Storage: Files are moved into a global Content-Addressed Store (CAS) at ~/.local/share/apm/store/.
  4. Materialization: APM creates the application directory using hardlinks (or reflinks on supported filesystems like Btrfs) pointing back to the CAS.

This results in an “installed” directory that looks exactly like a normal extracted AppImage but occupies almost zero additional space if its dependencies are already present in the store.

Content-addressed store (CAS)

The CAS is the heart of APM’s efficiency. By storing files by their content hash rather than their name, APM automatically deduplicates identical files across different applications. If you have five different Electron-based AppImages, the core Electron framework is stored only once.

Sandboxing with Sydbox

APM uses Sydbox to isolate applications. Unlike raw AppImages which have full access to your $HOME, APM-managed apps are restricted by default.

Sydbox leverages Landlock, a modern Linux kernel feature, to provide granular filesystem access control without the overhead of namespaces or mounting.

APM determines sandbox permissions through:

  1. Signed Metadata: The developer explicitly declares permissions (network, filesystem, etc.) in the package metadata. Because this metadata is signed and verified via DNS, APM trusts it.
  2. Heuristics (Fallback): If no signed metadata is available (e.g. installing a raw URL), APM scans the app’s .desktop file and effectively guesses safe defaults.
  3. User Overrides: You can always manually grant or revoke permissions via apm config.

Delta Updates and Zsync

APM makes updates extremely fast by supporting zsync and HTTP Range requests.

When an update is available, APM compares the new version’s metadata with your local CAS. It only downloads the specific blocks or files that are missing from your store. Even for multi-gigabyte applications, an update might only require a few megabytes of transfer.

DNS verification

APM supports an optional layer of trust called DNS verification. Developers can sign their AppImages with an Ed25519 key and publish the public key as a DNS TXT record. APM verifies this signature during installation to ensure the AppImage has not been tampered with and truly comes from the domain owner.

APM Network

APM Network is a WebSub-based hub that connects developers and app stores. When a developer publishes a new version, they send a notification to the hub. App stores and other subscribers receive the update automatically, keeping their metadata in sync without polling. Learn more on the APM Network page.