Cncf Buildpacks.instructions

---
description: Future architecture reference for migrating from imperative CI/CD to declarative Cloud Native Buildpacks
applyTo: "**"
---

# Future Architecture: CNCF Cloud Native Buildpacks

While the Inversion of Control architecture successfully decouples build logic from the CI platform via the Bootstrapper pattern, the ultimate evolution is to adopt Cloud Native Buildpacks (CNB). Maintained by the CNCF, Buildpacks eliminate the need for custom build scripts entirely by automatically detecting application frameworks and compiling them into secure, optimized, OCI-compliant container images.

## The Paradigm Shift

Moving to CNB changes the CI/CD contract from *imperative* to *declarative*.

- **Current state:** The repository tells the framework exactly *how* to build the app step-by-step using shell scripts.
- **Future state:** The repository hands the source code to a standardized CNB Builder (e.g., Paketo Buildpacks). The Builder detects language and framework files, automatically provisions the correct toolchains, and outputs a deployable artifact.

## Key Considerations for Migration

### Deployment Target Mismatch (Critical Risk)

Cloud Native Buildpacks natively output *container images* (Docker images), not static files. If the deployment target only accepts static assets, either:
1. **Migrate hosting** to a containerized runtime (Google Cloud Run, AWS App Runner, Azure Container Apps, or Kubernetes).
2. **Implement an artifact extraction step:** Use CNB to build the container, run it temporarily, extract compiled static files from the container's `/workspace` directory, and push those files to the static host.

### Pipeline Simplification

Once the deployment target is resolved, the CI orchestrator reduces to a single command: