[Sandbox] Dexfile

[ep0ll]

Project summary

Dexfile is a dynamic, modular extension of Dockerfile, functioning as a BuildKit frontend that introduces native programming constructs for complex, reproducible, and secure container image generation.

Project description

​The Dockerfile reshaped how the world builds containers. But its static, procedural design has not evolved with today’s dynamic, cloud-native systems. Modern build pipelines need adaptability, reuse, and modularity—yet Dockerfiles provide none. Teams resort to fragile shell scripts, external CI logic, and duplicated instructions that fragment workflows, slow builds, and break caching.

​Dexfile redefines this foundation. It is a dynamic superset of Dockerfile, implemented as a BuildKit frontend. Every valid Dockerfile runs unmodified as a Dexfile. Dexfile extends this familiar format with logic, modularity, and composable control, transforming static image definitions into programmable, reproducible build frameworks.

Why Dexfile?

1. Reusable, Modular Build Logic: Dockerfiles are inherently linear and isolated. Dexfile introduces parameterized targets function-like build units that can be composed, imported, and reused across projects. This eliminates copy-paste duplication, promotes DRY design, and improves long-term maintainability.

2. ​Dynamic and Adaptive Flow Control: Dexfile embeds native conditional and iterative constructs (IF, ELSE, FOR loops) directly into the build language. This dynamic logic allows builds to be adaptive and context-aware, making build definitions smarter and eliminating the need for brittle external scripting to manage complex build flows.

3. ​Transparent and Reproducible Supply Chain: Dexfile replaces opaque RUN fetches with declarative IMPORT instructions for Git repositories and HTTP archives. Dependencies become explicit, verifiable, and cache-aware, leveraging BuildKit’s content-addressable execution model for guaranteed reproducibility and auditable builds.

4. Unified Build Experience: Dexfile can orchestrate the entire lifecycle—from dependency resolution and testing to artifact packaging and OCI image creation—within a single definition. It unifies fragmented tooling, providing a simple yet powerful alternative to Buildpacks that favors developer control and incremental adoption.

​Dexfile takes the simplicity developers love about Dockerfile and extends it for the complexity of modern software. It makes container builds dynamic, modular, and reproducible—bridging the gap between static configuration and programmable automation, and enabling teams to build with clarity, speed, and confidence.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/dexnore

Project repo URL in scope of application

https://github.com/dexnore/dexfile

Additional repos in scope of the application

https://github.com/dexnore/templates

Website URL

https://github.com/dexnore/dexfile

Roadmap

https://github.com/orgs/dexnore/projects/1

Roadmap context

Dexfile’s roadmap is designed to achieve technical maturity, strong adoption, and open collaboration—laying the groundwork for an open, sustainable cloud-native container build ecosystem atop BuildKit.

Near-Term Goals (Next 6–12 Months)

Core Syntax Finalization:

Complete the Dexfile grammar and semantics, establishing predictable behavior and strict backward compatibility with Dockerfile builds.

Automated Test Coverage:

Exceed 90% automated test coverage spanning the parser, evaluator, and BuildKit integration to ensure robust, maintainable releases.

Developer Experience:

Release a VS Code extension with syntax highlighting, auto-completion, linting, and in-line documentation, promoting rapid adoption.

Documentation & Community Enablement:

Launch a documentation portal with tutorials, API references, and migration guides to streamline onboarding and contribution.

Mid-Term Goals (12–24 Months)

DexModules – Modular, Reusable Builds:

Deliver DexModules to enable shareable, composable build blueprints for major language and platform ecosystems, including automatic source detection and OCI artifact export.

DexHub – Shared Registry:

Operate DexHub, a public registry for DexModules, supporting collaboration, discoverability, and standardized best practices.

Performance & Ecosystem Integration:

Optimize for BuildKit’s caching, concurrency, and multi-architecture support. Expand conformance with CNCF interoperability standards and integrate with CI/CD and observability tools.

Long-Term Goal (Beyond 24 Months)

Stable, Versioned Specification:

