cpak

Containerpak — a Linux application package format built on OCI
container images, by Mirko Brombin (the Bottles author). One Go
binary + a storage companion install apps from OCI images while the
package identity lives in a Git repository.

Core model: cpak install github.com/bottlesdevs/bottles — the repo
is the package. Its cpak.json manifest (v3) points at a
digest-pinned OCI image, declares exported binaries/desktop entries,
dependencies/addons, and every host permission the app needs — readable
before install.

Problems it solves

1. Flatpak runtime lock-in — Flatpak apps build against Flatpak
   runtimes and integrate through portal APIs. cpak runs what you
   already build in a Containerfile; typed host actions and native file
   choosers come without rewriting the app around portals.
2. Centralized stores — Snap requires the Snap Store; Flathub is the
   de-facto gatekeeper. cpak installs from any Git origin + OCI
   registry; the cpak Store is optional discovery on top — manifests and
   images stay in the publisher’s repo, ownership never moves.
3. Opaque permissions — sandbox grants are declared in the manifest
   (33 override keys for Bottles: sockets, devices, clipboard, network)
   and user-visible; updates diff old vs new effective permissions and
   new grants need interactive approval.
4. Duplication across apps — OCI layers stored by content digest:
   packages referencing the same bytes share layers; local dedup across
   packages via storage drivers. (Flatpak dedups runtimes; Snap needs
   its daemon.)
5. Daemon-free, low footprint — two static binaries, no snapd-style
   system service; rootless sandbox (user namespaces, rootless
   OverlayFS, seccomp, Landlock). cpak doctor verifies host
   capabilities.
6. Update provenance — git-native versioning: follow a branch, a
   release tag, or pin an exact commit; lock files pin manifest hashes +
   OCI digests. Rollback is built in.

Honest caveats (from cpak’s own comparison): young ecosystem, small
catalogue, less field testing than Flatpak/Snap on some environments.

How Bottles uses it

Bottles 66+ ships cpak as its second official package (experimental,
next to the recommended Flatpak). Its cpak.json:

• Image: ghcr.io/bottlesdevs/bottles@sha256:… — digest-pinned, built
  from the same release tag as the Flatpak
• Exports bottles + bottles-cli binaries and the desktop entry
• UMU arrives as a direct cpak dependency — the Proton-outside-Steam
  runtime is installed/managed by the package graph, not hand-assembled
  by the user (see UMU)
• Bottles recognizes the cpak install as an official package; cpak
  instances stay independent (relevant for Wine prefixes per install)
• ARM64 only via cpak: Bottles 67.4’s aarch64 test release (with
  Soda 11.0-10 bundling FEX) ships through cpak — Flathub stays
  x86_64
• The cpak build avoids the Flatpak sandbox issues the Wine runner path
  historically hit (runner downloads, dependency installers)

Same pattern for the Office 365 on Linux via Bottles (Soda 11) TIL —
the cpak package + Soda 11 runner is what made that work.

Context

• Linux package managers — where cpak sits among Flatpak/Snap/deb
• GitHub: Containerpak/cpak
  (Go, LGPL-2.1, since 2023-09); docs: cpak.it/docs
• Not to confuse with Distrobox: cpak packages one reviewed app with
  declared permissions; Distrobox gives you a mutable environment you
  enter and modify