Build OCI images from APK packages directly without Dockerfile
1.6k
Stars
221
Forks
154
Open issues
30
Contributors
AI Analysis
apko is a declarative OCI image builder that constructs container images from APK packages without requiring Dockerfile syntax, emphasizing reproducibility, speed, and minimal image size. It is purpose-built for teams needing secure, lightweight containers with SBOM support and multi-process orchestration via s6, making it ideal for DevOps practitioners and container-focused organizations like Chainguard; it is not a general-purpose Docker replacement but rather a specialized alternative for ...
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
APK-native OCI builder emphasizing reproducibility and minimal images over Dockerfile flexibility
apko is a declarative OCI image builder from Chainguard that constructs container images from APK packages without Dockerfiles, prioritizing reproducibility, speed, and minimal image size. It targets organizations building secure, auditable container infrastructure at scale — particularly those already using Alpine Linux or committed to supply-chain security. The project is actively maintained and serves as part of Chainguard's internal tooling ecosystem, but adoption appears concentrated within security-focused and DevOps-adjacent communities rather than mainstream container development.
Created by Chainguard in February 2022 to solve internal needs for fast, reproducible image builds, apko emerged from influence by Google's ko and distroless projects. It positions itself as complementary to melange (APK packaging tool) rather than as a general-purpose Dockerfile replacement, acknowledging the tradeoff between declarative guarantees and scripting flexibility.
Steady but slow adoption trajectory: 1,645 stars over 4+ years with 221 forks suggests niche but deliberate uptake. Recent activity (5 stars in last 7 days, last push 2026-07-06) indicates ongoing maintenance. Growth appears driven by security and supply-chain communities rather than mainstream container adoption, consistent with Chainguard's positioning in the security tooling space.
adoption not verified in README. No explicit customer list, deployment statistics, or case studies provided. Indirect signals: Chainguard uses it internally for their own images; presence in mainstream package managers (Homebrew, cgr.dev container image) and Kubernetes Slack community suggests some practitioner adoption, but scale and breadth remain unclear.
Likely a single-purpose Go binary that orchestrates APK package resolution, layer construction, and OCI image emission without invoking Docker or Dockerfile parsing. Based on README, appears to use s6 supervision suite for multi-process supervision and generates SBOMs alongside images. The declarative YAML format and emphasis on reproducibility suggest deterministic dependency resolution and layer generation.
not documented in README
Recent push date (2026-07-06, same as evaluation date) confirms active maintenance. README indicates work-in-progress status but no deprecation signals. Presence in Homebrew and container registry suggests operational maturity despite 'WIP' disclaimer. Maintenance appears ongoing but not high-velocity — consistent with a stable tool serving defined use cases rather than rapid feature expansion.
ADOPT IF: you are building container infrastructure where reproducibility, auditability, and supply-chain visibility are non-negotiable (security-critical, compliance-driven, or large-scale DevOps organizations); your software already targets Alpine/APK ecosystems; and you can invest in packaging upstream dependencies as APKs via melange or similar. AVOID IF: you need rapid scripting flexibility, `RUN` statement portability, or broad non-Alpine base image support; your team is unfamiliar with declarative configuration or APK packaging; or you require extensive community tooling ecosystem integration. MONITOR IF: you are evaluating multi-tool container image supply-chain strategies; considering reproducible builds as a long-term organizational investment; or work in security/DevOps but have not yet committed to APK-based infrastructure.
Independent dimensions
Mainstream potential
3/10
Technical importance
7/10
Adoption evidence
3/10
- Narrow ecosystem lock-in: success depends on strong APK packaging tooling (melange); if packaging becomes friction point, adoption will plateau.
- Adoption remains opaque: lack of public telemetry or case studies makes it difficult to assess whether real-world production usage is significant or primarily internal to Chainguard.
- Declarative-only philosophy trades power for safety: teams with complex, dynamic build requirements may find the constraint untenable and revert to Dockerfiles.
- APK ecosystem concentration: limited to Alpine Linux packages; organizations using Debian/RPM-based systems must either adopt Alpine as base or fork alternate packaging.
- Slow mainstream growth relative to peers: after 4 years, star count lags ko and buildah by 5–6x, suggesting ceiling on non-specialized adoption.
apko will likely remain a durable, actively maintained tool for security and DevOps-focused organizations prioritizing reproducibility, but is unlikely to rival Docker/Dockerfile as a general-purpose image build mechanism. Expected future: incremental feature additions (better SBOM integration, supply-chain attestation features), tighter integration with Chainguard ecosystem, and slow organic adoption within the security/compliance tooling space. Mainstream adoption unlikely without a material shift toward reproducible-build-first container practices industry-wide.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Website
- https://apko.dev
- Language
- Go
- License
- Apache-2.0
- Last updated
- 22h ago
- Created
- 54mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
No open issues — clean slate.
Top contributors
Similar repos
podman-container-tools/buildah
Buildah is a command-line tool for building OCI and Docker container images,...
buildpacks-community/kpack
kpack is a Kubernetes-native service that builds OCI container images using...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
1.6k | +7 | Go | 8/10 | 22h ago |
|
|
8.5k | — | Go | 8/10 | 13h ago |
|
|
8.9k | — | Go | 8/10 | 8h ago |
|
|
1.1k | — | Go | 8/10 | 1w ago |
|
|
1.1k | — | Go | 7/10 | 13h ago |
|
|
1.2k | — | Go | 8/10 | 23h ago |
ko (8,467 stars) builds Go source directly into images; apko builds from already-packaged APK artifacts. ko targets Go developers; apko targets system packagers and security-focused teams. ko emphasizes speed for development; apko emphasizes reproducibility for supply-chain security.
buildah (8,912 stars) is a low-level container image builder with Dockerfile support and rootless capabilities. Buildah is more general-purpose and Podman-centric; apko is narrower, APK-specific, and reproducibility-focused. Buildah is the established mainstream choice; apko serves specialized requirements.
Traditional Dockerfiles offer maximum scripting flexibility with `RUN` statements; apko deliberately removes this to guarantee reproducibility and auditability. Dockerfiles are universal; apko requires buy-in to declarative, package-based thinking and APK ecosystem.
kpack (1,077 stars) uses Cloud Native Buildpacks for image construction on Kubernetes. kpack is abstraction-heavy and buildpack-focused; apko is minimal and package-focused. Both prioritize reproducibility but target different deployment contexts.
distroless provides minimal base images but relies on Dockerfile layering to construct them. apko builds distroless-style minimal images directly from declarations without Dockerfiles, combining both the concept and the tooling.