Skip to content

Zarf Principles

Zarf is a tool for continuous software delivery to disconnected environments. To ensure that Zarf remains true to its mission and continues to provide value for its users, the following design principles serve as a framework for evaluating new features and capabilities.

Zarf is designed for airgapped environments, meaning that all functionality should operate without requiring external dependencies. This includes:

  • Ensuring that all packaged software and dependencies are self-contained.
  • Avoiding reliance on external repositories or registries during runtime.
  • Providing a seamless user experience for both online and offline operations.

The Zarf binary must remain lightweight and secure while offering core functionality. Considerations include:

  • Baking in only essential tools necessary for package management, deployment, and validation.
  • Avoiding unnecessary bloat by carefully selecting embedded utilities.
  • Ensuring security best practices, including dependency verification and signed releases.

Zarf operates in Kubernetes clusters but does not attempt to replace existing Kubernetes tooling. Instead, Zarf should:

  • Focus on enabling package management and deployment in airgapped clusters.
  • Complement, rather than compete with, Kubernetes-native solutions (e.g., Helm, Kustomize, and Operator patterns).
  • Facilitate cluster initialization and ongoing software management without enforcing opinionated infrastructure choices.

To maintain consistency in deployments, Zarf should emphasize:

  • Declarative package definitions that allow for repeatable deployments.
  • Versioned and auditable package formats that ensure integrity across different environments.
  • Support for GitOps workflows where applicable.

Zarf should remain simple to use and operationalize, with considerations such as:

  • Clear and concise configuration files that reduce complexity.
  • A user-friendly CLI that abstracts away unnecessary details while allowing expert-level control when needed.
  • Automation and scripting capabilities that streamline usage in constrained environments.

Zarf should be flexible enough to work in various environments while maintaining its core mission. This means:

  • Supporting multiple architectures and operating systems where feasible.
  • Allowing extensibility through custom package configurations and integrations.
  • Ensuring compatibility with industry standards to facilitate interoperability.

As an open-source project, Zarf should prioritize community involvement and transparency by:

  • Encouraging feedback and contributions from users and maintainers.
  • Providing clear documentation and guidance for adoption.
  • Adhering to open governance principles to guide long-term sustainability.

These principles help guide the evolution of Zarf while ensuring that new features and capabilities align with its core mission. By adhering to these guidelines, Zarf can continue to serve as a robust, reliable tool for software delivery.