Tool Comparison — linux-update-cds vs Alternatives¶
This document compares linux-update-cds with the most commonly considered alternatives for hosting a governed apt/yum mirror. The goal is to help you pick the right tool for your situation, not to sell this project.
Comparison table¶
| Capability | linux-update-cds | apt-mirror | aptly | Raw Pulp 3 | Artifactory |
|---|---|---|---|---|---|
| Air-gap / offline support | ✅ First-class — designed for it; on_demand sync decouples metadata fetch from blob transfer | ⚠️ Manual rsync to offline media; no built-in transfer workflow | ⚠️ Snapshot export/import exists but no air-gap transfer tooling | ✅ Pulp export/import API designed for cross-domain transfer | ✅ Offline bundle ("cold transfer") via Artifactory Edge or JFrog CLI |
| Azure Government / IL4–IL6 readiness | ✅ Bicep stack targets .usgovcloudapi.net; private DNS zone overrides included |
❌ No cloud-native integration; you operate the VM yourself | ❌ No cloud-native integration | ⚠️ Pulp itself is cloud-agnostic; you bring your own Azure-gov-ready infra | ✅ JFrog offers FedRAMP-authorized SaaS and self-hosted on gov cloud |
| Immutable snapshots / publication versioning | ✅ Pulp publications are immutable; clients can be pinned to a named version | ❌ Flat mirror; no snapshotting | ✅ Core feature; aptly snapshots are immutable and diff-able | ✅ Core Pulp feature | ✅ Artifactory snapshots and build-info immutability |
| Multi-distro support (Ubuntu / Debian / RHEL/EPEL) | ⚠️ Ubuntu 22.04 jammy only in Milestone 1; Pulp supports deb + rpm plugins | ⚠️ Debian/Ubuntu only (deb) | ⚠️ Debian/Ubuntu only (deb) | ✅ pulp_deb, pulp_rpm, pulp_python, pulp_container — broad ecosystem | ✅ Universal repository supporting virtually any package format |
| Lazy / on-demand sync | ✅ on_demand sync policy; blobs fetched on first client request and cached |
❌ Always eager; full mirror download required | ❌ No lazy sync; snapshot is fully materialised | ✅ on_demand and streamed policies |
✅ Remote repositories with caching / lazy fetch |
| Ops complexity | Medium — Bicep + Python wrapper reduces Day 1 effort; Day 2 (upgrades, Pulp internals) is non-trivial | Low — single cron job, no database | Low-Medium — CLI-driven, stateful DB, more steps than apt-mirror | High — manual cluster setup, migrations, plugin management | Medium-High (SaaS) / High (self-hosted) |
| Licensing model | Apache 2.0 (OSS) | GPL-2.0 (OSS) | MIT (OSS) | GPL-2.0 (Pulp core) + per-plugin | Commercial (Artifactory Pro/Enterprise); limited OSS edition (JFrog OSS) |
| Cost — software | Free | Free | Free | Free | Free (OSS tier, limited) — $20k+/yr (Pro/Enterprise) |
| Cost — infrastructure (Azure) | ~$300–$500/month (default quickstart) — see cost-estimate.md | ~$30–$80/month (single Linux VM) | ~$30–$80/month (single Linux VM + PostgreSQL) | ~$500–$800/month (comparable ACA or AKS deployment) | $500–$2,000+/month self-hosted; variable for SaaS |
| Maturity / community size | Early-stage OSS wrapper around Pulp 3 (Milestone 1, 2025) | Mature (~15 yrs), minimal active development | Mature (~10 yrs), small but active community | Active upstream (Red Hat-sponsored); used in production at scale | Very mature; large enterprise community |
| Hosted (SaaS) option | ❌ Self-hosted only | ❌ | ❌ | ❌ | ✅ JFrog Cloud (multi-cloud including GovCloud) |
| Suitability for regulated fleets (FedRAMP/IL4+) | ✅ Designed for this — private endpoints, Managed Identity, RBAC, Azure Gov DNS overrides | ⚠️ Possible with VM hardening, but no built-in controls | ⚠️ Possible with VM hardening; no cloud-native security posture | ⚠️ Possible with correct infra; requires operator expertise | ✅ JFrog has FedRAMP ATO path; Artifactory is used in cleared environments |
When to choose what¶
Choose linux-update-cds when¶
- You are deploying an Ubuntu/Debian apt mirror into an Azure Commercial or Azure Government environment and want a zero-touch Bicep stack with sensible defaults.
- You need air-gap support: the on_demand sync + Pulp export/import workflow maps directly to a cross-domain transfer pipeline (low-side mirror → transfer media → high-side consumption).
- You want immutable, pinnable snapshots so fleet nodes can be locked to a specific distro publication and rolled forward deliberately.
- Your team is Azure-native and does not want to manage Kubernetes or bare-metal infrastructure.
- You are in Milestone 1 scope: Ubuntu 22.04 jammy, single tenant, Azure Container Apps.
Choose apt-mirror when¶
- You have a single operations team, no air-gap, and just need a fast local Ubuntu/Debian mirror.
- Ops complexity must be minimal — a cron job and a few hundred GiB of disk is all you can justify.
- You do not need snapshots, publication versioning, or regulated-environment controls.
- You are running on-premises or in a cloud VM and want the simplest possible setup.
Choose aptly when¶
- You need immutable snapshots and diff-able mirror versions without adopting Pulp's complexity.
- You want a CLI-first, script-friendly workflow with no persistent service required.
- Your scope is Debian/Ubuntu only and you do not anticipate needing RPM or container image support.
- The team is comfortable with a stateful local database (BoltDB) and manual mirror promotion.
Choose raw Pulp 3 when¶
- You need multi-format support today: deb, rpm, Python, container images — from a single service, with a common API.
- You want full control over every Pulp plugin, deployment topology, and configuration.
- Your team has Pulp operational experience or is willing to invest in it.
- linux-update-cds's opinionated defaults (Ubuntu only, Azure-only, single-tenant) are too constraining for your use case.
Choose Artifactory when¶
- You need enterprise-grade, multi-tenant package hosting across dozens of formats and teams.
- A SaaS option with a FedRAMP ATO path is required (JFrog Cloud GovCloud).
- You have budget for a commercial license and want a supported, fully-featured product with SSO, access federation, and build-info tracking.
- You are running at a scale where the licensing cost is justified by reduced operational burden.
- You need a single platform for packages, container images, Helm charts, and build artifacts.
Honest limitations of linux-update-cds¶
- Ubuntu/Debian only in Milestone 1. RHEL/EPEL and RPM support is planned but not shipped.
- Single tenant, single ACA environment. Multi-tenant isolation or multi-region replication requires additional Bicep work not in scope for Milestone 1.
- Early-stage project. Community, documentation, and operational runbooks are growing but not at the depth of Pulp upstream or Artifactory.
- Azure dependency. The Bicep stack is Azure-specific. Adapting to AWS or on-premises requires replacing the IaC layer entirely, even though Pulp itself is platform-agnostic.
- No GUI. The operator interface is the Pulp DRF browsable API at
/pulp/api/v3/and the Python wrapper scripts. There is no dashboard.