Advance to Dexfile v1, defining the stable, CNCF-compatible build specification. Implement semantic versioning (#syntax=dexnore/dexfile:1) and formalize conformance criteria for ecosystem compatibility, tooling, and migration safety.

Contributing guide

https://github.com/dexnore/dexfile/blob/master/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/dexnore/dexfile/blob/master/CODE_OF_CONDUCT.md

Adopters

No response

Maintainers file

https://github.com/dexnore/dexfile/blob/master/MAINTAINERS.md

Security policy file

https://github.com/dexnore/dexfile/blob/master/SECURITY.md

Standard or specification?

N/A

Business product or service to project separation

This project is unrelated to any product or service.

Why CNCF?

Dexfile seeks CNCF Sandbox membership to gain neutral governance, community reach, and operational support needed to evolve into a widely trusted, interoperable build standard. Joining CNCF will accelerate adoption, ensure transparent development, and strengthen interoperability across the cloud-native ecosystem.

• Neutral Governance: Establishes Dexfile as a community-driven project, free from single-vendor influence.
• Ecosystem Integration: Aligns with CNCF’s mission to advance cloud-native build, packaging, and deployment standards.
• Collaborative Growth: Leverages CNCF’s open community and technical oversight to attract contributors and drive innovation.
• Operational Support: Benefits from CNCF infrastructure, security guidance, and event participation.
• Interoperability Focus: Enhances compatibility with existing CNCF projects and emerging build ecosystem standards.

Benefit to the landscape

Dexfile’s primary benefit is acting as a necessary abstraction layer that unites and enhances the functionality of critical CNCF projects, specifically BuildKit and OCI image specifications, without introducing fragmentation.

• Improves build reproducibility and provenance: Declarative imports and BuildKit integration make external inputs explicit and cacheable, promoting reliable, auditable image builds across CNCF projects and users.
• Strengthens supply-chain security: Enables dependency transparency and machine-readable provenance, supporting SBOM generation and SLSA-aligned supply chain assurances favored by CNCF.
• Reduces tooling fragmentation: Embeds flow control and reusable build units within the build definition, minimizing brittle shell scripts and CI glue, simplifying integration across registries, CI systems, and orchestrators.
• Fosters an open, shareable build ecosystem: DexHub and DexModules provide a community registry for curated build blueprints, helping standardize best practices and reduce duplication across CNCF organizations and projects.
• Supports adoption and migration: Backward compatibility with Dockerfile, plus migration aids, lower barriers for CNCF projects and users to adopt more secure, modular, and maintainable build workflows.

Cloud native 'fit'

Dexfile belongs in the Application Definition & Image Build area of the cloud-native landscape. It complements existing, widely used build and runtime projects by providing a BuildKit frontend that produces OCI artifacts and enables reproducible, auditable builds.

Cloud native 'integration'

Dexfile integrates directly with BuildKit as its execution backend. It acts as a frontend that translates Dexfile syntax into BuildKit’s Low-Level Build (LLB) graph, leveraging BuildKit’s content-addressable caching, parallel execution, exporters, and session features. Through BuildKit, Dexfile inherits integrations with OCI registries, containerd, and Kubernetes, producing fully compliant OCI artifacts. This deep integration enables Dexfile to deliver reproducible, cache-efficient, and secure builds while remaining compatible with existing BuildKit tooling such as buildctl and docker buildx, ensuring seamless adoption across cloud-native environments.

Cloud native overlap

• Buildpacks: Shares the goal of simplifying and standardizing build automation but differs by keeping low-level control. Dexfile allows developers to define explicit, reproducible build logic rather than relying on high-level auto-detection and abstraction.
• Dockerfile (BuildKit Frontend): Fully backward compatible yet more expressive. Dexfile extends Dockerfile with conditionals, imports, and modular constructs while preserving compatibility with existing BuildKit workflows and OCI outputs.
• Earthly (Earthfiles): Similar in enabling reusable, declarative build pipelines, but Dexfile is natively integrated with BuildKit, remains lighter, and focuses on standard OCI artifact production rather than proprietary orchestration.

Similar projects

• Dockerfile (BuildKit Frontend): The most direct technical analogue. Dexfile extends Dockerfile with modularity, conditionals, and imports while maintaining full backward compatibility and seamless BuildKit backend integration.
• Kaniko: A daemonless OCI image builder that operates as an execution engine. Dexfile complements Kaniko by serving as a declarative frontend capable of producing Kaniko-compatible outputs through BuildKit.
• Podman: Emphasizes OCI compliance and daemonless builds focused on runtime execution. Dexfile provides an additional declarative build definition layer atop BuildKit for programmable, composable pipelines.
• Buildpacks: Automates image creation from source code with opinionated detection logic. Dexfile overlaps in simplifying builds but gives developers full control with explicit, composable definitions.
• Earthly (Earthfiles): Shares a goal of reproducible and portable builds. Dexfile differentiates itself as a thin, native BuildKit frontend adhering closely to Dockerfile syntax for maximum compatibility and ecosystem reuse.

Landscape

NO

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

IP policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Will the project require a license exception?

N/A

Project "Domain Technical Review"

No response

Application contact email(s)

wygininc@gmail.com

Contributing or sponsoring entity signatory information

Or, if an individual or individual(s):

Name	Country	Email address
Sai Kiran Maggidi	India	wygininc@gmail.com

CNCF contacts

No response

Additional information

No response

[krook]

@WYGIN the Contribution Agreement draft has been sent by email for your review. We will execute it if the TOC votes to accept your project.

[jeremyrickard]

@WYGIN thanks for submitting this project for consideration as a CNCF sandbox project. After reviewing the application, we would like to postpone voting on this project and ask you to come back in 6-12 months. During that time, we would like to see some community building around the project and some additional maintainers.

Thank you!

[ep0ll]

@jeremyrickard

There was earlier discussion about the Dexfile / Devfile naming similarity. To avoid confusion, I’m considering renaming the project to Yardfile and moving it from the dexnore org to ctryard.

is there anything I need to consider before moving project, like a request to update contribution agreement?