Version the inputs
Use TPA package definitions or prepared Debian trees alongside your source. Build and test the actual DEBs; qualify reproducibility rather than assuming it.
Nix-inspired discipline. Debian-native tools.
Your fleet.
Your releases.
Still Debian.
Build and deliver trusted software across Debian machines without replacing APT, dpkg, SSH or systemd.
Build locally. Sign locally. Keep package definitions in version control. Test the DEBs, review their hashes, and sign on a device you trust. TPA.run distributes the approved repository; your existing tools decide where and when to install it.
- Versioned package definitions
- Owner-controlled signing
- Native APT delivery
Release discipline for fleet management
One tested release.
Many Debian machines.
Make the artifact—not a remote build or an unreviewed script—the hand-off between development and operations.
Approve exact bytes
Review package identities and SHA256 hashes. A separate signing device can retrieve and recheck staged artifacts before signing APT metadata. No DEB rebuild follows approval.
Activate a verified snapshot
Owner-side TPA creates the repository. SSH-CAS transfers missing content; an expected-parent check prevents a competing publication from being silently overwritten.
Use native host tools
Select a canary, install the chosen version through APT, and check its service with systemd. Use your existing automation to repeat the approved rollout across the fleet.
Staged signing requires a compatible current TPA CLI. See release availability before following that workflow.
Take the discipline. Keep Debian.
Nix-inspired workflows.
Not a new operating system.
Explicit inputs, identifiable artifacts and reviewed releases—delivered through the Debian interfaces your machines already use.
DEBs, not another package store
Your payloads remain ordinary .deb files. dpkg records installed packages; APT handles dependency resolution and trusted repository metadata. No Nix runtime is required.
SSH, not a mandatory fleet agent
Keep your existing inventory, configuration management and host access policy. TPA.run is the release-distribution layer, not a host-inventory or remote-command control plane.
systemd, not a new supervisor
Packages can ship ordinary service units. Health checks and restart policy stay with the host. Publishing a repository does not authorize an installation or start a service.
This is not a promise of Nix derivations, isolated builds or atomic whole-system rollback. Package downgrades and recovery still require compatible packages, configuration and application data. Plan the rollout and recovery boundary.
Infrastructure you can inspect
A trusted release layer.
Not another fleet platform to operate.
Separate building from signing
CI can build, test and upload while the owner reviews the manifest on another device. Hashes identify the exact bytes; test results and source provenance remain separate evidence.
Review the signing workflowPublic or private APT sources
Distribute public software or authorize private downloads with repository-scoped reader credentials. Machines consume standard APT sources; publishing and operator permissions stay separate.
Understand accessTransfer less. See what changed.
Content-addressable SSH uploads reuse existing chunks. Inspect repository history, uploaded and reused bytes, logical size and HTTP egress without confusing them with filesystem usage.
Read the usage modelHosted or self-hosted
TPA works independently. Host the finished signed tree on an ordinary SSH/web server, or use TPA.run for authenticated CAS transport and verified generation activation. Neither host builds or signs for you.
Choose a hosting strategyStart with the published tools
Keep your machines Debian.
The canonical bootstrap repository contains TPA 0.8.0 for amd64, arm64 and riscv64. Review the inventory and publisher's key before configuring APT; receiver and automation releases remain separate.
EDCEE63AA803737C8ABBC1E4A34190A2829D5E54